The One With Two Daily Scrums

11 January 2011

Geoff Watts
Inspect & Adapt

Overview

On my first day coaching a new team they invited me along to their Daily Scrum first thing in the morning. They had been using Scrum for a couple of months and had a great “Scrum room” with glass walls on all sides and a lovely view of the lake. On one wall they had their Sprint Backlog, on another they had the Sprint Burndown and on another they had the outcomes from the last retrospective.
Everybody was there on time and even Annika, the Product Owner, was demonstrating her commitment to the team by being present. There were a few quick greetings before the team members stood in a circle and took turns to update their colleagues on their progress, confirming the view that the Sprint Burndown was indicating their good overall progress towards their Sprint goal. The Daily Scrum didn’t last too long, probably only about 6 or 7 minutes and the team dispersed, preferring to get back to work as things were obviously progressing well.
However, when the team got back to where they worked Stephanie, the ScrumMaster, had a quick look around before getting another printed copy of the Sprint Burndown out of a drawer and the development team held another Daily Scrum. This one was slightly different to the one I had just witnessed and the Sprint Burndown that I was now looking at implied the team were not on track to meet their Sprint goal. When I asked what was going on, Stephanie told me that “this is the real Daily Scrum; that one was just for the Product Owner. She would freak if she saw this Sprint Burndown”!

Analysis

This was both amusing and disturbing although at the time I was just plain shocked. The fact that the team felt the need to put on a charade for the Product Owner was definitely not a good sign about the health of the relationships in the Scrum team. We value transparency and collaboration highly in Scrum so blatantly deceiving the Product Owner is not a good thing. However you could choose to view this as Stephanie doing a great job of shielding the team and allowing them to do what they need to do to meet their Sprint goal.
The first question to ask is why are they doing this? Are they doing this so that the Product Owner isn’t aware of a bad situation, giving the team an opportunity to put things right before she notices? Or are they doing this for a more rational and acceptable reason? In this case, the team were confident that they were on track and things were under control but the Sprint Burndown was not doing them justice. When Annika saw the Sprint Burndown indicating the team was behind schedule her natural instinct was to get more hands-on.
The team had decided to only reflect progress in the Sprint Burndown when a feature was complete rather than how many hours were remaining on the cumulative tasks on the Sprint Backlog, leading to a rather “jagged” Sprint Burndown. They did this as they felt it gave them a greater idea of how much was actually “done”  and what their risks were in this Sprint. This is a common tactic development teams will employ if they are finding that they are getting to the end of a Sprint with a lot of items started but not finished.
The team felt that the Sprint Burndown, as it was previously setup, was not proving very useful to the team in their attempts to self-manage and so, quite rightly, Stephanie encouraged the team to tailor their process to make their tools more useful to them. Funnily enough, the team felt wasting 10 minutes a day by going through the motions of a staged Daily Scrum was allowing them to be more effective than worrying the Product Owner and less painful than having a conversation with Annika to explain the new Sprint Burndown and ease her anxieties. 

Summary

The Sprint Backlog in Scrum is one of the tools available to the team (along with the Daily Scrum) to allow them to effectively manage themselves during a Sprint. It is not, as some people think, a reporting tool for management to check on the progress of the team on a daily basis. Therefore if the tool was not helping them, it should be changed and that is a sign of both a healthy development team and a functional ScrumMaster.
However, the fact that the team and Stephanie chose not to discuss this with the Product Owner is worrying. The ScrumMaster has a responsibility to protect the team and allow them to be productive as they focus on achieving their Sprint goal in the best way they can so if the Product Owner is distracting the team or putting them under unnecessary pressure or focus then the ScrumMaster should try and reduce this. However, the ScrumMaster also has a responsibility to foster relationships between the Product Owner and the development team such that transparency is promoted, there is a feeling of ‘one team’ and trust is built up. By deceiving the Product Owner, Stephanie runs the risk of driving a wedge between Annika and the rest of the Scrum team, decreasing the trust she has in the team and the process.
On reflection, Stephanie felt that she took the easy option rather than deal with the real problem by talking to Annika openly about the situation. She also said that she would have rather taken the whole team further down the path of discovery rather than settle for this as a solution. 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

John Gunnarsson, CSM, 1/24/2011 11:06:25 AM
This was hard to read, the font was so small!
It was a nice "How not to" :-)
Geoff Watts, CST,CSC,CSP,CSM,CSPO,REP, 1/25/2011 1:32:16 AM
I agree John. It's a shame the website doesn't allow me to edit the article to change the font size. Sorry about that and glad you managed to read it and enjoy it.
Damian Torrez, CSM, 2/8/2011 5:27:11 PM
Geoff, very informative. The political jockeying that goes on within a company can cause development teams some real trouble. We found in our company that one of the reasons for our failure to meet sprint objectives was the "untasked" items. All the little favors, and the fires that needed immediate attention. At first we attempted to ban these outright but eventually learned that in our company this isn't possible. We must attend to the daily distractions since we are such a small group of developers. So our solution was to add custom task of "Interrupt" and use this to track how many hours are spent on non-planned items. Which we can now schedule and plan for these since they averages about ~%15 - %20 of our time. Once we did this, management eased up on 2 things. first they realized how often they needed favors, and two, they were given a real world view of how much work we could accomplish during each sprint.
Geoff Watts, CST,CSC,CSP,CSM,CSPO,REP, 2/9/2011 1:09:35 AM
Hi Damian

That sounds like a good way of making things visible so that they can be properly addressed to improve the overall process within the organisation. Nice one!

Geoff

You must Login or Signup to comment.