I have something of a love-hate relationship with Scrum. Let’s break that down …
Great Scrum
Scrum that helps:
- Scrum can act as a container in which a loose work-group can develop into a collaborative, high-performing team.
- Scrum can scaffold rapid learning and delivery cycles via the cadence of the daily scrum and the longer cadence of one to four week sprints.
- Scrum can help a team to focus on a main goal and prioritise effectively.
- Scrum can act as a container for continuous improvement.
- Scrum can help a team flip from scope-boxing to time-boxing.
- Scrum can act as a thin project management layer that wraps around technical practices.
- Scrum can be adopted incrementally and be adapted to fit your context.
- Scrum can reduce the number of meetings by folding most of them into the standard events: planning, daily scrum, review, retrospective, and refinement.
- Scrum can help a team remain customer and stakeholder focussed through once-a-sprint reviews and re-planning.
- Scrum can help a team to keep up a sustainable pace, by learning to estimate and slice up work to fit inside the sprint.
- Scrum can help reduce stress and perfectionism by encouraging iteration on work items.
- Scrum can help foster self-organisation and collaborative leadership by sharing responsibility and accountability.
- Scrum can give wonderful, actionable insights to help teams and organisations when used as a silver mirror, rather than as a silver bullet.
Terrible Scrum
Scrum that hurts:
- Scrum can be misused/abused as a whip to beat the team, forcing them to commit to too much work each and every sprint. Or worse, an increasing amount of work, by mandating an ever-increasing velocity.
- Unmodified Scrum works poorly when there are many significant streams of work, rather than one main focus.
- Unmodified Scrum works poorly when most pieces of work have external dependencies making it difficult to finish a piece within a sprint.
- Scrum can fall down when the group is highly specialised, with little interest or motivation in cross-skilling.
- Scrum can increase the amount of meetings that team-members must attend, when the Scrum events are added to rather than replace existing meetings.
- Scrum retrospectives can devolve into whinging sessions, when there is a lack of deeper investigation and subsequent adaptation.
- Scrum becomes excessively rigid when the Scrum Guide is taken at face value and all components of Scrum are treated as mandatory.
- Scrum can be misused as an excuse for lack of discipline when Inspect and Adapt is used as an excuse to do “whatever”.
- Scrum can be misused as an excuse for why “Agile doesn’t work here” because it was a poor choice to start with.
- Scrum can be rejected prematurely when it fails to magically fix everything immediately.
When working with a group I like to start by assessing their context, needs, and pains — and building some rapport. Depending on what I diagnose I’ll most often recommend starting with either vanilla Scrum or minimal Kanban. Over time we’ll make changes and incorporate other relevant practices to co-create a fit-for-purpose Agile approach.
Great comments and further discussion on LinkedIn.
