How Successful Pilots Often Actually Hurt an Organization

October 3, 2010 — Posted by Al Shalloway

(BTW if you prefer videos, jump to the end for a link to one that covers this blog). 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 for 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 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 whom 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 affects 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

Alan Shalloway
CEO, Net Objectives

See Successful Pilots Can Sometimes Harm Agile Organizations to see a short video covering this topic.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban