Questioning Large Scrum Failure Rates

March 15, 2009 — Posted by Al Shalloway

In an interview in February 2008 (originally at agilecollab.com/interview-with-ken-schwaber), Ken Schwaber said “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” He continued to say “Scrum is a very simple framework within which the ‘game’ of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices.The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.”

While I agree with what Ken said, I admittedly was surprised by his admission. Two questions occurred to me when I read this. First, does Scrum really expose the dysfunctions so they can be seen? In my experience, many of the dysfunctions in a team are only properly understood if one understands Lean-Thinking - which most people don't. Second, why do “many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them”? Is management incompetent, unmotivated? We don't think so, but I found it odd that Ken didn't pursue this question. That is, "why does management accommodate instead of solve?"

At Net Objectives, we think to have an effective organization, you need to:

  • Identify the products whose creation or enhancement will make the greatest impact on the bottom line of the company
  • Match these product enhancements (projects) to the resources of the organization
  • Manage these projects so the product enhancements are achieved with the greatest quality and speed possible
  • Organize the software development teams so they can work with each other in the most effective manner
  • Use proper software engineering methods to both support the project management and to ensure the long term viability and low-cost sustainability of the products created
  • Create a learning environment so that the process used is continuously improved

These map out into four different areas of the company:

  • Product portfolio management
  • Enterprise organizational management (how the teams are organized to get their work done)
  • Project management
  • Technical management

Our experience that only some of the time is the real problem with the dysfunctionality of the teams. It is more often the case that the root cause of blocked flow is somewhere else in the organization (even if it is showing up at the team level). So, if you arbitrarily start with Scrum (as most Scrum coaches/consultants suggest) it may be that companies aren’t getting the value they seek because they aren’t solving the real problem. Furthermore, the problems in the other areas are typically caused by violating lean principles which most people aren’t familiar with. Therefore, the reason people accommodate the problems is that they really don’t know how to solve them.

I suggest we might learn something by applying the five whys technique to this problem. Ken asked the first one, here's the second why?

Q: Why do people accommodate the inadequacies or dysfunctions instead of solving them?
A: They don’t notice that this is what they are doing.

Q: Why don’t they notice this is what they are doing? (Accommodating instead of fixing)
A: Because they don’t understand the implications of the challenges (i.e., they don’t understand Lean) or the problems aren’t at the team level.

Q: (Assuming they don’t understand the implications) Why don’t they understand the implications of the challenges?
A: Because that requires an understanding of Lean principles which aren’t discussed by most Agile consultants.

Q: Why don’t most Agile consultants talk about Lean?
A: Because a lot of people have had success with Scrum and Scrum’s leaders claim you don’t need Lean (even go so far as to discourage discussion of it).

Q: (Assuming the problem isn’t with the team) If the problem isn’t with the teams, why do people so often start there?
A: Because that’s where it looks like the problems are.

Q: Why does it look like the problem is with the team?
A: Because the teams are thrashing and can’t get their work done.

Q: But why do people assume that that’s a team problem?
A: Because the American way is that the people having the problems can pull themselves out of their problems.

I could go on and on. I hope the point is made that if one looks at the challenges of companies attempting to do Scrum from a team perspective, one should expect a success rate of only 25%. That’s because only part of the time will the team be the main challenge. To see this requires a bigger view – that of the entire value stream.

If you found this blog interesting, you might find it useful to read "The Big Picture" from our upcoming Lean-Agile Software Development: Achieving Enterprise Agility.

If you have questions or comments about this blog, please make them at the leanagile yahoogroups discussion group.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility

 

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.


Comments

"why does management accommodate instead of solve?"

Oh what a question this is. I believe in 99% of the answers, the truth would be 'it's quicker and cheaper to accomodate'
Management generally don't want to hear that there is a problem, or what it will take to fix it. The 'work around' or whatever will get you moving forward is usually the best choice.

Obviously we all know it is the bad choice, and that these problems will rear their ugly head again and again, but that is the nature of the beast I am afraid.

We need management to think Agile too!

Regards,
David
http://www.jacksguides.com

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