Scaling Agile from teams up is seductive. Almost any organization has at least a team or two where Agile methods would be an improvement over Waterfall methods. This focus on the team often obscures the bigger picture, however – creating enterprise agility.  I have seen many organizations achieve team agility while actually moving further away from enterprise agility – which is our true goal. Enterprise agility is the ability for an organization to deliver value quickly when needed. Let me give an example of what I have seen all too often.

The real problem

 A common problem facing many organizations is too many projects for individual team members.  This happens for several reasons:

  • People with certain skills, domain knowledge or familiarity with legacy code need to be spread across several teams
  • If companies have their staff organized by role, where business analysts report to one manager, developers to another, teams need to be formed and reformed as needed. People are not always available when needed so, while they are waiting, they work on something else.

But reflect on the efficiency (or lack of it) of the team members where both of these situations are true.  First, we can see that our most highly skilled people will be operating on the most teams and hence, will suffer the most from the multi-tasking required.

If we decide to go Agile with a team-based method, such as Scrum, we create a cross-functional, self-organizing team that focuses on working on only one project at a time.  When teams do this, they often have great success.  This is because they have appropriated these highly specialized people – putting them on the pilot project but reducing their availability elsewhere in the organization.

Ironically, much of the success is not actually due to the agile method followed, but mostly due to focusing a team on one project and likely being co-located as well. I say this because in our work with companies we’ve seen development groups in an organization greatly outperform similar groups using the same process.  The only significant differences were the hyper-performing teams were all reporting to one manager, were all working on one project, and were all co-located. Interestingly all the teams observed in these situations were using waterfall methods on 3-6 month projects. 

Now, let’s go back to our example.  Let’s say you have 100 people working on about 5 projects each.  If the average number of people on each project is 10, this means you’ll have about 50 projects going on at any one time. Let’s say you decide to “go Agile” and start a pilot project.  You pick some of your best people because you want to demonstrate success and give them a project to work on. You also co-locate them and give them a team room to work out of.  Even if they don’t change anything, our experience would suggest they’d develop better code three times faster than before – clearly a successful pilot project. 

I’d suggest, however, that the entire organization may not have improved – but may actually have gotten a little worse.  Only you won’t 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 5 projects to work on and some of the key people that used to be available to them are no longer available since they are on the pilot project.  Of course, you may not notice their slight degradation because getting things out of these teams was difficult already. Everyone is working even harder now – but it seems like nothing of value is coming out. 

So, what do we do?  Of course, our pilot’s success makes us think Agile is working, clearly better than our current process.  So the obvious solution is to create another Scrum team.  We figure we can keep doing this until we’ve transitioned the entire organization to Agile methods. For a while, we are pleased with our success. Each Agile project achieves great success.  All the while, however, the rest of our organization is slowly getting worse. 

Eventually, however, the Agile teams start running into the wider organizational impediments that we were trying to overcome in the first place.  While Scrum may have highlighted these more than before, it’s provided us little to solve them with.  At some point we realize scaling agility just isn’t going to work.  We conclude that scaling Agile is difficult!  Or, we lament that the organization will not solve the real problems they are facing.  This last one is true – unfortunately, team-centric Agile methods give us little insights into what the problems are or how to solve them.

 

Latest Article

Why Leaders Should Focus on Value Streams

Read on Cutter's site >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow