There is a lot of work being done on scaling Agile. This makes sense. There are few people anymore that will argue against Agile methods on a small-scale. The problem is that many organizations are not small. Plugging these small-scale changes into the greater organization can be difficult and often has mixed results.
Any organization looking to scale needs to know why they want to scale. They need a plan to scale. They need a way to evaluate whether their transition is working.
A good way to think of what’s happening is by imagining a city skyline. Spreading Agile to all teams is equivalent to building more skyscrapers across the horizontal landscape. Scaling Agile in the organization is more like extending the existing skyscrapers higher in the vertical plane. The analogy isn’t perfect of course. Scaling will require more horizontal involvement and spreading will require a degree of vertical integration. The important part is the focus and most movement is in a different direction scaling than it is for spreading.
The reasons for scaling Agile are going to be different from the reasons all the teams should be working with agility. If the reason to scale Agile is that “Team A” did great when they started Scrum so we want all teams to do Scrum, that’s a bad sign. That’s a great reason to roll Agile out across an organization, but not necessarily to scale agile up within the organization. A better reason might be that the organization sees the benefits of rapid feature response and hopes to capture some of that at the strategic decision-making level.
Failing to have a plan in place for change is asking for resistance and early loss of momentum. Selling the idea of change is easier than the road to make the change. Just look at the phenomenon known as New Year’s Resolutions. Without a plan in place early momentum will get lost as the details are figured out. If there isn’t an individual or team in the organization dedicated to planning and working the change then look for outside help. Even if there is some outside help might not be a bad thing. Consider it an investment in the company.
What good is any Agile change without the ability to evaluate and adjust as it happens? From a reason and plan it should be easy to create what essentially becomes a definition of done for scaling agile. Without knowing what the end goal looks like there is no way to know if the change is providing the expected value or not.
Scaling Agile is a topic that is far to complex for a short blog post such as this. Over the next decade I believe that scaling Agile will become just as hot a topic, and as great a need, as Agile has become over the last one.