The One With Two Daily Scrums
January 11, 2011 in Experiences
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”!
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.
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.