Heavy process is a great way to get average results
To drain all the energy and empowerment from your teams, you could go down the route of SAFe or PRINCE2.
At a more meta-level, concepts like Conway’s Law and Dunbar’s Number can inform us about the limits of self-organising team structures, and the ways in which we might want to shepherd this self-organisation. These are often reflected in the exemplar organisations that we see frequently in discussion: Spotify, Netflix, Github to name a few.
The common factors across all great software organisations are small, focussed, loosely coupled teams with high alignment.
Small things, loosely coupled.
If this were software we’d immediately start talking about bounded context, microservices, and connascence.
- A system for reasoning about the complexity introduced by co-dependent components.
By observing and categorising connascence, we can triage and prioritise areas of the system where we should concentrate on improvement.
We accept people and team problems as “difficult” and counter this by implementing process – done without spending time to observe, analyse and improve the small-scale interactions that end up resulting in macro problems. How often have you observed a failure or slippage not as the fault of the specific product team, but instead as a result of the context given to that team, and the external influences on the team? Pretty much always.
What if we had a set of tools that allowed us to reason about the complexity caused by context and coupling of teams?
My observation is we can take things like bounded context and connascence from software, and apply them to teams and interactions with considerable success.
In product land, it’s common for a team to be considered as the sum of its people and deliverables. “The inventory team” or “the ecommerce team” are a couple of ours. In reality, a team’s context is far more complex, especially when you consider teams further from the front-line.
We’ve found some success in creating team bounded contexts by deliberately documenting the context of teams – the team needs to create ways to cover every requirement in their context.
Having a clear bounded context elevates the teams to consider things that were traditionally driven by process and management decisions. Additionally, the overall cognitive load is reduced when you can clearly say “no, that’s not our problem” and know that it will be covered elsewhere, rather than worry and rove around finding an owner.
Coupling and Connascence
Each time we run a post-mortem to assess a breakage or a poor product decision, we inevitably find that the best of intentions have been influenced by multiple interconnected tendrils of … stuff – it all comes about because of team dependencies. Team connascences.
There are some connections that are stronger than others. There are some that we prefer, and others that we want to reduce or remove. Defining these connascences is a work in progress: we’re still discovering more. Here’s what we’ve come up with:
Static Team Connascences:
Dynamic Team Connascences:
We can prioritise by identifying strong connascence (e.g. shared deadline), and working on ways to reduce this to a weaker connascence (shared vision).
Team bounded context workshop
Connascence is not a perfect fit for team interactions. What drew me to it was the clarity with which it provides a system for reasoning about the complexity introduced by co-dependent components. My assertion is that there is value in a similar system for teams, organisations, and processes. A taxonomy with which we can discuss the common and recurrent failures inherent in fast-scaling agile engineering teams.
Let’s build a system for debugging organisations and processes in a way that empowers teams and individuals, instead of crushing them with rules and processes.
My strongest hope is that we end up in a place where — at an organisational level — instead of manipulating features and sprints and deadlines, we discuss solutions, people, and interactions.
For the extended version of this post click here.