While you might be abiding to the two basic rules above, this does not necessarily mean these meetings are beneficial. All too often the mechanism of this meeting is implemented without much regard to the underlying concepts that support it. Here are some tips and ideas around Daily Scrums I have gathered over the years I think help you get the most out of them:
The Daily Scrum is for the Team
This meeting is not for reporting to the Scrum Master or anyone else for that matter. While anyone (including Chickens if they behave) can attend, the team members are reporting to each other. Sometimes just the mere presence of a VP or other manager causes the team to feel like they are giving a status update to this person. This often results in the chicken feeling the same way and emboldens them to ask clarifying questions or start directing the meeting. It may be as subtle as them moving it along by asking the next person to start, but it can quickly turn the orientation of the meeting. I see this most often if the Scrum Master cannot be present and an attending chicken thinks someone needs to be "in charge".To prevent this (and its hard to do when you report to these chickens in some way) try a few of these suggestions:
- Remind everyone that only the scrum team and the Scrum Master are allowed to talk during this meeting. After everyone has given their updates, then questions and clarifications can be asked but everyone else can leave.
- If possible, position the team in an “inner circle” and have chickens behind them outside of the circle. It is a subtle physical reminder of who the meeting is intended for.
- I also think that even chickens need to be standing, but a good argument for not making them stand is to have another physical reminder.
- Even with the Scrum Master present, the team should take charge in starting and moving the meeting along. When the Scrum Master does this, it can still make it feel like you are reporting to them and if the Scrum Master is also a member of management it makes it even harder to break the habit.
Use a Task Board
All too often with Scrum teams that do not use a task board for their Daily Scrums you here things like “I finished the widget class yesterday” and depending on how integrated the team is some of us may have no idea what the widget class is exactly and the fact that is it done does not give us any kind of clear picture of the progress for the User Story it belongs to. This is even less clear when you use a Agile management tool and people report things like “I finished task 24533 yesterday". If you are not intimately involved in that particular story you have no real reference to determine how it is progressing.By using a story board you can get an idea of how a story is progressing even if you do not have any knowledge about it. By merely seeing the flow of tasks in their various states you can determine how much of it is done.
It is also easier to identify issues with stories with a task board. If someone has been reporting on the same 6 hour task for 3 days it becomes very clear there is an issue. Is there an impediment keeping them from finishing this task? Was the task originally scoped too small? Is this joker some kind of slacker? Even when people do not know they are in trouble the task board can identify the issue and them team can act appropriately.
(Note: I am planning a follow up blog post just about task boards later with more details.)
Another practice that deviates from the normal Daily Scrum rules is “walking the board”. Instead of asking the 3 questions, the team walks through each story on the backlog and says what tasks were done for each one, what is going to be started, and any impediments for that story. I was not a big fan of this at first when a client started doing it, but I think in some cases it works really well. If you do try this be careful that everyone on the team is participating since your attention is to the story and not the individual members.
Use Information Radiators
Per Alistair Cockburn an information radiator is something that show valuable project metrics that can be gained to a casual observer with a glance. This would include items like:- Sprint Burndown Chart – A graph showing the hours remaining from the Sprint Backlog for each day of the sprint. Good for monitoring how the flow of the tasks is going.
- Story Burndown Chart – Similar to the sprint burndown but instead of showing remaining hours per day it shows unfinished stories.
- Task Board – The task board itself is a good indication of how the project is doing per story.
- Build Status – Whether you use something like Brian the Build Bunny or simply track builds passing and failing on a graph, this can alert you to problems with code quality.
No comments:
Post a Comment