Author: Véronique Skelsey & Mike Collins, Liqueo Ways of Working Agile Coaches

In this article, we are looking at how you can make your Daily Stand Up deliver more. Stand-Ups and the Daily Scrum are often used as interchangeable terminology, but in fact, there are subtle differences. 

Stand-Ups vs the Daily Scrum 

• The Scrum Guide 2020 describes the Daily Scrum as a “15-minute event for the Developers of the Scrum Team… to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work”. 
• The daily Stand-Up originated in Extreme Programming (XP) and is an adaptation of the Daily Scrum, without the guidelines and restrictions of the Scrum Guide. 

Both events are simply a check-in with the whole team: to see how things are progressing, to confirm if anyone needs any help, and to make adjustments if necessary. They’re a useful point of interaction for any team, whichever framework they’re using (Scrum, Kanban, XP etc.) or even for teams working totally outside of development. 

To keep this framework-agnostic, this article uses the term ‘Stand-Up’ except where referring specifically to Scrum.

Who should be involved?

Until 2011, the Scrum Guide used the Pigs and Chickens metaphor to differentiate between who should speak in the Daily Scrum and those who do not speak but could attend.

A Pig and a Chicken are walking down the road.
The Chicken says: “Hey Pig, I was thinking we should open a restaurant!”
Pig replies: “Hm, maybe, what would we call it?”
The Chicken responds: “How about ‘Ham-N-Eggs’?”
The Pig thinks for a moment and says: “No thanks, I’d be committed. You’d only be involved.”

The idea was that only the Development team should speak at the Daily Scrum. The Scrum Master would often facilitate, and the Product Owner and any interested stakeholders would be limited to observing.

Many people found that this created an unnecessary divide between the team and the Product Owner. Thinking on this has evolved over time. The Scrum Guide 2020 outlines specific accountabilities for the Developers, the Scrum Master and the Product Owner but explicitly states: “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint”.

As the person ultimately accountable for the value of the product, the Product Owner is as invested in the success of the product, if not more so, than the Development team. Often, they also have useful information to contribute or can make prioritisation decisions based on the latest information surfacing from the Daily Scrum or Stand-Up.

It is critical to remember that the Stand-Up is neither a status meeting nor an enquiry into the productivity of the team members. It’s an opportunity to collaborate and to embrace collective responsibility towards delivery. The Scrum Guide 2020 describes it as a means to “improve communications, identify impediments, [and] promote quick decision-making”.

An Iteration/Sprint Review, NOT the Stand-Up, is the primary place for business and management stakeholders to inspect and adapt (i.e. feed back) on the increment of the product, and review progress towards business goals. The Stand-Up is used by the team to decide how to get things done and is NOT about reporting to management.

N.B. Some teams may “Review” with stakeholders throughout an iteration (Sprint) rather than wait until the end. But these “mini-Reviews” shouldn’t get mixed up with the team’s Stand-Up, which has a different purpose.

Who should ‘run’ the Stand-Up?

Traditionally, a Scrum Master may have facilitated the Daily Scrum. However, it’s a great idea to share responsibility for the Stand-Up and rotate facilitation regularly between team members. This means everyone has a good understanding and experience of what’s involved. It also means it never feels as though one person is in charge or ‘telling’ the rest of the team what they should work on.

How should it be run?

Whichever format you use, it’s useful, when visualising your workflow using a Scrum or Kanban board, to use the board as a reminder of what work was agreed and what has happened with it.

Standing Up is a technique to ensure, first and foremost, that the meeting is kept short and to maintain engagement and energy levels. With more teams being increasingly geographically dispersed, this has become more challenging, yet there is still a lot of merit in experimenting with this where practical.

It’s also a good idea to ask each team member to spend one or two minutes BEFORE the Stand-Up, jotting down anything they have done since the last session that will be of interest to the team. This can considerably shorten the meeting and make sure that it is focused on what is important and relevant.

It’s important to keep the meeting short and focused. Always postpone any detailed discussions until after the Stand-Up. These post Stand-Up discussions should only include the relevant people. This keeps Stand-Ups productive for everyone.

The 3 Questions

Most people are familiar with the Yesterday, Today, Impediments model of Stand-Ups. The team takes it in turn to tackle the three questions:

• What did I do yesterday (that helped the team meet the Sprint Goal)?
• What will I do today (to help the team meet the Sprint Goal)?
• Do I see any impediment (that prevents me or the team from meeting the Sprint Goal)?

Unfortunately, this can quickly become mindless and mechanical. Instead of listening, people think about their contribution while waiting for their turn and then stop listening altogether once they’ve said their piece. It then ceases to be an aid to collaboration or impediment resolution and becomes a status update for the Product Owner and stakeholders.

If your team has got into this rut, it’s time to change the format.

Walk The Board

One alternative to the 3 questions is, to “Walk the Board”. This technique helps the team focus on delivery and the progress being made, and promotes a “stop starting, start finishing” mindset, helping them to limit Work In Progress (WIP). As we all know, being busy and being productive can be very different things. If you’re working on a thousand different tasks, you’ll finish none of them. 

To Walk the Board, start at top right of your team’s board (the column nearest to Done in example image given below) and talk through what needs to happen to get it over the line to Done. This helps identify any problems or impediments. Then work down each column, from top to bottom, right to left until there is nothing left to discuss. The final step is to check if anyone is looking for work. Assign any work from the top of the backlog (in order of highest priority).

The reason for going through the board in this order is that items on the right are:

• Closest to being live
• Closest to providing value
• Closest to showing Net Present Value (Where Income now is more valuable than income later)

By focusing first on those items that are almost complete and doing everything you can to finish them before picking up new work, you can deliver more value, faster. 

The Daily Demo

Another alternative to the 3 Questions is the Daily Demo. It is only really recommended for more mature Agile teams who are very disciplined and attentive to their iteration goals and WIP limits. It involves always keeping the board up-to-date, and using it as a reference point in sessions but the board is NOT the focus. Instead, each team member (including non-developers) quickly shares what they have done so far. Where possible, a quick visual demonstration allows everyone to see the emerging solution and any progress. No amount of talking can replace seeing actual working software!

Tip: Do make sure demos can be done quickly in the Stand-Up. Prepare beforehand but keep things simple. This will avoid wasting several minutes trying to get things working!

As mentioned earlier, it’s important to keep the separation between the Stand-Up Demo and the Review. 

• The Stand-Up Demo is given by developers to the whole team (including the Product Owner). It may include half-finished work, design options, and visual designs. It’s about sharing solutions, progress, co-ordination and receiving very fast feedback which may inform further work on a particular item. If the team needs to see more details, this can be discussed in a separate meeting. 
• A Review is with stakeholders and usually demonstrates a finished increment, to validate the end product. Feedback at the Review stage could be anything from a small tweak to significant or even to Pivot the direction of development. Any substantial change, however, is generally achieved through a new User Story or work item in a new Iteration/Sprint.

A final word on best practice when using any Stand-Up format…

Whether you’re using The Questions, Walking The Board or doing a Daily Demo, it’s important that you NEVER wait until the Stand-Up to raise a problem. If something arises, discuss it with your team members immediately and agree what to do about it.

Here at Liqueo, we provide organisations with the skills to implement programmes successfully through our flexible workforce model, tailoring solutions for our clients’ strategic goals. We deliver an exceptional, bespoke service to every client via a dynamic and agile framework. If you are interested in how we can help you implement successful programmes or want more information about the Daily Stand Up, contact us.