The Daily Scrum/Stand-up Meeting

TL;DR

A good stand-up is always about the team. A team which shows ownership, respects each other and works with an agreed structure will do great.

For many years, I have been part of teams that follow the agile methodology and practises some kind of scrum. One of the key practices in agile scrum is the Daily Stand-up or Scrum meeting. The DSM is done in different ways, and it is really up to the team to do what works best for them. That said, there are certain characteristics which are important to maintain, irrespective of the team which is following DSM. I explain these characteristics as I understand them and see fit.

A typical Daily Scrum Meeting

DSM Virtual Meeting

A Virtual DSM: Photo by Chris Montgomery on Unsplash

It is 11:30am in the morning. Every one from the "Delta" team has assembled in the virtual meeting room. Out of 13 member team (11 developers, 1 product owner and 1 engineering manager), only a few of them had turned on the video. Some kind of construction noise is heard in the background. Ram, the manager opens the scrum dashboard and filters the cards for Hasina, a team member.

"Ok Hasina, can you please share your update"

"Sure Ram. Yesterday, I was working on these items but got stuck on some testing issues. Ram, what is the priority of this task?"

"Hasina, this needs to be delivered by the end of this week. So we need to plan accordingly"

"Got it Ram. What about this other requirement? Should I pick that as well now or later?"

"Let us do that later."

"Ok Ram. Other than that, I was able to close out this story NZ-202. I will be picking up new story today from the TODO lane"

"Thanks Hasina. Can anybody who is not talking turn off their mikes? There is too much noise... Gagan, can you share your updates."

Hasina turns off her video. Also, the background noise dies down.

"Ok Ram. I am facing some kind of strong migration issue."

"Can you give some context on this Gagan?"

"Oh sure Ram. Yesterday, I was working on the status check API story and was trying to do the DB model changes. That is when I faced the problem."

"Can you explain the details of the issue?"

"So when I try to deploy the migration script locally.... blah... blah... blah... "

Vikas, a developer joins the call.

"Have you tried to close the console and start a new session" chimed in Winston

"That did not help" said Gagan.

"What about trying to restart the laptop?" Winston countered.

"Come on, that is not a solution buddy!"

Vidya starts fidgeting with her keychain as this happens. Shanti (the Product Manager) lets out a muffled yawn.

"There is an option in the library to turn off specific test cases. You could use that Gagan" said Abdul.

"Thanks Abdul. I will try that out"

"Can you continue with the update, Gagan" said Ram.

"Sure Ram. So I will continue working on this issue today and I will try to close it out by EOD today"

"Thanks Gagan. Vidya, can you give an update"

"Sure Ram. Let me see.... What was I working on?... Yeah, I worked on the validation story... no that was day before... sorry. Yes I worked on the transformation story yesterday... blah... blah... blah... ...

This goes on for 40 minutes and at 12:10 pm, Ram asks Shanti

"Do you have any product updates for the team Shanti?"

"Nothing from me Ram."

"Great. Have a good day folks!"

This is a typical Daily Stand-up or Scrum meeting I observe in my world. I am sure many of you have experienced something similar. I want to dissect this example, but first I want to give you some historical context on Stand-ups and Daily Scrum meetings.

Origins

The daily stand-up originated from the annals of Extreme Programming (XP). Kent Beck made this methodology famous through his book by the same name (almost). The daily stand-up was just one of the practices/rules in Extreme Programming (dig more here). Our focus is only the daily stand-up.

Let me add some quotes from the source

A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each.

During a stand up meeting developers report at least three things; what was accomplished yesterday, what will be attempted today, and what problems are causing delays. The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length

... Source

I think this is a good description for us to work with.

Let us move to the Daily Scrum meeting which comes from the Scrum methodology. Again, I am going to the source:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

... Source

Though these two processes have different origins, you can surely notice similarities. I will list the ones which strike me:

  • They happen on a daily basis, preferably in the morning.
  • One of their main purpose is to eliminate other meetings.
  • They are expected to be short (you can potentially stand through them).
  • They are owned by Developers, allowing them to manage themselves as a team.
  • You talk about progress made and impediments faced/facing in both cases.
  • Goal is to work on a plan and improve focus and self-management.

There could be more, but these stand out to me. Using these sources as the main reference (I will include other ideas if required), let us dissect the example DSM (of the Delta team) which I described before. I am treating the name stand-up (XP) and daily scrum meeting (DSM) as synonyms. If you see one, I mean either.

Before you look at my thoughts below, spend sometime dissecting the Delta stand-up and share the same in comments below.

The "Delta Team" DSM biopsy

Doing a biopsy on the Delta team DSM

