Originally posted October 3, 2010
It is seductive to think about scaling Agile up from teams to the enterprise. It seems the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is the ability of an organization to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – team agility – and move even further away from enterprise agility.
Let me explain.
A common problem facing many organizations is having too many projects going on for individual team members. This happens for several reasons:
Some people have certain special skills, domain knowledge or familiarity with legacy code and so need to be shared across several teams.
When staff are organized by role – with business analysts reporting to one manager and developers to another –teams get formed and reformed as needed. Of course, people are not always available exactly when they are needed. To solve this problem, people are often given two or more projects to work on so they will always have something to do.
When both of these happen, it is especially bad. The most highly-skilled, in-demand people end up being sucked into many teams, many projects, and so suffer the most from multi-tasking. And everything becomes inefficient because people depend upon them.
Suppose you have 100 people working on an average of five projects each. If the average number of people on each project is 10, then you have 50 projects going on at any one time. Now, you decide to “go Agile” and start a pilot project. You can pull together a cross-functional, self-organizing team that can have those highly specialized people dedicated to the pilot because you want to demonstrate success. You co-locate them and give them a dedicated team room. Even if they don’t change anything, our experience would suggest they’d be three times faster and build better code to boot – clearly a successful pilot project. This happens because the team can now focus on one project and this results in fewer delays which both speeds up the work and raises the quality of the product. For more on this, see my blog Challenging Why (not if) Scrum Works, written in May 2007.
That is great for the pilot project. And it is great for the specialized people because they aren’t having to multi-task. But it not so great for the rest of the organization because these critical people are no longer available. This sets things up for early success without a path to scale. Ironically, you’ve not really demonstrated that you’ve improved the business. In fact, you may have made it worse… only you may not have noticed it.
Why what will have happened? While the Agile team has had great success, the rest of the organization now has slightly more than five projects to work on and they no longer have access to those key people they had previously relied on but who have now been dedicated to the pilot. Of course, you may not notice this slight degradation because getting things out of those other teams was difficult already. Everyone is working even harder now – but it seems like even less value is coming out.
So, what do you do? Since the Agile pilot project was a success, it seems that Agile is clearly better than the current process. The obvious solution is to create another Agile team. And keep doing this until the entire organization has transitioned to Agile. For a while, you are pleased because each new Agile project is achieving great success. All the while, however, the rest of the organization is slowly getting worse.
Eventually, the Agile teams will start running into the wider organizational impediments that you were trying to overcome in the first place. Your Agile approach may not be making these impediments clear because your focus on the team success has blinded you to the bigger picture. Even if it does, team-Agile methods do little to help you solve enterprise issues. At some point, you come to realize that merely trying to scale Agile just isn’t going to work.
You conclude that scaling Agile is difficult! Or, you lament that the organization will not solve the real problems they are facing. This last one is true – because it is so difficult. unfortunately, team-centric Agile methods give little insight into what the problems are or how to solve them.
Achieving enterprise agility is an enterprise-wide problem. And it requires an enterprise-wide view. That is what Lean-Agile does. Even if you can only start at a team level, you must look to see how your local changes affect other parts of the organization. This, by the way, is one reason why Kanban can often be a more effective manner to start an Agile transition when you have challenges in creating teams. It enables you to start where you are and directly see the effects of your changes.
If you are interested in transitioning the enterprise, we’d love to work with you. Please contact me at alshall @ netobjectives.com or follow me on twitter @alshalloway