The Problem with Scrum

I feel that I should post a short note to explain my personally weak enthusiasm for Scrum as an Agile methodology. I think I’d be happy working on a team that used Scrum well, but I’ve seen too many team adopt Scrum practices without being at all Agile. When that happens, the problems can be even harder to solve. It’s very hard to tell a Scrum Master that they don’t know how to do Scum.

Years ago, the training sessions that first introduced me to Agile methodologies happened to present Scrum. The PMs were enthusiastic! They were quite familiar with how much programming would get accomplished in the final press towards a release. Imagine: by having a release every few weeks, we could maintain a continual, unrelenting death march of development!

The Good

The practice of Scrum comes with a clearly defined set of rituals that can really help the team change their interactions with the business. For well-functioning teams, getting business buy-in may seems as natural as breathing. However, I once worked with a team that spent nearly a year building an application; when they went to deliver it, it turns out that the customer didn’t know about the project and didn’t want the application. (Per my suggestion, that team got intense training in Agile Scum shortly after that. And also new management). Although that is an extreme example, because of the sometimes long development lead times, it is not unusual for a traditionally-planned (or “waterfall” oriented) team to lose contact with the changing needs of the business. The rituals of Scum do protect against that drift.

The Scrum practice of “sprints” organically solves several problems:

  • They force check-ins with the business on a regular cadence
  • They implicitly keep “user stories” from getting too large
  • They protect the development team from a business that is constantly changing their mind

For teams that have essentially lost contact with their customers, these practices can naturally reverse that decay.

The Context

Of necessity, teams that are following traditional, Waterfall planning practices are being driven by their PMs. The PMs are organizing the steps and making the schedules to deliver a finished release.

Teams don’t change their development practice methods unless they see a chance to avoid something negative, like loss of business confidence, or gain something positive, like increased efficiency. For a team losing business confidence, adopting the Agile rituals provide a great way for a team to noisily demonstrate a team planning transformation to a “best practices” approach.

PMs that were previously in control of team deliverables may find that part of their role diminished in an Agile environment. Many PMs will resist this.

The Bad

Unfortunately, Scrum rituals can easily be adopted by the PMs in charge to continue managing the team via traditional project planning. The project plan might now have a consistent sprint cadence, but the PM who owns the team can still plan all the steps to a release (calling it an “Epic”).

Significantly, Scrum practices and terminology provide a lot of assistance to the PM who wants to continue waterfall planning their new sprint-based calendar:

  • “Commitments”, which are made at the beginning of the sprint, sound like something that the team commits to delivering by the end of the sprint. Actually, they aren’t. Any team that consistently delivers all of their “commitments” is doing something very wrong! Sometimes the teams should not get everything done because they over-estimated; occasionally the team should take on more work because they got everything done early.
  • “Burndown charts” illustrate the team’s intra-sprint progress toward meeting their “commitments”. This strongly helps underline the implicit goal of accomplishing all of those tasks during the sprint. Not meeting the “commitments” or taking on additional work will mess up the “ideal trend” of the Burndown chart. As a measure of team health, this is worthless.
  • “Failed sprints” are what PMs commonly call sprints that didn’t meet their forecast objectives. The Scrum folks describe a “failed sprint” as a sprint where the team didn’t learn anything about now to make the process better. However, the only times I’ve heard reference to a “failed sprint” was in terms of meeting “commitments”.
  • “Sprint review” meetings are held at the end of each sprint to present a demo of the completed work to the product owner or stakeholders. The ambitious PM, with “commitments” in hand, can even invite stakeholders to the review meeting in advance, with a full agenda of stories to be demoed. Furthermore, this nurtures the idea that this meeting is for owner approval of the sprint’s work. This is another misunderstanding that Scum facilitates. Implicitly, this causes teams to delay releases until this end-of-sprint approval is obtained from the product owner. Efficient teams will release as soon as the work is ready, hopefully multiple times during a sprint. Queuing releases until the sprint review meeting simply delays the delivery of business value.

So let me say this clearly again: a team’s sprint “commitments” are really estimates that the team should be spending almost no time into making accurate. All the time spent on these estimate is “waste”, in a formal Lean sense. Because a sprint planning is simply a bundle of educated guesses, a team that consistently meets their “commitments” is either defying statistical probability or over-planning.

I recommend that all Scum teams immediately stop calling these guesses “commitments” and start calling them “prioritized stuff most of which we hope to get to during this sprint”. And when things do get done, should be deployed as soon as possible to maximize the business benefit.

Don’t get me wrong, Epics, Commitments, Sprints, Burndown charts, and sprint review meetings are all used by very effective, Agile teams. My concern is that Scrum rituals and terminology makes it far too easy for traditionally planned, waterfall teams to adopt Scum practices without becoming Agile. The Scrum terminology doesn’t clarify (and, indeed, actively obfuscates, in my opinion) the real purpose of some of these rituals, so that the over-planning PM can continue to rule the team by continuing to over-plan team sprints.

Redeeming Scrum

In most cases, the implicit goal of implementing a substantially new development process is to improve the efficiency of the team. Adopting Scrum rituals without implementing Lean principles is unlikely to help this.

There are two ways in which a development process helps teams become more efficient:

  • Teams are more efficient because what they deliver is closely aligned with what the business needs, right now
  • Teams are more efficient because they spend more of their time actually building new stuff (rather than planning, testing, waiting, deploying, or fixing stuff)

Scrum often does a good job at aligning the team with the business priorities. Does it make a development team more efficient at delivering functionality? It certainly can, but teams that are already inefficient are very likely to be able to fully adopt Scrum without any improvement to their overall delivery cadence. For dysfunctional teams, adopting Scrum may be a good first step, but the next step is unlearning what they think they’ve learned in the course of adopting Scrum.