Scrum: Daily Stand-Up
Has your Daily Scrum become a bit boring? Is everybody just sending, but not listening? Has the interaction been lost? Then it’s time to spice up your stand-up!
It wasn’t this awful in my team, but during one of our Sprint Retrospective we discussed our Daily Scrums. The interaction was a little bit lost. One of the Agile principles is: Individuals and interactions over processes and tools. The pitfall of the Daily is that it can feel like a mandatory part of the process instead of an opportunity to exchange information and help each other. A part of that mandatory feeling is answering the three questions: What did I do since the last Daily? What am I going to do until the next Daily? Do I encounter any impediments?
In a previous team it even felt like reporting that you actually worked. Off course we kept the Daily and the three questions. But we changed the format to make it more dynamic. Every team member used to answer the questions for him or her in turn. Now we put more focus on the Sprint progress and the progress of completing Story’s and deploying releases. We did this by addressing each lane on the Scrum Board separately. On each lane there is either a Story, the current release, or non-blocking bugs on the bugs lane and some independent tasks on the support lane. We created the bugs and support lanes to keep things transparent, even if team members were working outside the Story’s we’ve got in a Sprint. Also the deployments of the release to Acceptance and Production needs some work of the team. Therefore we created a separate lane for it as well. By addressing each lane separately we keep focus on progress on the completion of the work of every lane. Now every team member answers the three questions in regard to the lane. For example: What did I do since the last Daily for this Story? What am I going to do until the next Daily for this Story? Do I encounter any impediments while working on this Story? The answers also include: When do I expect to be done with a particular work item? Such that another team member can review it. Or it can be tested. Or somebody else can use it for another work item. This works especially well if back-end and front-end work is done by specialized developers. This improved interaction between team members (individuals) to tune their work to each other. At our next Sprint Retrospective we evaluated this change. Everybody was really positive about the extra interaction it brought. Besides that the focus on completion led to a more steady burn-down. We kept it ever since.