Let Your Teams Design Their Own Approaches to Agile
If you are thinking of agile as part of a program, each team has to have its own approach to agile because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as adults, explain the desired principles (working software all the time and exposed interdependencies), and provide training and other resources they need, you are likely to get what you want.
In the program, what you need is for each team to deliver all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.
The other day Jason Yip tweeted an excerpt from the book Thinking in Systems: A Primer: "Large organizations ... lose their resilience simply because the feedback mechanisms ... have too many layers of delay and distortion."
This is why you cannot standardize on anything for any team in a program. A program needs resilience. It needs to be able to release early and often. Even though it’s a program, it still needs to be able to obtain feedback.
Each team must know the principles:
- You need to see all the work in progress.
- You want to flow work through the entire team.
- You want to see working software sooner rather than later.
Teams use agile and lean principles. Management treats the people on the teams as adults. The teams look at their own issues and design their own approaches to agile or lean, always keeping in mind that they need to deliver early and often.
When you want to meld these teams into a program, you might think things roll down from the program manager or the core team. Not so. Instead, this is where each team’s autonomy in making its own decisions about how it implements its approach to agile or lean is key.
The teams—the core team, the technical teams, and the teams that the core team represents—are the heart of the program.
This is a change from traditional process thinking or traditional program management thinking. This kind of thinking requires that the teams know how to do agile already and are just new to the program, not to agile. This kind of thinking also means the program manager is a servant leader.
In a program, you will have interdependencies. You want to minimize them by reducing batch size and the size of each feature, by coordinating the features with a program roadmap, and by looking at the value of each feature, not its cost estimate.
That means the teams need to become good at delivering—not estimating. It also means the product owners need to become good at creating ranked backlogs for the teams and changing them. It means the program needs a roadmap that can—and does—change.
Remember, agile is about the ability to change. The teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.
