Scrum can be great (or terrible) for teams

I have something of a love-hate relationship with Scrum. Let’s break that down …

Great Scrum

Scrum that helps:

  1. Scrum can act as a container in which a loose work-group can develop into a collaborative, high-performing team.
  2. 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.
  3. Scrum can help a team to focus on a main goal and prioritise effectively.
  4. Scrum can act as a container for continuous improvement.
  5. Scrum can help a team flip from scope-boxing to time-boxing.
  6. Scrum can act as a thin project management layer that wraps around technical practices.
  7. Scrum can be adopted incrementally and be adapted to fit your context.
  8. Scrum can reduce the number of meetings by folding most of them into the standard events: planning, daily scrum, review, retrospective, and refinement.
  9. Scrum can help a team remain customer and stakeholder focussed through once-a-sprint reviews and re-planning.
  10. Scrum can help a team to keep up a sustainable pace, by learning to estimate and slice up work to fit inside the sprint.
  11. Scrum can help reduce stress and perfectionism by encouraging iteration on work items.
  12. Scrum can help foster self-organisation and collaborative leadership by sharing responsibility and accountability.
  13. 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:

  1. 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.
  2. Unmodified Scrum works poorly when there are many significant streams of work, rather than one main focus.
  3. Unmodified Scrum works poorly when most pieces of work have external dependencies making it difficult to finish a piece within a sprint.
  4. Scrum can fall down when the group is highly specialised, with little interest or motivation in cross-skilling.
  5. Scrum can increase the amount of meetings that team-members must attend, when the Scrum events are added to rather than replace existing meetings.
  6. Scrum retrospectives can devolve into whinging sessions, when there is a lack of deeper investigation and subsequent adaptation.
  7. Scrum becomes excessively rigid when the Scrum Guide is taken at face value and all components of Scrum are treated as mandatory.
  8. Scrum can be misused as an excuse for lack of discipline when Inspect and Adapt is used as an excuse to do “whatever”.
  9. Scrum can be misused as an excuse for why “Agile doesn’t work here” because it was a poor choice to start with.
  10. 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.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.