Ask anyone in the sales department what Scrum is, and apart from mentioning the colorful, sticky-note-decorated task board, they will more than likely mention the daily scrum, also known as the team stand-up.
The daily scrum is the regular pulse of the team. A pulse needs to be steady, consistent, and lively to remain healthy, and this article gives you a few tips to help ensure that these sessions keep humming along like clockwork.
When and Where?
First things first: I highly recommend that the daily scrum be conducted as a stand-up rather than a sit-down. It is a subtle yet important distinction. The simple act of standing provides the team with a sense of liveliness to help kick-start the day, and it also ensures that the session stays short and sharp to prevent aching legs!
I am not a believer in imposing the time of the daily scrum on the team: the time should be decided as a group. However, you should encourage everyone to commit to a time that works for them that is as early as possible in the day. Of course, if your team is disparately located, then your daily scrum will need to accommodate the various time zones.
Once there is an agreed-upon time, you can start to reinforce some guidelines. Here are three that I am a fan of:
- The daily scrum should start on the dot irrespective of who is late.
- Anyone who is late without either prior warning, a super excuse, or an extremely funny excuse (that induces laughter from every team member) needs to make a financial contribution to the late jar (this can go toward an agreed-upon charity).
- Your daily scrum should look like a nice tight circle (or semicircle around the task board) rather than an amorphous blob (see Figure 1).
Figure 1 – Your daily scrum should look like a nice tight circle (or semicircle) instead of an amorphous blob
What Should Be Covered?
The typical questions that each developer answers during the daily scrum are
- What did I achieve yesterday?
- What do I hope to achieve today?
- Do I have any impediments or blocks?
Although these questions seem straightforward, I have a few specific tips to make your daily scrums more effective. First, everyone should reference the tasks on the task board when discussing what they achieved and what they hope to achieve. This way, you ensure that the task board is up to date (if anyone forgot the night before).
In reality, it should take each team member only about 30 seconds to run through the three questions. However, the problem is that at least a couple of updates every day will typically spawn spinoff discussions that can drag the entire team into a black hole of debate (until everyone realizes that their legs are aching after standing for half an hour!). It is very easy for a daily scrum to get hijacked by implementation detail, so I highly recommend that whenever you get a whiff of tangential discussion, jump in and say “offline,” or if you want to be more subtle, slowly start raising your hand. What you are communicating with this prompt is the following: “I know that this is an important discussion, but let’s get through all of the updates, and then at the end, anyone who is required to participate in the discussion can hang back.”
GIFTS
Agile consultant and blogger Jason Yip explains the key purpose of the stand-up using an apt acronym, GIFTS, which I like as a simple mnemonic:
Good Start
Good Start means that the stand-up meeting should give energy, not take it. Energy comes from instilling a sense of purpose and urgency.
Improvement
We can’t fix problems we don’t know about so a large part of stand-ups is about exposing problems to allow us to improve. Improvement is not just about problem solving though. Sharing better techniques and ideas is also important.
Focus
The stand-up should encourage a focus on moving work through the system in order to achieve our objectives, not encourage pointless activity.
Team
Effective teams are built by regularly communicating, working, and helping each other. This is also strongly tied with team members helping each other with shared obstacles.
Status
Status is about answering a couple questions:
- How is the work progressing?
- Is there anything else interesting that the team should know?
Multiple Teams
Your project may include multiple parallel Scrum teams that share common interfaces (both technical and communicative). A popular option in this situation is to run a scrum of scrums stand-up (an additional stand-up with a representative from each team). This is a good option, but I personally prefer the use of stand-up ambassadors who act as observers in the other groups to pick up on any potential contention and/or lessons (see Figure 2). This way, there are fewer potential breakpoints in the communication channel. These ambassadors are typically the most senior developers in each of the groups. If you adopt this approach, it is important to stagger the kick-off times of each team’s daily scrum so that ambassadors can attend.
Figure 2 – Stagger the kick-off times for each team’s daily scrum so that ambassadors can attend.
Ignore the ScrumMaster
I like the way Ken Schwaber (in his book Agile Project Management with Scrum) puts it when he states that the daily scrum is supposed to be an opportunity for the group to briefly “socialize and synchronize.” It is not a roll call or micromanagement session where the team reports into the ScrumMaster and/or product owner. I often find that some team members get into the habit of directing their update to the ScrumMaster only. If you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling — I have found that the habit is quickly broken with this physical cue.
Some Extra Touches
I recommend that before the daily scrum formalities begin, encourage (but don’t contrive) any light banter and joking around — it’s always nice to start the day on a positive note feeling energized instead of feeling like you’re at a military roll call!
I also like to use the daily scrum as the forum for awarding the infamous broken build punishment. The team can really flex their creative muscles when collectively determining their approach to this (see Figure 3). Some suggestions include anything from the relatively innocuous monitor that flashes the culprit’s name to the more extreme practice of placing a moldy loaf of bread on the transgressor’s monitor (as Clinton Keith writes in his book Agile Game Development with Scrum – this was much easier prior to flatscreens! My longstanding preference sits somewhere in the middle of this spectrum whereby the culpable party is awarded the Akubra (Australian cowboy hat) to wear for the rest of the day (including to lunch!).
Figure 3 – Broken build “punishments” can range from innocuous to extreme.
While the daily scrum can certainly flow in a stock-standard direction, I like to keep everyone on their toes by utilizing some sort of randomizer. For example, you can use a small soccer ball that gets passed around from team member to team member in any order; anyone who isn’t listening (or is a terrible soccer player) will get a little embarrassed as the ball slips through his or her legs.
It’s Hitting the Big Time!
I see a bright future for the daily scrum. Along with the task board, it is a popular Scrum element that I’m already seeing cross the chasm into non-software-related teams to great effect; even the mainstream Wall Street Journal has reported on its growing popularity!
The daily scrum is a simple concept, but without care it can quickly turn into a daily mess! So, try out some of these mess-mitigating tips, and never forget Conway’s law:
“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.”Melvin Conway – How Do Committees Invent?
If you liked this article, you can:
Find out more about stand-ups by taking one of our CSM training courses.
[…] seinen Artikel zu Outstanding Stand-Ups habe ich das großartige Blog von Ilan aus Australien gefunden. Sehr pragmatische und trotzdem […]
Danke for the German translation Christian and glad you’re enjoying the blog!
Nothing says “you broke the build” like our life-sized cardboard Justin Bieber. Our rules are slightly different.
Break it once: Justin lives in your cube for the sprint.
Break it twice: Justin lives on your desk for the sprint.
Break it three times: Justin spends an entire day going to every meeting and lunch with you.
LMHO – cruel and unusual punishment however I don’t doubt its efficacy!
Thanks for the ‘late jar’ tip – I just introduced the late jar (Kai is kicking himself for showing me your blog hehe).
When someone goes off on a tangent during the stand up, anyone can simply shout out “bing!” and it is taken offline, that seems to work well.
The multiple team handling I wasn’t too clear on, could you elaborate on that part? Do you send someone from your team to attend/observe another team’s standup?
We have multiple teams (eg. frontend team, services team, database team) and each team runs its stand ups at 1000. Each team lead then attends a “Big Stand Up” at 1015 and essentially gives a summary of their team’s stand up. This is advantageous because I get to hear what is happening in teams that I don’t interface with (because maybe i should be), but has two disadvantages compared to the chicken method – I don’t hear the details of their stand ups, and if I never want to or need to interface with them then I’m probably wasting my time at the Big Stand up listening to them.
In terms of the nightly build/continuous integration build: some teams have setup speakers and a computer that shouts out (loudly) the names of the people who have checked in code related to the broken build. Its not fun hearing your name broadcast over the office PA, but it is when its not you!
Glad you are enjoying the blog Nick and nice work on the late jar 😉
I totally love your internal PA system – classic!
Yep, regarding the multiple team situation, we accomplish the ‘ambassador’ approach by staggering the times of the daily stand-up. That being said, there is nothing wrong with your method if you don’t mind not being able to attend them all in person and relying on the team lead to report the relevant info.
Epic!