April 27th, 2011
Half way through the Sprint the team are having their Daily Scrum. The team take it in turns to share with their colleagues what progress they have made and what they plan to work on today. There are a couple of impediments that get added to the Sprint Backlog and Ashley, the ScrumMaster promises to pick up – one with an external vendor who is not supplying the input file in the correct format, and another with Operations who still haven’t provided a correctly configured staging environment.
The team glance at the Sprint Burndown which shows they are roughly on track and the team are about to leave the Scrum room when Ashley asks a vital question:
“Are we actually OK here? I feel worried but you guys seem fine with how things are going”.
The team respond that they all have things to work on and the Burndown proves that things are going well. Still Ashley isn’t convinced and asks the team about the Sprint Backlog (represented as a taskboard) that shows every task in the “in progress” column. Nothing is waiting to be worked on and nothing has been completed.
The Sprint Backlog, Sprint Burndown and Daily Scrum are all tools for the development team to manage themselves towards their Sprint goal and the collective commitment they made at the Sprint Planning Meeting. The team should be using these tools to inspect and adapt, on a daily basis, their plan for the Sprint and regularly asking themselves whether they are OK and what needs to be done now.
The taskboard and Burndown are also referred to as information radiators, making it very visible to everyone how the Sprint is progressing; a quick and easy way to see where we are against plan and outstanding work remaining.The Sprint Burndown in Scrum is deliberately simple – two lines – the ideal burn rate of the work committed to spread evenly over the total number of days in the Sprint compared to the actual amount of work remaining at any point within the Sprint. It is deliberately simple as it is expected that the team supplement the visible information with a conversation and collaboration to “fill in the gaps”.
Unfortunately, because of the simplicity of the Sprint Burndown it can sometimes be misleading and so the conversation and contextualisation becomes more important. Ashley sensed something wasn’t quite right despite the Burndown indicating otherwise. The team were comfortable because they all had something on which they were making progress and the Burndown showed they still had enough time available in the Sprint to do the outstanding work. The problem was in the fact that every task was in the “in progress” column of the Sprint task board.This indicates that at some point every task had been started but stopped – either because something else became urgent within the Sprint or, more likely, they hit an impediment meaning they couldn’t take it any further.
In order for them to carry on making progress and, at the same time, appear busy they took another task from the Sprint Backlog and worked on that one. This team now had about 20 items that were blocked by impediments and nothing was “done”. This is a massive risk to the Sprint; there is a great chance that, come the end of the Sprint, none of the features from the Product Backlog would be complete. They may have enough time remaining to do the outstanding work but that isn’t factoring in the time needed to remove the impediments.
While Ashley felt he needed to do something he wasn’t sure how to handle this with the team. Should he remind the team of their responsibility to get things done early and regularly within a Sprint? Should he let the team get on with it?In this case, Ashley decided to try and find out why the team were moving from task to task when they hit an impediment. They were of the belief that it was Ashley’s job as ScrumMaster to get impediments removed – which is (strictly) true – and that they couldn’t just sit around waiting for an impediment to be removed when there were other things they could be getting on with. What did Ashley expect them to do? Just stop work until they could finish the one task they were working on? That wouldn’t be very efficient and would probably end up with them getting sacked!
Ashley asked them whether they thought it was realistic to expect him to be able to remove all of these impediments in time for them to meet their Sprint goal and he was met with a laugh. They obviously didn’t think it was possible but they were starting on new work items nonetheless. Being busy was more important to them than getting things “done”. Ashley asked them how the team thought Carlo, the Product Owner, would react at the end of the Sprint if none of the features were delivered because of impediments but every member of the team had been busy all the way through the Sprint. “Hmmm…” was the answer that came back along with a lot of looking at the floor.
Ashley felt uncomfortable here because how the team manage themselves during the Sprint is ultimately up to the team but equally, the team also have a responsibility to help deliver as much value as they can. From a Product Owner’s perspective having 6 features partially done is nowhere near as valuable as having one feature actually “done”. Ultimately by digging into the underlying behaviours Ashley found that culturally the team felt under pressure to be seen to be “busy” all the time. This is often a highly dysfunctional behaviour leading to poor results and increased project risk.
It would be more valuable to the Product Owner and the business for the team to swarm around one of the features, collectively remove the impediments and get it done even though they might not all look busy.While I am not recommending teams “downing tools” when they hit impediments, sometimes by explicitly making it very clear that a team is unable to make valuable progress it can create enough political desire within the organisation to remove the impediments. A “stop the line” mentality, as practiced in Toyota, can be highly valuable in making clear what a teams true velocity is and, ultimately, providing the necessary impetus to enable them to improve it by fixing problems quickly.
Sometimes, as a ScrumMaster, you need to make things uncomfortably transparent in order to fix the root cause of a problem. In this case Ashley needed to make it clear to the team that it was more important for them to get an item done than to be busy all of the time. In order for the team to accept this, he will need to make it visible to management how this helps the bottom line. Sometimes in order to make things visible, somewhat drastic steps need to be taken but also remember what a wise man once told me:
“A dead ScrumMaster is a useless ScrumMaster”.
Also, just because removing impediments is primarily the responsibility of the ScrumMaster, the team should see an impediment as something to be tackled collaboratively. They shouldn’t just be passing this problem on to the ScrumMaster.
0 comments | add comment|