A recent poster to scrumdevelopment writes “I find it challenging to get my team to articulate impediments [...] what types of questions do other scrummasters ask that help to get at these impediments?” [href="http://groups.yahoo.com/group/scrumdevelopment/message/39331"] [ref]
I don’t think it is about asking questions. I think it is about creating an environment of visibility and honesty. Task boards help us do that, but task boards alone won’t achieve it. Sometimes we need a whack to the side of the head.
The biggest impediment I have discovered to identifying impediments is the practice of measuring tasks in hours, and having team members update those hours at each meeting. People look at me askance when I make that suggestion. It doesn’t seem to make sense. But it does.
Some years ago, I took over as ScrumMaster for a team that had been doing Scrum “by the book” (their words). All of them hated the standup meetings, and especially the updating of hours. They felt they were being measured at a micro-level, that they should just be trusted to do the work and that it was insulting and a waste of time to be doing this. Well, being someone much more inclined to trust gut-feel than metrics I was happy to accommodate this request. The term “Scrumbut” didn’t exist back then.
We agreed that no hours would be put on tasks on the condition that all tasks were considered small enough to be completed in a single day. This is very important. What we discovered with this process change is that when tasks were not done in one day it was an indication of an impediment that no-one had thought to mention, or even acknowledged as an impediment. Now some of these impediments” are very tiny, such as “we thought the task was easier” so the solution is to break the task into smaller pieces, and commit to a smaller task for the next day, but other times it is indicative of a bigger problem.
For example, the team were falling behind, and one developer had a task sit in the in-progress column for three days. After one day he said it was almost done and just a bit bigger than he’d thought. We marked it with a red spot (this red-spot marking gives an immediate visual indication of the blocked tasks). After two days he said he didn’t have time to complete it. That raised some eyebrows. Why not? It turned out that this particular developer was frequently being called away to fix bugs in another property. This had nothing to do with the project he was on, and had not been discussed in the planning meeting. No one on the team had viewed this as an impediment because “that’s just the way we do things round here”. As ScrumMaster it became my job to change that.
This issue would not have come to the surface nearly so fast if we did not have the “one-day task” rule. The process of measuring things at a micro level, with the intent of creating visibility, actually serves to hide important information.
I recall another team I worked with (using an electronic tool to track) where the developers would knock hours off all the tasks they were working on, even if they knew they hadn’t done much work on them. They were all keen to see the burndown burn down, and didn’t feel safe saying the size of the task was the same or bigger. By the end of the sprint almost all tasks had about one hour remaining. Very few were done. No stories were done. This convinced me of the need for binary measurement. A task is either done or not done. A task with one hour remaining is not done.
Having this team stop measuring partially done work and measure only completed things (tasks and stories) helped them to create an environment of honesty and trust, and helped them to better understand what they could realistically commit to. It also allowed the impediments that were preventing them completing tasks to be surfaced much quicker (usually 24 hours)
Since 2005 I have discouraged all teams I work with to measure and track in hours. Using the “one-day task” rule will very quickly surface impediments and dysfunction. It will also free up your developers to actually focus on the work, and off the numbers.
Scrum requires a massive shift in thinking and behaving. Getting rid of the notion that measuring in hours is somehow necessary and helpful will be a great leap towards your Agile edge.
Related post: [href="http://agilethinking.net/blog/2007/05/21/estimation-time-or-size/"] [Estimation: Time or Size?]