Disecting the Delta DSM - image by Ri Butov from Pixabay

The "Good Parts"

There are good things happening in the Delta team stand-up.

  1. The stand-up happens at a regular daily cadence.
  2. Developers have the ability to bring up their impediments and get solutions to move things forward.
  3. There is free-flowing conversation happening between developers.
  4. There is an explicit section for the PM to chime in and add thoughts. This is not prescribed in any of the original guides, but I like this idea as long as it is kept short.
  5. They are using the common scrum dashboard to drive the meeting. This allows people to get on the same page quickly, and they have the reference to dive deeper if required.
  6. Some people are turning on video for the call and that is good thing. More about this on the other sections.

I have not elaborated the above good parts because I think they are self-evident. Let us get into some not so good parts now.

The time

The Delta team stand-up starts at 11:30 am. I am not sure if that can be called morning. That is closer to the afternoon. There could be legitimate reasons for this - people working in different time zones. Also in today's world of flexible work timings this is probably unavoidable.

Having said that, if you ask me, I would prefer the stand-up to start much earlier - sometime around 9:30 am. My reason is that the stand-up is supposed to help you create an action plan for the day (this is not really planning but to get clarity). It is better to have this clarity earlier in the day, so that team members know where they have to focus on.

Other aspect of time is the duration. 40-45 minutes of stand-up time is very high. The reason why extreme programming suggests the stand-up should be done standing up is to keep it short (it is actually not necessary for people to stand up as long as the duration is kept in mind). Similarly, the scrum guide also suggests that the DSM should be 15 minutes long.

In my experience, when a team gets together for the stand-up discussion, there are times when it needs a little more time (than 15 minutes). But not always. A steady 45-minute stand-up is a smell (like a code smell) to be addressed. We will look at some remedies soon after the biopsy.

The ownership

Carefully observe (means read again if required) the DSM conducted by the Delta team, and tell me who is the owner of the meeting. I feel that the meeting is owned by Ram who is actually a manager. In scrum terms, we could probably treat him as the Scrum master.

Ram governs the flow of the conversation. Everyone is talking to him in the stand-up. This is really wrong. A practice like this converts the daily stand-up meeting into a status meeting. Once this happens, the team is just answerable to the manager. Self-management, team spirit and team ownership go out of the window. People will not enjoy going to these meetings since they are afraid that the manager will judge them. Real impediments may not get discussed. This is a very bad situation and needs remediation. The Delta team may not be in this situation yet, but they are in-route.

Another thing that adds to this issue is that the Delta team is fairly large. A 13 member team can be pretty crowded and intimidating especially for junior developers and new joinees. This is only a passing mention. Its implication & solution is beyond the scope of this article.

The rambling

The Delta team stand-up is very ad-hoc in my opinion. Everybody seems to be talking all the time. There is no structure to the conversation. The Extreme Programming stand-up actually prescribes a structure to the conversation. The Scrum DSM is little more flexible but has essentially advocated similar kind of information to be shared - Work progress, Impediments, Plan for today etc.

In the Delta team stand-up, Gagan starts his conversation with mentioning an impediment. Ram draws out the context and eventually multiple others (Winston and Abdul) jump in to try to suggest a solution and this drags on leading to others getting restless. The availability of help is a good thing, but the lack of structure leads to rambling and others tuning out of it. This kind of rambling conversation is also why the stand-up stretches out for such a long time. This also leads to people tuning out of the conversation.

Another source of rambling is the lack of preparation of the team members when they come to the stand-up. Vidya keeps stumbling to figure out what she needs to talk about. This again leads to wastage of time. It also sends a wrong message that there is no respect for people's time. Bad!

What Goal?

Another thing missing in the DSM is the absence of discussion or tracking to check team's progress towards their Sprint goal. Typically, teams look at a burn-down chart to figure out where they are with respect to what they planned for the sprint.

Scope discussions should be related to already defined goals and if they need to be altered. In the Delta team, the priorities seem to be unclear and getting figured out in the stand-up. While this is better than not getting clarity, the ideal place for this is the Sprint planning meeting.

Rude?

I am not saying that the Delta team folks are talking rudely to each other or behaving badly. But there are some subtle things to look at.

Right at the beginning of the meeting, there was noise coming in to the stand-up meeting. Only after Ram called it out, the relevant person muted their audio to stop the disturbance. While this is not outright rude, it just tells that the team members are insensitive to others. Also, this might be a one off and if so, we could ignore it. But if this happens regularly then it means that the team is not following basic etiquette.

Another similar incident in the Delta stand-up is Vikas joining late. This again sets up a bad precedence for the entire team. I am not talking about being late by a few seconds or a minute.

