So, you’ve long ago embraced on your agile journey, you enact Scrum so elegantly that new recruits get on boarded in a matter of days, and you are well on your way to excel in engineering practices. And now you want the Holy Grail of Scrum: that each team will be able to take any feature, and complete it end to end. Ahhhh, on to Scrum perfection!
Or is it?
If that’s your aim, think again. In particular if you're organisation is very large. Say larger than 5-10 teams.
Stem Cells, Stem Teams
In the middle of the 19th century German biologist Ernst Haeckel coined the term Stem Cells. According to his theory a fertilised egg is a stem-cell, from which all other cell types of an organism can evolve. Today we know that stem-cells can regenerate, thereafter transdifferentiate into other, specialised, cells. In an oversimplified way, such are blood cells, that transdifferentiate from the same stem-cells.
Living organisms start from either one or two cells. In the very early stages cells divide into identical cells - all cells are stem-cells at this point. And then some cells begin to transdifferentiate in a non-reversible process, and some stem-cells further divide into stem-cells. Such are bone-marrow cells (which transdifferentiate into blood cells). Stem cells are pluripotent - they can potentially becomes many types of cells. Transdifferentiated cells are unipotent - they can only do one function.
Many organisations, at one point, had stem-teams. These are teams that can take any kind of feature, carry any kind of task, deliver any kind of value. And then split into smaller teams.
However, when teams split, at some point they transdifferentiate. Hopefully not in a non-reversible manner. Yet, they do become specialised.
It is so tempting to think that we can keep teams at their stem functionality. This utopian team function does not scale. Here’s why.
Organisations are open systems: They have boundaries, they interact with the environment, they have inputs and they have outputs. They exchange information, consume resources and emit stuff, preferably valuable.
This exchange happens at the boundaries of the organisation. So the larger the organisation, the larger the boundaries. And the larger the boundaries, the more variation there is with the neighbouring environment.
Small organisations have a small ‘surface’, so at any given point in time they can interact with only few variances in their environment. This is why “stem teams” can operate in such organisations: even if they need to re-specialise, they all re-specialise to the same kind of environment variance.
Large organisations have a large ‘surface’, so at any given point in time they have to interact with many kinds of environments. Teams at the boundaries have to specialise according to the environment “near” them. And they lose their “stemness” compared to neighbouring teams.
It’s not that someone necessarily makes a decision to transdifferentiate the stem-team into something else. Being an open system, it’s the environment that drives the change in the team into what it is capable to.
Fostering a healthy team transdifferentiation
Traditionally organisations transdifferentiate their teams according to their proximity to its boundaries. So teams closer to the outer boundary of a typical software organisation are, for example, QA, support, maybe UI. Inner teams, interacting with those outbound ones are, for example, UI, customisation and business-layer teams. And inner still teams are, for example, infrastructure, DB, data-abstraction layer teams.
A typical result is that, compared to the outside environment, the inner teams are isolated. They develop a culture as if they were closed-systems: they know little about the environment outside because they hardly interact with it.
Moreover, the outbound teams in order to specialise with the ever-growing variances in the environment either consume many resources, or pay the context-switch cost of becoming “stem teams”, or both. Conversely, infrastructure teams are expected to become “stem teams” that can provide a super elastic and configurable solution to forecast the demands from an environment that they are not familiar with.
An agile approach is different. Once the stem teams begin to transdifferentiate, they should specialise in a certain kind of environment - that is, a special kind of business features. They should still be able to cover the various application aspects, and specialise in their business context.
Why is this so important?
There is no Holy Grail. Environments will keep changing, business contexts will keep evolving, successful organisations will keep growing. That means that teams will need to split and transdifferentiate.
Differentiating according to technology or architectural layering is doomed to failure: this creates pseudo closed-systems, that get ever disconnected with their real world context.
Not differentiating is impossible: the variations and permutations in both business and technology is not realistic for a effective teamwork.
Differentiating according to the environmental context - the organisation’s business - is also hard work. Yet, of these three options it is the only one that is both reasonable and keeps the system an open one.
Change or Die
For most traditional organisations this change may seem impossible. This means changing organisational structure, roles, letting go of ego, letting go of lifetime old beliefs, and many more.
This is true.
But the alternative is to ever-increase cycle times, build evermore features that no ones needs, attempt at omni-potential infrastructures that can forecast every possible and impossible scenario, in a competitive environment that embraces change.
There is no Holy Grail. Stem Teams are only good as far as your first few teams. Beyond 5-10 team, get your teams to know the organisation’s boundary that they interact with, and specialise there. So when you increase your success, they can split again and transdifferentiate to their new reality.
Stem cell electron micrograph image by Robert M. Hunt. Source: Wikipedia.