Scrum: As It Plays Out
(chapter under extensive revision)
Patterns, Anti-patterns, Tips & Tricks
In recent years the Scrum community: teams attempting Scrum, coaches and consultants have come across a few situations time and again. Many patterns and anti-patterns have emerged as organisations try to follow Scrum. So common is the dysfunctional manner in which Scrum is implemented, that we now have two types of Scrum: Scrum and Scrum-but.
Scrum is what has been detailed in this book and other standard sources; Scrum-but is where people say “we do Scrum, but we don’t …..”.
- Make working software available every sprint
- Fix the date of the delivery
- Do a stand up every day …. etc
Scrum is often circumvented for sake of convenience but brings only short term benefit, if at all. Project groups must realise that retreating into the familiar comfort zone, only means performance at current levels. The key is to understand that Scrum mainly surfaces problems, and only solving these problems will bring real lasting improvement. The key is to make a distinction between problems caused by Scrum and problems surfaced by Scrum.
The two most common underlying reasons for failing to realise the benefits of Scrum are:
- The team not being free to choose how much of the product backlog they can commit to in any given sprint.
- Failure to keep to the “NO CHANGE RULE”
So overall advice is don’t change Scrum, but change the way you work. Particularly stick to the “NO CHANGE RULE” as well as choose a good “Definition of Done” and maintain it. Visibility and transparency will provide huge and sustained benefits over the longer term.
What are the kinds of projects where Scrum is unsuitable?
- Research projects
- Pure customer support kind of projects ( completely event driven and no prior planning is possible)
- Projects which are so small, that a couple of people finish it in about a week or so
- Any other kind of work that cannot benefit from use of Scrum(We have explained the principles of Scrum as well as why and how Scrum works. After understanding all of this, if in your judgment you think that Scrum is unsuitable for your kind of work, don't use it ).
Even so having a practice of daily stand-ups and monthly retrospectives done well, can certainly benefit the project, as this is a case of ‘inspect and adapt‘. So from this perspective any or all activity can be done under Scrum.
What do we do if in a SPM no one has a clue on how much to commit, or how to break down backlog items (user stories) into a list of tasks.
This commonly happens during the first sprint for the team. The Scrum Master and managers present must resist the temptation to do the planning for the team. As mentioned in the Sprint Planning Section, the first step of capacity planning is straight forward. Next instead of the team focusing on how much to commit, it should be encouraged to work out how to do the first product backlog item. They need to list all the items required to take this item from description to implementation. We recommend a list of about 10 tasks. Then they can estimate how long each of these tasks might take. The recommended range of an acceptable task is between 2 hrs to 12 hrs. Any task that requires more time, should be given more thought and broken down into smaller tasks. If a tasks takes only an hour it can be included into another task, unless forgetting it will create real problems, in which case it can be explicitly stated (eg: Code check-in activity). A totalling of time required for all these tasks (with an added buffer of about 20%) will indicate to the team how much more (or less) they can do. Sometimes it helps for the managers to leave the room and even the Scrum Master giving the message to the team that they have to work out together the Sprint goal and plan. The Scrum Master can announce that he/she is at hand to help if the team wants. A worry for many managers is that the team is inherently incapable of planning. It is worth noting that the team is planning only a few items, for a limited duration of time (one sprint) and also collectively has the advantage of an intimate knowledge of themselves. We have all collectively planned a trip for a few days with friends without the help of a project manager, which usually unfolded pleasantly enough.
How not to use Scrum
We have come across multiple instances where teams say they do Scrum and then go ahead and plan their release by having a requirements sprint, a design sprint and an implementation sprint, a testing sprint and a release sprint. This is exactly what Scrum tries not to do. The aim of Scrum is to have a fully coded, tested and completely “DONE” and potentially shippable product increment at the end of each and every Sprint, not at the end of 6th sprint or 7th sprint. If we don’t do this, we may as well follow Waterfall model.