Common Failure Modes in Scrum
Learn the common reasons for failure when using Scrum.
We'll cover the following...
- Ineffective Product Owner
- Insufficient product backlog refinement
- Stories too large
- Daily scrums not held daily
- Overly long sprints
- Emphasis on horizontal slices rather than vertical slices
- Separate development teams and test teams
- Unclear Definition of Done
- Not driving to a releasable level of quality each sprint
- Retrospectives not held
- Lessons from retrospectives not implemented in the next sprint
- “Scrum and”
- Ineffective Scrum Master
- What the Scrum failure modes have in common
My company has seen many more ineffective Scrum implementations than effective ones. Most ineffective implementations are “Scrum-but,” meaning, “We’re doing Scrum, but we aren’t using some of its key practices.” Examples include, “We’re doing Scrum, but we aren’t doing daily standups.” Or “We’re doing Scrum, but we aren’t holding retrospectives.” Or “We’re doing Scrum, but we haven’t been able to fill the Product Owner role.” Ineffective Scrum implementations have usually removed at least one essential attribute of Scrum. Here’s my favorite example: “We looked at Scrum but found that most of the practices wouldn’t work in our organization. We’re doing Scrum, but the main practice we use is daily standups, and we do those on Fridays.”
Unlike the enormous umbrella of Agile practices generally, Scrum is a minimal process for managing workflow. Because it is already minimal, there really isn’t any part of Scrum that you can remove and still achieve the benefits of Scrum.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
—Antoine de Saint-Exupery
If your organization has adopted Scrum and you aren’t realizing significant benefits, the first question to ask is, “Have you really adopted Scrum, or have you adopted only parts of Scrum?”
An advanced Scrum implementation might eventually remove specific parts of Scrum by applying Inspect and Adapt to their Scrum process with rigor. But that is an advanced activity, not a beginner activity. Beginners will do better if they adopt Scrum by the book.
The following sections describe the most common challenges we see with Scrum implementations.
Ineffective Product Owner
For decades before Agile development existed, the most commonly reported source of project challenges and failures was poor requirements. It should not be a surprise that post-Agile, the most problematic role on Scrum projects is the one that’s responsible for requirements.
Problems with Product Owners take several forms:
-
No Product Owner—the role is expected to be filled by individuals on the Scrum team.
-
The PO is spread too thin—the Scrum team is starved for requirements. A PO can support 1–2 teams, rarely more than that.
-
The PO doesn’t adequately understand the business— this results in low-quality requirements being fed to the Scrum team or requirements that are prioritized poorly.
-
The PO does not understand how to specify software requirements—this is another way that low-quality requirements are fed to the Scrum team.
-
The PO doesn’t understand the Development team’s technical challenges—and does not ...