“This is not true Scrum!!!” – we often hear from people, pointing at omissions and pitfalls of fake Scrum implementations. The list of classically seen Scrum anti-pattern could become pretty exhaustive. Here are some examples of “Dark Scrum” (as Ron Jeffries puts it):
- Multiple people playing the role of Product Owner
- No Scrum Master present or line manager performing the role
- Scrum events are dismissed, in favor of status calls
- PMO or first-line managers driving team dynamics , assign and monitor team work
- Teams are understaffed and miss required skill-set to complete work
- Too many translators-BAs that sit between real customers and development teams (see below)
But not all Scrum anti-patterns are equally obvious. Let’s take a look at three instances of team-sprinting, where (1) Scrum anti-pattern is obvious, (2) Scrum anti-pattern is not obvious, (3) Scrum is done well.
Just before we proceed, let’s recap (paraphrase) what the Scrum Guide says: In Scrum, in every Sprint, a team delivers Potentially Shippable Product Increment (PSPI). This is fundamental for Scrum. In order for this to happen, each team must possess all necessary attributes (skills, knowledge, domain expertise) required to get work fully DONE (potentially shippable). This is what makes Scrum - real Scrum. Many teams that lack the required Scrum attributes still attempt to sprint, however, effectiveness of such “sprint-like activities” is significantly reduced. Not all anti-patterns of Scrum are equally obvious.
Instance 1: Scrum anti-pattern is obvious
- Separate, phase-specific backlogs or
- Single backlog with phase-specific items
- Local optimization by single-skill specialists (e.g. PM, BA, QA, Architect, Developer)
- Hand-overs, toll-gates, “internal contracts”
- Long periods of down-time by specialists, when it is not “their phase” to work
- “Water-scrum” /” Scrum-fall”
- Very weak Definition of Ready & Done
- PSPI – takes many sprints to produce
Instance 2: Scrum anti-pattern is not obvious
- Separate, component-specific backlogs or
- Single backlog with component-specific items
- Local optimization by component specialists (e.g. UI/UX, middle-tier, back-end, web service, architecture)
- Hand-overs, toll-gates, “internal contracts”
- Multiple non-development sprints needed to integrate all components and fix bugs
- Weak Definition of Ready & Done
- PSPI – takes many sprints to produce
Instance 3: Scrum is done well.
- Single, shared, customer-centric backlog
- Single, empowered Product Owner
- Shared ownership of work, no siloes
- Swarming by T-shaped people
- Strong Definition of Ready & Done
- PSPI – every sprint
For organizations and teams that are new to agile and scrum, did not make a required investment in proper training/education, have not made an effort to improve organizational design for better agility and do not have experienced agile coaches, supporting them in their journey, option 2 above, may seem as “OK way to sprint”. But please, beware, that you are not getting a real benefit of true Scrum, when you have so much “Undone” work at the end of each sprint cycle ☹.
Below is a graphic illustration of the three types of sprinting described.
