What’s the problem with “What’s the problem with Scrum?”

I’m not a salesman for, or even much of an enthusiast for Scrum, and yet I keep finding myself in the position of defending it (or appearing to do so). A survey was posted a few weeks ago entitled “What’s the Problem with Scrum, and How can we Fix it?” (capitalization theirs). They’ve published the results, and so here I am again, appearing to defend Scrum.

What I’m actually defending is the idea that if we want to criticize a thing, that at least let’s criticize what the thing really is, and not a strawman version of it.

The survey results are here: http://agilelion.com/agile-kanban-cafe/what%E2%80%99s-problem-scrum-and-how-can-we-fix-it.

The definition of Scrum is here: http://scrumguides.org

So, here we go.

Scrum’s Frustrating Parts: Story Points for Estimation = 34%. Respondents cited this as the single most frustrating part of Scrum. There’s just one small problem: It’s not part of Scrum. Click on the link to the Scrum Guide and see for yourself.

Second most frustrating part of Scrum: There are no specialized roles like Architect, PM, BA, Project Manager, etc. This is not frustrating for people who are interested in applying Scrum. It is only frustrating for people who want to continue to work in an Industrial Age manner. Scrum defines three roles, and under the auspices of one of them (Developer), a team can have specialists, if that’s the way the team chooses to self-organize, or if that’s the best the organization is able to do at the moment. The detailed information about the survey results states that Scrum defines “rigid roles.” Quite the opposite, actually. So, this criticism is a non sequitur.

Third most frustrating part of Scrum: The lack of IT technical practices (23%). Ken Schwaber has described Scrum as “a lightweight management wrapper for empirical process control.” In addition, Scrum is designed to support product development generally, not just software development. So, the omission of technical practices is not an error or a “problem.”

We’re expected to use appropriate good practices for developing whatever sort of product we’re developing. If our product happens to be software, then we’re expected to know a thing or two about how to build software. It’s the poor craftsman who blames his tools.

Fourth most frustrating part of Scrum: Planning Poker (21%). This is not part of Scrum. Check the Scrum Guide for yourself. Planning Poker was invented on the spur of the moment by James Grenning to break an impasse between two technical team members who were locked in one of those circular debates folks like us get into from time to time. Somehow, it became a “thing.” Whatever. Another non sequitur.

Fifth most frustrating part of Scrum: The daily standup meeting (16%). There’s no further explanation of this item in the article, so we’re left to guess at what people were thinking about. I’ve seen daily standup meetings that were ineffective and useless, so this criticism is understandable. What’s less understandable is why people don’t change their standups, if they aren’t being served. Looking for a rigid set of rules, maybe? Well, good luck.

Sixth most frustrating part of Scrum: The burn down chart (15%). There’s no further explanation of this item in the article, so we’re left to guess at what people were thinking about. I’ve seen so many variations of problems with burn charts that it’s hard to guess what respondents meant by this, but it’s an understandable sentiment.

What Scrum actually says about this is the following: “Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism.” So, it’s another non sequitur, and another occasion to ask why people don’t take ownership of their own results, and use a different method if they find burn charts don’t help them with forecasting. (Or maybe they didn’t know that’s what the charts were for.)

Seventh place is a tie at 12%. Let’s start with The Scrum Master role. This is definitely a unique feature of Scrum, and it’s almost always misunderstood and/or misapplied. Most organizations staff the role in name only, while continuing to apply Industrial Age management thinking to the whole software development operation. I’ve seen many, many cases of problems with the Scrum Master role, and in 100% of those cases the problem has been that the role was either misunderstood or was not enabled to perform the function the Scrum Guide describes for it.

Also at seventh place is The Backlog Grooming Ceremony. Anyone who pays attention to Scrum knows that the wording of the Scrum Guide was changed as long ago as 2011 from grooming to refinement. The idea is to keep the backlog in good shape incrementally, focusing on near-term items as well as high-risk items at any given time. The wording was also changed from ceremony to event. There is a Sprint Planning event in which some level of backlog refinement occurs, but backlog refinement is an ongoing task of the Scrum Team. As a self-organizing team, they are responsible for determining how best to accomplish this in their context. Those who are looking for rules to follow and a process to blame for their results will be disappointed in Scrum.

Ninth most frustrating part of Scrum: The Product Owner role (11%). This is another unique role of Scrum, and another aspect of Scrum that is often misunderstood and misapplied. Ideally, the Product Owner is not part of the IT organization, but is a business stakeholder; possibly the project sponsor. In reality, this is often not feasible. Some organizations have a group of POs, others assign a proxy PO from within the IT department, and others assume the PM role can pick up the responsibilities the Scrum Guide defines for the PO. There are numerous variations, and a great deal of thrashing around the concept of a PO. Some organizations find a way to deal with it effectively and others don’t.

Tenth most frustrating part of Scrum: The Sprint (10%). Yes, this is definitely frustrating for most organizations. It isn’t “Scrum” as such that’s frustrating, it’s the more general idea of a time-boxed iteration (which Scrum calls a “Sprint,” for some reason). The two salient characteristics of a time-boxed iteration, as opposed to a plain vanilla iteration, are

1. All iterations are the same length; and
2. A production-ready solution increment must be delivered at least by the end of each iteration.

That is what Industrial Age organizations have difficulty with. Their existing processes have been based on role specialization, hand-offs, and after-the-fact reviews and approvals for so many years that it’s all but impossible for them to break free of their own self-imposed constraints. What Scrum does is to make all that crap visible. People don’t like it all up their faces every day. I can’t blame them for that. I can blame them for not doing anything to change it.

The people who did the survey did a good job of collating, categorizing, and summarizing the results. What they didn’t do was give the slightest indication that they understand Scrum.