Scrum By Example – Cascade’s Team Discover Scrummerfall

Cascade’s team is struggling, three sprints running they’ve been unable to build a potentially shippable product. The developers complain there isn’t enough time in a two week sprint to get their work done. They want three-week sprints. The testers complain that they only get something to test in the last three days of sprint, and even then it’s usually too buggy to work with. Cascade calls her old friend Steve who seems to be having more success with Scrum.

Steve does some digging and finds the following data about (expressed in Story Points). The team had committed to 41 points of Stories sized: 5, 8, 13, 5, 8, 2

NB: Scroll to see full table. In several cases a single story is both in (Analysis and Development) or (Development and Test) at the same time.

From here Steve chats with Cascade to find out how the work flowed. She explains that on Tuesday the four developers grabbed the first three stories (5, 8, 13) and just disappeared for a few days. During Friday’s Daily Scrum, one of them said that he realized the ‘2’ was closely related to something he was already working on and he grabbed it too. Towards the end of the sprint the developers started throwing code over the wall to the testers saying “they will figure it out”. Furthermore, when the testers find problems they insist on logging all the details in the bug tracking system, instead of just talking to the developers first. In addition, when Testers find a bug, the developers often put up a fight rather than collaborate to fix it.

Analysis

There are a number of possible causes that lead to this state:

• Large stories – lead to everything getting finished later.
• Individual work – leads to a lot of work being started and little being finished. Notice on Wednesday that four developers started three stories. That seems to suggest that there is very little collaboration going on.
• With so much Work in Progress, everything is started and nothing is finished.
• The Developer/Tester divide is alive and well.
• Use of the bug tracking system in sprint is further enlarging the Developer/Tester divide.

Story

Steve suggests to Cascade that they go out for coffee (a ScrumMaster’s secret weapon). He explains that it seems her team has a very serious case of ScrummerFall or Waterfall practiced inside Scrum. He goes on to show that by starting most the Sprint’s work at the start, they’re very unlikely to get everything done. Instead, what they’ve done is guarantee the first bottleneck. He suggests that the first thing they do is learn to start slicing their stories into smaller, more digestible, chunks. Cascade is confused and wonders about the loss of efficiency. Steve tries to explain that a focus on efficiency often leads to slower overall throughput, but this doesn’t make sense to her.

In the end Steve proposes she gather together the team and they play the penny game (Ed: the version I do just times the overall process and not the individual workers). After playing the game and running the debrief, they make the rather surprising discovery that the smaller they slice things, the faster value gets to the customer and better their overall throughput. Cascade sets up meeting to start splitting some of their upcoming stories.

Analysis

In addition to Splitting Stories the team could:

• Pair Programming – to get each individual story done sooner
• Test Partially Complete Work – instead of waiting until all the work is complete
• Skip the Bug Tracking System – in Sprint most bugs can be handled with a quick conversation instead of the time consuming use of a tracking system
• Focus on the Early Discovery of Bugs
• Discover Acceptance Test Driven Development (ATDD) and Specification By Example so that they work collaboratively to discover the acceptance criteria. In addition they can write the tests before they write the code.

Inspired by frequent questions on the subject of “What percentage of time should I allocate for Analysis, Development and Test in a Sprint”.

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.