Software Development Team Dynamics Revisited
I’ve been thinking a lot recently about how teams interact and particularly where they fall down and why. What follows is a model that illustrates how I’ve observed high-performing teams interrelate when producing software, as well as causes for different kinds of intra-team dysfunction.
The outer circle represents the constraints a given team has accepted at least for the moment. These might be time, money, available skills/expertise, the technology stack, legacy code and so on. They should be revisited regularly and challenged when appropriate, but for any given situation, these are the ones that the team has accepted, or is obliged to accept. These constraints form a framework within which the team can operate.
It’s worth mentioning at this point that the circles within are not represented hierarchically. What is important is how they interact with one another. The centre circle represents some discrete piece of work. I’ve called it ‘story’ for simplicity, but even if you scale up to ‘project’ or down to ‘task’, the underlying relationships remain.
The ultimate purpose of the three inner circles is the same in essence; deliver working software that addresses some need. Each group has a focus and activities that are different, but related to the others. The disciplines within each group also tend to have their own worldview, rules and expectations that are not necessarily shared by the others.
Tech is the realm of creating elegant solutions to non-trivial problems.
Product is focused on bringing something useful to market to benefit the business in a timely fashion.
Research & Experimentation are information radiators. Software testers, data analysts, UX specialists and the like. Their focus is on making sure the people that matter have information that allows them to make informed decisions about what to do next.
The point here is not to create an exhaustive taxonomy of roles/disciplines and categorise them. Some roles (e.g. scrum master, delivery manager) fit in multiple spheres and indeed this is a good thing. The intersection of the disciplines is where the magic happens.
Imagine each group as a gravity well. When the gravity of each is equal, then the work (in this case a story) remains in the centre. When each group is equally represented within a team, and when each takes into account the needs of the others, then things tend to go well. What about when that isn’t the case?
When one group dominates, then you tend to get dysfunction and that tends to look different depending on the group.
If product is dominant, you may see the rapid buildup of technical debt as the team rushes to hit delivery deadlines, or it might be prototypes end up living in production, and so on. The focus is overly high on the delivery of ‘something’.
Where tech dominates, you tend to get things like over-engineering and the use of new tech for the novelty factor. More than once I have seen it manifest as unnecessary rewrites of legacy systems.
Where Research & Experimentation is overly zealous, taking action can be stifled by ‘what if’. Analysis paralysis and quality police/gatekeepers are two examples of the sort of dysfunction you might see.
In each case, the competence of each discipline in isolation is certainly a factor, but even if we assume sufficient competence in an isolated discipline, that is not enough to prevent these sorts of issues from occurring. It’s not advisable for any one discipline to eschew awareness of either the utility or the needs of the other disciplines. Perhaps more accurately, choosing to do so invites dysfunction and decision making that you may not understand or be happy with.
For example, no one wants to pour their heart and soul and time into a project that is doomed to failure, but it happens frequently. The real tragedy though is when people on the team don’t see it coming and suddenly the thing they believed in and willingly spent overtime on, is suddenly mothballed — never to be seen again. In most cases, the decision to kill a project doesn’t happen on a whim, but is rooted in the needs of the business. If those in the technical & research disciplines are insulated from, or choose not to be involved in understanding the needs of the business, then they will continue to be blindsided.
What each discipline needs is an understanding of the utility of the disciplines outside one’s own. How do the others augment my ability to do work, and what impact do my actions have upon them?
Let’s take story breakdown/slicing as an example. This is an activity that ought to involve representation from each group (3 amigos). The business need should be well understood by everyone. Not just ‘what do we need to build next’, but understanding the ‘why’. Why is this the most important thing to build next? Moreover, what is the cost of delay? What is the window of opportunity? If the team doesn’t have a handle on this, then it becomes more difficult to make informed design decisions to address them.
Here are some questions that each group might naturally ask:
Product:
- What’s the next most valuable thing we can deliver?
- What’s the smallest part we can deliver that creates value?
- What’s the fastest way we can get it done?
Tech:
- How do we build this in a way that is efficient and maintainable?
- Do we understand the request well enough to estimate complexity?
Research & Experimentation:
- What might cause this piece of work to fail?
- What are the most pressing risks and their consequences?
- How will we know if the change is having the intended effect?
These are all good questions to ask and ought to prompt good discussion. We can go further still. When each group listens to the needs of the others, and can make use of their information, then they can look beyond the piece of work in question to the circumstances surrounding it. It allows a qualitative conversation and the ability to make informed trade-offs about what to do next.
Here are some example questions that come up when the groups intersect effectively:
- How do we know this is the next most valuable thing to build?
Given the complexity of building this, is there something that is significantly less effort and almost as valuable? - Do we need to build (or refactor) something else first that will drastically reduce the effort of building this?
- Does it make sense to try several prototypes to see which solution is preferable (or to discover a better option)?
I understand the temptation to delve ever more deeply into one’s own discipline. There’s a never-ending list of things to learn. What I do assert however, is that understanding the utility of the disciplines outside your own is part of the fundamentals of your craft and you neglect it at your peril.
Originally published at http://testjutsu.com on September 13, 2018.
