The question how to scale Agile (especially Scrum) seems to be one of the biggest and most controversial topics in the agile community. I believe that the issue boils down to three major questions:
- Where do requirements come from? A single backlog for all teams? A project manager or product owner for the product owners or a committee of product owners?
- Where do the requirements go to? Or more specifically: How is it decided where they go to? Which team gets which task?
- How do we deal with dependencies between teams? How does Team A tell Team B that it needs a sub-feature in the next sprint so that it can build on that feature in the sprint after that? How is the software ultimately integrated?
A lot of complex ideas have been built around these questions. I feel though that we are in a kind of „Emperor‘s New Clothes“ situation here where everyone is intimidated by these questions and in awe of those complex solutions, the big charts that have been drawn to explain them and the additional roles that have been introduced to make them work. Many people seem to be too scared to just point out that common sense should be the major guiding factor here, and that additional roles and ceremonies should come second.
I believe that this is true especially for the third question. How can Team A expect to tell another self-organized team which stories it must pull (and complete!) in the next sprint? Or to take it one step further: How can Team A plan two sprints ahead to be able to make such a statement in the first place? How is that still agile? Of course, it is possible to draw up predictions for the next few sprints and the next major release based on team velocities and rough estimates, but these are predictions! Once we create a dependency between the predictions of two teams, the predictions become plans – and not the nice kind of plans, but the ugly types of plans that result in a lot of stress, anger and finger-pointing when they inevitably go wrong. With this kind of planning, we give up the idea of limiting our risk to one sprint. We give up the idea of responding to changes.
And this is where many people seem to forget common sense, because the strikingly obvious common sense solution to the problem is not to plan dependencies, but to avoid them. At all cost!
A cross-functional team is capable of developing features from start to finish without requiring outside help. At least that is how I usually define „cross-functional“ when asked about the meaning of the term. Once we simply accept inter-team dependencies, we give up the idea that cross-functional teams can truly exist. The real solution should be to either make the team cross-functional or to trust it to become cross-functional. A team cannot complete a feature alone, because the feature affects code maintained by another team? Well, then the team is not truly cross-functional. I believe that the correct solution here is not to shrug and give up a handful of agile principles. The correct solution is to give the team the full responsibility for the feature. The correct solution is to trust the developers. To challenge them. To give them the support and environment they need to complete the feature. The whole feature.
And yes, I am fully aware of the difficulties of delving into someone else‘s code. I have worked in technical domains before, where it took even great developers many months before they could make meaningful changes in the code base. I am not saying that it is easy to build features in code that you have never worked on. I am saying that it is better than giving up on agile values and principles and that in the long run, it is easier and actually more predictable than trying to manage dependencies between a large number of teams.
I know that this is difficult to apply in many environments, because a lot of companies are built in silos with non-cross-functional teams and interdependent projects, but I challenge both developers and agile coaches to work on changing these environments step by step to introduce common sense into this problem space. A meeting like a Scrum of Scrums is not a solution – it is a symptom of a problem that we have so far avoided to solve.
AgileEvangelist 