Monday, April 15, 2013

Decoupling the individual from the problem

During the Daily Scrum meeting, it is very common to ask each person in the team the following questions:
  1. What did you do yesterday?
  2. What will you do today?
  3. What is blocking progress?
This is standard procedure, as taught by Scrum trainers and Wikipedia. The first question gives the developer the possibility to shine a bit and get rewarded for being productive. The second question is used for putting focus on progressing further. The third question offers the developer to ask for help if something is getting out of hand.

But one team I worked with discovered that there are severe drawbacks with asking these questions.

To begin with, everyone wants to look good. So it was quite common for people to put up a handful of new notes on the board, explaining why they were important and then cashing in the reward by moving some of them to done. This took focus away from the existing notes so it was sometimes hard to detect if something did not progress as we visioned it earlier.

Secondly, people don't like giving promises that are not likely to hold. "So the work I plan for today is a few meetings, doing some critical support and maybe getting some work done on this story". It was useless.

Thirdly, and most importantly, it is really hard to ask for help. How do you know if something is really blocking or just being awry? And why do I have to ask for help every other morning when others seem to cope with their work just fine? Further, when someone asked for help, the rest of the team had already begun working on their stories in their heads and were not too willing to help out (courtesy of question 2).

One sprint, we tried talking about stories instead of people:
  1. What work was done on this story yesterday?
  2. What work will be done on this story today?
  3. What is blocking progress on this story?
This made some dramatic change to how we worked as a team; it became natural to be two or more developers working on each story.

The first question still had the reward built into it, but without adding unplanned work items as we did earlier. The second question was answered more objective and realistic.

Finding impediments in the third question came to be a Q&A session on how the story could progress. Ideas were bounced and people offered themselves to help out.

Pair programming became normal procedure and with that the common understanding of how we developed software (aka. coding guidelines) became more widespread and agreed-upon.

To summarize, this was a game changer for us. All the benefits from the original questions were still there, but decoupling the individual from the problem enabled us to speak freely.

1 comment: