This was originally published in May 2009
Virtually 2 years ago I wrote a blog called Challenging Why (not if) Scrum Works. Basically, I was looking to see why Scrum worked so I would be able to best take advantage of Scrum. I believe Scrum works very much due to the structure of the team, the iterative nature of development and the proper context within which the team works. In this prior blog, I reported my experience with teams that were co-located, had all team members work together and worked on only one project compared with those who were not co-located, had team members of different roles report to different managers so they were not always working together and these same people were typically on 3-5 projects at once. The co-located teams were three times more productive than the other ones – even though the people, domain and customers were virtually the same. I thought this was a great insight for two reasons. First, it meant if you couldn’t deliver (or even build) in increments, there were things you could do to improve your development methods. Second, if you could do incremental development, these practices were some of the first things to implement.
Unfortunately, the Scrum community hasn’t been very receptive to examining where Scrum works best. Any questioning about where or when or how Scrum works has been labeled as “bashing Scrum.” Recent events have had me re-look at the issue in a different way. When, where and why does Scrum fail? I hadn’t really been thinking about this too much until I read the following from Ken Schwaber in an interview with Agile Collab:
“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.”
Unfortunately, Ken does not go into why this happens. I was left with the feeling that Ken thought this was a failure of management – not of Scrum. I am not so sure.
Does Scrum really fail to achieve its promise 3 out of 4 times? I am afraid so. I have heard that at the last Scrum gathering this number was bandied about and although it was somewhat arbitrarily selected, seems to have won general acceptance. Underscoring this was a recent email from Agile University. Although a separate company, Agile University is more or less run by Rally Dev, one of the larger Scrum training/coaching organizations. They post any Agile related course but 90%+ are Scrum related. I was, therefore, very surprised when I received an email from them with this subject line: “75% of organizations using Scrum will not succeed” This sounded even stronger than what Ken had said. Unless they are trying to scare us away from Scrum (which I doubt) I can only infer that they are implying that proper training will increase the success rate. Unfortunately, I think the high failure rate has little to do with lack of training. In my mind it has more to do with why impediments are not removed.
Now, am I saying Scrum is bad? No, I am not there yet, although I do believe for Scrum to work beyond the team you need more than Scrum. I am saying one must know when to use Scrum and when not to. One must also know what to add to Scrum making it more effective when it won’t readily work. As Scrum has become more popular, more and more different types and sizes of organizations have been attempting to adopt it. This has had Scrum be attempted in places it has not been used before. This causes new challenges that must be investigated.
In our upcoming book (since published), Lean-Agile Software Development: Achieving Enterprise Agility, we discuss the fact that lack of team agility is not always the major impediment to Enterprise Agility. In particular, in the Becoming an Agile Enterprise chapter, we talk about different places to start, depending upon where you are. While starting at the team level with Scrum is often good, you often need to start with the product management team – that is, where product enhancements to be worked on are selected. If you organization does not have well-defined teams, attempting to create them with Scrum, without addressing how projects are started, may or may not improve things at the enterprise level. Even when Scrum works at the team level, organizations very often report little impact to the bottom line. While this is better than nothing (if the teams are happier, that’s good), it usually doesn’t justify a huge investment.
In analyzing where and why Scrum teams have failed to get the results desired, I have come to an inescapable conclusion – Scrum works readily in some contexts and not in others. This should not be a surprise. But the second conclusion is more profound – in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in. In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do. These impediments are often not even seen or if they are, are often viewed as “just the way it is.” In fact, I’d go so far as to say certain Scrum attitudes often makes things worse. I’ll explain in a minute – after we look to see what it takes to develop software effectively and efficiently.
To develop software effectively (build the right things) and efficiently (build them the right way) we need to do the following:
- identify the products whose creation or enhancement will make the greatest impact on the bottom line of the company
- Properly 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
- allocate resources properly to these projects
- Create a learning environment so that the process used is continuously improved
Scrum has a challenge dealing with the first four items because it is set up to separate the team from management. Scrum protects the team from interruptions – but these interruptions are often management. Scrum treats its process as a black-box. While using information radiators to show what the team has accomplished, Scrum does little to let management to know how the team works or what impact management decisions have on the team. Ironically, Scrum avoids managers by taking the first line manager and making him part of the team (the Scrum Master). Ironically, the Scrum Master nearly plays the role of what a good, first-line Lean manager would play.
How does Scrum suggest dealing with all of these issues? “Inspect and adapt” (and figure it out) is what I most often hear. There is almost a religious zeal that Scrum tells you little of what to do. Personally, I like building on the knowledge of others. Another challenge in Scrum is its reliance on the Scrum-of-Scrums (SoS) approach for team coordination. While SoS works well for certain types of work, it does not work well when the different teams have different motivations. People tend to identify with their own families first. In business, this is the team people work with. People hold their team as the highest priority and cooperate with other teams when it doesn’t hurt them. This isn’t bad, this is being a human being. People focus first on their own tribe, so to speak. A bigger perspective is needed here if teams are going to act in a more coherent way together.
The Scrum community acknowledges that only 25% of teams adopting Scrum will get the value they hope to get from it. However, they don’t investigate if Scrum itself is the reason for this. In my opinion, the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn’t work well. One needs to pay attention to where to start as well as see how to change the context. Separating the team from management doesn’t help. Focusing on only the team part of the value stream – giving little guidance both up and downstream of the team also doesn’t help. Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights), but this has been rejected by many of the Scrum community’s leaders. See our chapter on The Product Coordination Team for more information on how Lean-Thinking can be use to improve Scrum-of-Scrums.
My own suggestion is to look into using Lean as a context for any improvement in your software development organization. While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development). Scrum’s rapid ascension probably has more to do with its success in the places it easily fits. Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
CEO, Net Objectives
Achieving Enterprise and Team Agility
Note: If you liked this, you may want to read Why Scrum Works and How This Tells Us When It Won’t