Your Daily Stand-Ups are Not Working
Of all the (agile, scrum or any other) process studios have implemented across the globe, the one element that seems to be the easiest and most sticky is the Daily Stand-Up (often called the Morning Meeting unfortunately). But the majority of Morning Stand-Ups I’ve been part of are at best not providing the outcomes they are designed to provide or at worst just an interruption and waste of your developers time.
The Scrum style stand-up is probably one of the most well know and is often the format taken, regardless of whether Scrum is being used or not. With that in mind, here’s a brief description of the Daily Scrum from the official Scrum Guide.
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronise activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
And that’s pretty much how people approach it. In other words, they do the how, but what about the why?
Again from the official Scrum Guide.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
I’ve highlighted the key reasons for the daily stand up.
Are the stand ups you’re running providing all those elements? Are they providing any of them?Have a look around during your next stand up, and see what your developers are doing
- Is everyone looking at the same person, usually the project lead, when talking
- Do you have to call everyone to the meeting rather than self-organising
- Are people looking at their feet, looking around, or otherwise unengaged
- After the meeting are people still asking questions about what people are doing
So how can you improve your stand ups?
One thing I’ve seen a lot of people do it try to add some kind of randomness into the process. Usually in regards to who goes next e.g. who’s just spoken decides who speaks next or having a toy thrown at the next person for them to catch before speaking.
This improves one thing — remembering who’s spoken. But the participants are so engaged in keeping track of who’s spoken so they look like they’re paying attention, they’re actually not focusing on the content being discussed.
So what can you actually do to improve your stand ups?
Make them consistent Make sure the meetings are called at the same time, in the same place, every single day. If they are called at different times, often dependant on certain people being present it will never become a self-organising collection of developers. By making them consistent, groups will arrive at the meeting every day, even if key members are not present. And by making the stand-ups self organising, you are making the participants much more engaged with the process which will increases the quality of the meetings.
Improve what people are saying The key points of the meeting are to identify work done, being done and any impediments — the point is not to go into minute details about your day. If you have people who are ‘over-sharing’, discuss it with them, make it clear the amount of detail needed. If it continues, time box them — though don’t time box too much, it’s the quality of the information you’re looking to change, not a specific amount of it.
Cut down on people I dislike ‘Scrum of Scrums’. To me, it’s a bad solution (information is silo’d to stand-up leads) to a serious problem but to many people in your stand-up means to much information and a lack of engagement. If this is the case (and I’d say anything over 5 is to large for a stand-up) then try a take on the Scrum of Scrums. Have feature or groups stand-up before the main stand-up (which by definition will be significantly smaller) and then in the main stand-up, only the representation of that feature group needs to contribute (but all are still present). The information will be at a higher level, but everyone is still present unlike the Scrum of Scrums approach.
Break Out Additional Meetings Kill additional discussions in the stand-up quickly, stating that these should break out into meetings after the stand-up if they’re needed. If you don’t kill them quickly, the meeting can quickly descend into minute detail, killing engagement and alienating the majority of participants. If you do it enough times, people will soon realise that further discussion needs to be done later, and this will start to happen automatically, drastically cutting down on the length of the stand-up.
Don’t Have a Lead Developers should be talking to developers, not the project lead, it’s not a report meeting, it’s an information sharing stand-up. If the participants are ‘reporting’ to one specific member, then remove that member (or yourself) for a while. Don’t turn up to the meeting, be ‘busy’ for a little while, but just stay out of the way until people realise that key member isn’t the only one who can get anything out of the meeting.
These points are just a few practical ways in which you can drastically improve the quality of your stand-ups, bringing them back to the why of the process as well as the how.
Originally published at managing-game-dev.com on March 25, 2015.
