Why You Need to Begin Agile at the Program and Not The Team
I talk to many people who have spent a lot of money and time on training their teams in Agile (typically Scrum) only after a year or so seeing little results. They say that although their teams are following Agile practices but getting things out the door hasn’t improved dramatically. This is not the fault of Scrum, but rather the fact that the bottom up approach for transition is flawed.
The classic Agile model of achieving Agile at scale is to train up your teams while attending to how they work together and then scaling via scrum-of-scrums. There are two assumptions in this approach that are rarely questioned but are not valid. These are:
- Training teams individually while attending to how they work with other teams is an effective way to start
- As you try to scale, the Impediments encountered can then be removed by management assisting the teams as needed
- These assumptions are flawed, however. Both evidence and logic bear this out. The evidence is the number of companies that have tried this only to find the following challenges:
- Collaboration across the teams is not necessarily improved when they are being driven by different stakeholders as each team needs to listen to their own stakeholder. This causes a lack of alignment of the teams.
- As teams become effective most of the work required for deployment can often be built quickly but very often small parts are missing that prevent delivery because the teams are not being driven by the bigger context of what is the entire backlog of development
- Shared services, while being able to do a better job with Kanban, are driven by many people and aren’t clear what order to complete things in
- The focus on the development teams often has non-software development teams (e.g., sales, support) be left out of key planning steps
- It is often difficult to manage constraints outside of the development teams
The idea that optimizing the pieces (the teams) and then combining them ignores the reality that software development is an holistic approach. On must consider the entire value network (that is, the flow of work from concept to realization). Ignoring how work gets selected and hits the teams also does nothing to influence the transition from a project based mindset (where new work comes in to different teams) to a product based mindset (where stable teams continue to build and support products or IT supporting software).
Teaching teams individually and then combining them is also a flawed teaching method. Learning information, by itself, is not nearly as important as getting people to learn how to work together. For example, knowing what Scrum is is considerably different from actually doing Scrum. Doing Scrum effectively as a team is quite different that doing Scrum in coordination with others. As they say in sports – practice as you play. Teams at scale do not work in isolation, they work together. Training them in isolation does not give them any experience in working together. In order to do this, one must first create the context within which the teams will work. In that way, as they are being trained, how they will work with each other can also be discussed.
Attending to the bigger picture enables the organization to see impediments to the entire value network – not merely those affecting individual teams or how they work with each other. The value network includes much more than the teams – it includes all of the steps prior to the work hitting the teams as well as how the software is deployed and supported. Impediments that arise are often symptoms of deeper causes that are difficult to see in isolation. Although management does need to support the teams, they are often the only ones who are able to see the bigger picture of the value network.
When starting an Agile transformation, we have found the following assumptions to be more effective:
- It is better to transform an entire train (group of teams working together) so that the context in which they will be working is present when they are trained
- Improvements should be driven by looking at impediments to the entire workflow of the train and seeing what the underlying impediments to value realization across the value network is. Then address those relevant ones – often best seen by management who must attend to how the teams are working so they get input from them
The bottom line is, if you are attempting to transition to Agile methods, starting at the teams is not an efficient approach. One must take an holistic view and consider the entire value network – training the teams within that context. If you are considering a transformation to Agile methods and considering starting with Scrum training, I advise you to drop me a line (firstname.lastname@example.org) and let me discuss better options.