The Real Problem with Scrum

May 7, 2010

Since I’ve spent a few posts refuting Kai Gilb’s issues with Scrum, I thought that I would take a stab at articulating the real problem with Scrum. Most of what Kai has complained about Scrum to date doesn't look like a problem with Scrum to me at all.

The lightweight nature of Scrum makes it broadly applicable, but since it is new to many organizations, experience and true understanding is lacking. The implementation of the deceptively simple framework of Scrum can trip you up.

As Scrum adoption increases, we’ll hear more about Scrum failures. It will fail to improve the delivery of software projects, costing organizations significant time and effort to adopt a new approach only to end up (at best) where they were before they started using Scrum.

Today, many of the problems that organizations experience with Scrum are that they have a ScrumBut problem. The “We’re doing Scrum, but…”
  • We don’t have a product owner.
  • We don’t have a product backlog.
  • We don’t bother with daily standup meetings.
  • We’re not doing ... some fundamental activity that is and should be a part of the Scrum process.
As Jurgen Appelo noted in a recent blog post, Some Day Kanban Will Fail 75% of the Time, that there are those who state that “at least 75 percent of Scrum implementations fail.” Jurgen makes the excellent point that this failure rate includes those who are “doing Scrum, but...”

I call this a basic blocking and tackling problem. Despite the fact that Scrum is a lightweight framework that is not complex, teams and organizations skimp on implementing the basic mechanics.

The Scrum community is doing a great job of highlighting the ScrumBut problem, and I feel that organizations will get the message that they should implement the entire Scrum framework if they expect success with Scrum. The next big issue will be that a great many organizations won’t realize any significant gains from the experience.

Sure, the workers will enjoy their jobs more because they have more control over their workday, but there will be one BIG question lurking, and it is the same one we ask ourselves at my company; “Are we producing better software, faster?” And while having a happier workforce is a victory, can you – and should you – ask for more?

Yes. Because this is where real, meaningful change takes place. It is also where the true value of Scrum is realized.

Scrum is not just another process to create software. The standard activities of requirements management, software design, software construction, and testing should NOT be handled as sequential activities. The key to raising productivity and aligning development with the business using Scrum is to establish true collaboration.

Shared knowledge, shared understanding, and constant, high-bandwidth communication should improve productivity and align the development team with the business. For example, there should not be a situation where the team reviews a User Story and then the developers go off to design and build something while QA writes a detailed test plan and waits for development to provide that feature in a build, with no customer (or proxy) involvement. That is a operating sequentially, using Scrum as a “mini-waterfall” process.

Instead, teams should review the User Story together with the product owner, who represents the business (unless an actual customer is involved as a part of a customer team). Furthermore, this should be a vertical, testable slice of functionality delivered, and not a horizontal, “data access layer” (or some other tier). There should be constant communication, shared design, pair programming, and talking about issues or questions that arise.

In the end, there is a certain flow and rhythm that is established with truly collaborative teams that is virtually impossible for a sequential process to beat. This is more difficult to achieve than it appears, but the potential exists. For many organizations, this autonomous, collaborative approach is also a very different work model, and the correct, successful adoption of Scrum is hampered because there is little available in terms of ScrumHow manuals to guide implementations.

If you were to ask me – based on what I know and have researched to date – for a good, single source of information that talks about Scrum from someone highly experienced with the common pitfalls and challenges, I would pick Mike Cohn’s book Succeeding with Agile: Software Development Using Scrum.

I recently read this book and I really appreciated the depth of Mike’s experience, and I found the information that he presented both uncannily accurate and very useful. I feel that it is one of the best ScrumHow manuals available today, going well beyond the basic blocking and tackling of Scrum.

A second book on Agile development that focuses greater attention on the technical practices along with giving you another great perspective of Agile development is The Art of Agile Development by Shane Warden and James Shore.

The wealth of information contained in these two books is extraordinary, and well worth your time to read if you are heading down the Agile/Scrum path.