Patterns Of Agile Adoption: Team Focus Sets Us Up To Fail

March 23, 2013 — Posted by Al Shalloway

Bloggers note: I feel compelled to mention that this blog is not at all an attack on Scrum.  At Net Objectives, Scrum, within the context of Lean-flow, is a popular method we espouse along with Kanban.  This is an attack against the improper use of Scrum.  In the same way I love my Lexus but don't drive it into the Puget Sound or off-road.  Not because I don't like it, but because that's not what it is designed for.  Unfortunately, there are all too many folks who seem to think Scrum will solve all of your problems.  It won't.  But it can be a great tool in your toolkit when used properly: I also want to be clear that creating self-organizing (mostly) cross-functional teams is essential for great agility - at the team or across teams.  My concern is the myopic focus I see that is all too prevalent in the industry on starting teams and then expanding from there.  A bottom-up, team approach, has not succeeded often.  Learn why.

I have seen two patterns of Agile adoption in large (>150) development/IT organizations that occur very frequently. The first is to start the adoption of Agile with Scrum by selecting folks to create a pilot project.  The second is to do Scrum within the current organizational structure across several already existing teams.  Each leads to its own set of initial success only to be followed by other challenges.  These challenges often lead executives to believe Agile is not a good thing.

The ultimate challenges that occur happen because these two approaches to starting Agile do not directly address the three main challenges most of these organizations face:

  1. Undertaking too many things (e.g., not having proper product portfolio management)
  2. Not having a way to coordinate work across teams
  3. Having some folks who are spread too thin due to skill sets, expertise or legacy knowledge

Solving these problems is not a bottom up approach but requires an holistic perspective.  This blog will discuss how a systems-thinking, lean-flow approach can provide insights that a team based approach won’t.  Ironically, the most popular team-based approach, Scrum, insists on practices that make solving the third approach more difficult (I am referring to the need to have cross-functional teams).

Systems-thinking suggests that we look at our system as a whole and recognize that working on one part of the system has impacts, often inadvertent and harmful, on other parts of the system.  Lean-flow can provide insights into how we need to manage multiple team projects.

Scrum’s approach to Agile is to create self-organizing, cross-functional teams.  This is the ideal case and we agree with this intention.  In fact, the main reason Scrum works is that this team structure eliminates delays in the workflow.  If you have a team with all the skills on your team to deliver value, and use a two-week sprint, it is relatively straightforward for the team to build in an effective manner.  Delays are forced to be less than the two week time-box the team has put itself in. This is why Scrum pilots, when done this way (creating a special Scrum team to try it), almost always works.  Unfortunately, it often also causes other challenges.  For more on this see the blog Why Scrum Works and How This Tells Us When it Won’t (blog)

What we've done with this approach is avoid the 3 afore-mentioned challenges for the team.  We likely haven’t provided any insights into solving them beyond the team.  Our experience is that any self-contained team will see a 3-to-1 or even greater improvement over the standard structure of teams working on many different things and requiring other teams to build software solutions – regardless of the process they use.  Mix Agile methods into it, and you should get a 10-to-1 improvement for a pilot of this type in a typical, matrixed, waterfall environment.

Solving the problem at the team level is a far cry from providing insights on how to solve the previously mentioned problems.   But, in the enthusiasm of our Agile adoption we may not notice that.  Especially because many Scrum thought leaders suggest we start this way and we figure they must be right - after all, Agile is good, isn't it?  We don’t notice that in making certain key folks available to this team we have made life a little bit more difficult for everyone else.  In fact, we think this approach is so good we do it again and again, each with good success, until we run out of projects on which we can do this.  At this point we declare – Agile is tough, it doesn’t scale and the whole thing collapses.  We are somewhat comforted by the mantra that software is complex.  However, as I explain in a 4 minute video, this is just an example of how Successful Pilots Can Hurt an Agile Organization.

The fact is, looking at the team doesn’t provide insights into the bigger picture.  The team-of-team approach (Scrum-of-Scrums), still espoused by many in the Scrum community, has a long track record of challenge other than for keeping teams informed of decisions.  One reason for this is that intra-team dynamics (where Scrum works) are quite different than inter-team dynamics (where our challenges lie).  Yet, it is these inter-team dynamics that are so critical.

To understand why, let’s look at how companies are structured and what we really need to do.  Virtually all organizations are in a hierarchical structure. We manage people by different roles or responsibilities.  But our work flows across these roles and responsibilities. It’s only natural for managers to manage their folks by how busy they are, what their productivity is and the quality of work of their people.  But we need to attend to time-to-market, the effects of upstream groups on their teams and the effects they have on downstream teams.

Figure 1: How we manage Vs. what we need to manage. See Why Seeing the Value Stream is So Important on our Lightning Webinars page for a short video (< 8 min) that illustrates this and how Scrum is only a first order solution.

Let’s now consider the other team-based approach that we often see adopted.  This is where we keep teams having essentially the same responsibilities we had before but now have them attempt to do iterations.  In some sense, we are not really doing Scrum with this.  Why?  Because the teams aren’t truly cross-functional in most cases.  But following this approach puts us in a damned if we do and damned if we don’t.  Creating truly cross-functional teams would require adding more people with special skills that are not currently available to all of the teams.  Doing so is often not economically feasible, or even possible.  You often cannot hire subject matter expertise or the knowledge achieved only by being there when the code was written years ago.   And many teams don’t require a full-time person on the team. It adds insult to injury when Scrum thought leaders declare we are not motivated or disciplined enough and that it would, in fact, work if people would only remove the impediments faced by the team.

In reality, in this situation Scrum has taken a simplistic view that you need a fully-cross functional team.  But the reality is you often don’t.  While you want to avoid overloading your key people, this can often be done with better management of their workload.  Lean and Kanban provides methods for coordinating key people across teams, not to mention coordinating the teams themselves.

The result of either of these types of failures is that executives and stakeholders in the company just come away with the sense that Agile fails.  Making it harder to come back and do it the right way later.

So what do we do?  First, we need to understand the structure we are in.  Even if we can achieve Scrum teams across the board we don’t solve all of our problems.  Starting with Scrum pilots is often a good approach.  But they must be done with the intent of solving the larger, aforementioned problems.  Once we are armed with these insights, solutions are not far off.  To see an example of how we have helped organizations solve multi-team development challenges, look at the Coordinating Teams With Backlog Management chapter from our upcoming Using Lean and Kanban to Create Cross Agile Team Collaboration.

We have seen only two approaches that have repeatedly worked.  They are our own Lean Agile Roadmap (or one of several other lean-based approaches available) or Dean Leffingwell's Scaled Agile Framework.  If you are having some of the challenges described in this blog I strongly suggest adopting a lean-thinking point of view. Success is possible, but is much easier when you work on the real challenges.

If you have followed this path and want help, please contact us.  I am sure we can help.

Al Shalloway
CEO, Net Objectives
Certified Scaled Program Consultant and Lean-Kanban University Instructor.

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 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


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