On a recent project, we hit a minor setback where a system was delivered with components that didn’t play nicely together. How did this happen? One team member’s point of view (me) was that a strategy for interoperability was talked about and I felt we were all on the same page on how we were to proceed. My instinctual reaction at discovering the incompatibility of the components was to feel frustration that “I was under the impression that we’d talked about doing X so why was Y done” and that additional unplanned development was now a part of an already-tight deadline. That’s my first reaction and it’s okay to feel that way. However, stopping at that reaction doesn’t address the deeper issues. The other part to this story is examining the processes or environment that led to the design and delivery of a system where two key components would not play well together. That’s a decent-sized “Oops” to have happen and I want to learn to prevent this from happening again.
At $currentCompany, we do Agile/Scrum with all the requisite ceremonies – daily standups, demos, et cetera. Standups are intended to help the team be aware of what everyone else is doing, help others get unblocked, and discuss any issues. I really like this explanation of what stand up are about from Jason Yip:
Stand-ups are a mechanism to regularly synchronise so that teams…
- Share understanding of goals. Even if we thought we understood each other at the start (which we probably didn’t), our understanding drifts, as does the context within which we’re operating. A “team” where each team member is working toward different goals tends to be ineffective.
- Coordinate efforts. If the work doesn’t need to be coordinated, you don’t need a team. Conversely, if you have a team, I assume the work requires coordination. Poor coordination amongst team members tends to lead to poor outcomes.
- Share problems and improvements. One of the primary benefits of a team versus working alone, is that team members can help each other when someone encounters a problem or discovers a better way of doing something. A “team” where team members are not comfortable sharing problems and/or do not help each other tends to be ineffective.
- Identify as a team. It is very difficult to psychologically identify with a group if you don’t regularly engage with the group. You will not develop a strong sense of relatedness even if you believe them to be capable and pursuing the same goals.
The description above captures the ideal state and I think we do well on the “Identify as a team” and “Share problems and improvements” bullet points. We joke at standups and commiserate over issues/things. However, the “Coordinate efforts” and “Share understanding of goals” seems to be where things went left as it were. In particular, I think when “understanding drifted”, standups would have been a perfect place to bring it up in order for others working on various parts of the system to be given the time to assess how their understanding of their piece changes. I’ll keep noodling on this as I continue to introspect.