In my opinion, it is better to send an offline update to the team rather than joining the stand-up after minutes of its starting.

Remedial Ideas

Now that the biopsy and diagnosis is complete, it is time for some remedial actions.

Remedies for a better DSM for Delta team

Remedies for improving the DSM - image by Angelo Rosa from Pixabay

Transfer Ownership to team

The first thing I want to address is the aspect of ownership. While other aspects are important, this one is critical. There are a couple of things that Ram (the scrum master) can do to change the situation:

  1. Ask everyone to explicitly address the team instead of addressing him (the manager/ the scrum master). This might seem silly, but doing this sends a signal. The mindset created is that as a developer, "I am responsible to the whole team. We as a team own this".

  2. There is need for someone to govern the flow of the conversation. So get developers to take turns (round-robin) at playing that role. I have successfully tried this with my teams and found that it helps. Doing this helps to reinforce the feeling that we are a team and are responsible for each other. This technique also helps groom team members to act like owners and help in governance. As a side benefit, the shy developers get a chance to express themselves in a safe environment.

  3. A key thing to note is that ownership & accountability comes only if one has a say on how things go. This means that Ram shouldn't be dictating all the decisions of any process (including stand-up). The members of the team must have a say, and they need to feel heard. Decisions have to be taken jointly. While this might be more time-consuming, decisions taken this way stick better.

Once these are done, ownership is no longer with Ram but with the entire team. Team is empowered to own its destiny, Ram (the manager) is just a guide in the process. This drives ownership back into the team.

Create a structure

The second key thing to address is the rambling. We do this by providing some structure to the stand-up discussion. The team can do a couple of things:

  1. Make every member to stick to a common structure of providing the updates. The team could adopt the XP style or a variation of it as decided by the team. It is the job of the team as a whole (or the current week coordinator/scrum master - not the Manager) to ensure that the team members follows the structure when they provide updates.

  2. When a developer is stuck and needs help or discussion then they can announce a "Post Stand-up" discussion that is needed after stand-up. Some of you might have heard this term before; I will explain it down the line.

  3. Ensure that we look at where we are with respect to the Spring goal. Discuss progress using burn-down charts etc. to ensure that everyone understands where we are and where we are going.

How a Post Stand-up works?

As part of stand-up, I mention that I worked on a particular task/story yesterday and I plan to either continue on it or pick another one today. I might have an impediment for which I need help or want a discussion to clear out some ideas. For doing this I state that I need a "Post Stand-up" discussion after everyone goes through their own updates. The stand-up is complete once updates and sprint progress discussions are complete. For the Post stand-up discussion, relevant & interested people can stay and others can drop off. This saves time for many developers who are not connected to the discussion. Also, the post stand-up allows the stand-up discussion to be more focused, structured and short. Since only relevant people need to be present, the post stand-up discussion itself could become more focused.

There can be a concern that if we create post stand-ups then the team could lose out on learnings that might come from knowing about the impediments & solutions. This is a valid concern, but post stand-ups don't eliminate participation. It only makes it a choice for the person which respects their time and pressures. In my experience, I have found that this works well for teams.

Again, remember that the Post Stand-up is a good broad idea. You can use it, tweak it and make it your own.

I also want to emphasize that we need the stand-up to be a place where developers can have free-flowing and open conversations. The structure is only to help the developers, but if that structure becomes a problem then we obviously need to change things up. As I said earlier, this should be done as a team.

Once you have a structure and start having post stand-ups, the duration of stand-up will come down (provided some of the below etiquette are followed). You can (and should) measure it so that we know how we are doing. I have done this with one of my sprint teams (after discussing with the team of course) and it helped us to look for ways to fine-tune the stand-up process. Measurement is almost always a good thing.

Good etiquette

It always pays to be well-mannered and nice to each other. It also helps to be prepared. The following list of things are simple rules which ideally developers / team members should follow. The scrum master / manager should also nudge the members when required:

  1. Always join the stand-up on time. Punctuality is a good thing.
  2. Mute yourselves when you are not talking. Actively listen though
  3. Prepare for the stand-up before it starts and not when another team member is giving their updates (you need to listen at that time). This will just take 2 minutes.
  4. Show yourselves - be on video. This helps you and the team in many ways.

Conclusion/Closing thought

Tweaking things to make it work for you is very much in the spirit of agile. We still need to ensure that the fundamental philosophies are not compromised by our innovative techniques.

This ends my own observations/learnings of one of the key processes in today's agile development world. What are you thoughts? Do you agree? Or do you think this is all b*l***t? Your comments are welcome below.

References

Aum sarvam SriKrishnarpanam astu

Comments

comments powered by Disqus