The Soggy Scrum Test

Scrum Implementation is hard, which is why many studios take bits and pieces of SCRUM and apply it to their current waterfall structure. Unfortunately, this is usually why SCRUM fails (dun dun DUN!). Below is a checklist of Scrum Soggiers. The more items on this list that occur in your studio, the soggier your SCRUM is.

Standups

No Daily Standups take place at all
Infrequent standups - The studio doesn’t ‘need’ 1 standup a day. Instead, twice a week is fine
Staff appear bored in daily standups
Scrum members talk to the guy/girl making them do the scrum, instead of the team
People aren’t actually standing up
People are notoriously late to the standup
People don’t do the standup if the scrum master ( or producer/guy/girl who is making them do scrum) is not there

The Team

Team members only tend to see each other at standups
Team members do not seek help when stuck
People don’t know what their tasks are
People don’t know why they are doing their tasks, and how this affects the project
Tasks do not get updated (in progress, finished, hours remaining)
Members of the team do not have any tasks marked as ‘in progress’ (in Hansoft/pm tool, or the task board)
There is hardly ever any noise in the office
People do not discuss solutions to other staff member task problems (inside the team, and outside the team)

The Production

There is no Burndown chart for each scrum team
The words ‘ad-hoc’ are used frequently - no performance data is available for previous tasks
Unfinished tasks roll over to the next sprint without re-prioritisation
Sprints vary in length (ie, sometimes 2 weeks, sometimes 3 weeks, sometimes 1 week)
Sprints don’t start on the same day (ie, Mondays)
Sprints don’t end on the same day (ie, Fridays)
There is no Planning meeting for each scrum team
The team does not commit to tasks in the sprint planning meeting
There is no communication between the scrum team and the product owner
The Sprint is not based on the product backlog priorities
There is no Sprint Review
There is no Sprint Retrospective
In the sprint review, the team does not talk about the product, and suggest ways to improve it
In the retrospective, the team does not talk about team challenges and successes from the last sprint
There is no discussion in retrospectives and reviews (ie, No disagreement ever)