The daily stand-up is arguably the most successful export of the agile philosophy. It has become a feature of many delivery teams—even non-agile, non-development teams.
In these teams it is mostly used as a morning catch-up session to align team members and share updates related to ongoing work.
As such it is different from the Daily Scrum ceremony which is specific to teams using the Scrum framework. Whilst the Daily Scrum is a meeting for a Scrum development team only, a daily stand-up, as co-opted by non-agile non development teams, encompasses a wider group of participants and often include discussions beyond the famous three questions.
Some teams have experimented with and adopted practices that make their stand-ups useful, efficient and enjoyable. Whilst others perform the meeting in a way that makes it tedious and uninspiring.
Here are some practices to experiment with when performing a daily stand-up as a non-agile, non-development team.
Do you really need a daily stand-up?
Before jumping in with daily stand-ups, ask yourself: Do you need a stand-up at all? Does it really need to be daily?
I have seen teams who spend their entire mornings dialling into one stand-up after another. These stand-ups are about 30 minutes long, start at 9am and you might have three or four of them in a row. First there is the programme stand-up, then the department stand-up, then the cross-team stand-up and the BAU stream stand-up and before you know it it’s 11am and you’ve spent the whole morning doing little more than muting and unmuting in so called stand-up meetings whilst firmly sat in your chair in-front of Microsoft Teams.
This may not be the most effective use of your team’s time.
The morning hours are when most people are at their freshest and able to do creative work so please, if you can, spare your team another stand-up and allow them to use this precious time of the day to engage in creative, high value work that actually produces product output.
You should have a really good reason if you need more than two stand-ups per day. Even one a day for some delivery teams is too much. So evaluate your current stand-up or think carefully whether one should be implemented at all.
Stand up (if you can)
Many project teams are now both virtual and distributed across the globe. As such it makes it necessary to have stand-ups using video calling tools. This, however convenient, takes away one of the key purposes and benefits of the stand-up: speed. The clue is in the name. Originally teams were co-located and so could head to a designated area and perform their daily stand-up whilst, wait for it… standing up. This had the effect of reminding participants of the concise and punchy nature of the meeting i.e. you’re less likely to keep rambling if you’re standing. This has been lost somewhat in the way that most teams now practice the stand-up where teams are virtual, distributed and not necessarily agile.
If you are a co-located team, then this is still something you can practice to see if it changes the flow and efficiency of your stand-up. If not, then you can still use some of the recommendations below to make your stand-up short, sharp and to the point.
Keep it to 15 minutes
Another tip that could help increase the speed and efficiency of your stand-up is to practice keeping it to 15 minutes.
Most of the stand-ups I have seen in non-agile project teams last 30 minutes or more. This is too long. If you set a meeting for 30 minutes people will inevitably take up the full 30 minutes—it’s just natural. People will speak more casually and ‘run down the clock’ simply because the time has been alloted.
If you’re running 30 minute stand-ups, experiment with shorter times and see if it produces a more pointed and precise discussion.
Don’t let one issue/person dominate the stand-up
The daily stand-up is useful to identify important areas of concern that need to be addressed in more detail. It is not the place to solve issues. It is an opportunity for team members to identify conversations that need to be had and schedule those conversations to take place outside the stand-up.
As such don’t let one topic dominate the who stand-up. For example, if the first person to speak raises a production issue recently discovered, as tempting as it is, don’t spend the whole stand-up discussing that one issue. If there isn’t an obvious and swift resolution within a few minutes, a separate meeting should be set up where a resolution can be discussed in more detail. This keeps the stand-up ‘fast and furious’ and gives other members of the team, an opportunity to raise issues of importance to them.
Use a board
Some teams use a kanban style board to aid their daily stand-ups. I generally recommend this as it helps to give team members a reference point when they cannot make a stand-up or where they want to revisit a point that was raised and follow its outcome.
You will need to take a view with this one and ensure that what you put in place here isn’t over the top. The best approach is a very high level board where team members can easily add, update and delete points that they raise in the stand-up.
This also gets the team into the habit of recording for themselves every decision, recommendation or issue that is raised such that no one goes away with a different understanding of events and visibility and transparency is increased across the team.
It’s best when this is owned and edited by team members and is not something that a manager updates on their behalf or is used to ‘check status’ or ‘hold the team to account’.
Do it in the evening
Most teams do their stand-ups in the morning. Whilst this is helpful, experiment with having your stand-ups later in the day. Try 4 or 4.30pm and see how that works.
One of the benefits of an evening stand-up is that it’s more likely to be concise as people begin to anticipate the end of their day. You will also get much more specific and relevant input as people are likely to have encountered things throughout the day that are at the forefront of their minds and easier to articulate.
Final Thoughts
The key thing about stand-ups for non-agile non-development project teams is to make sure that it is useful. Normally these meetings are permanently scheduled in calendars and no-one ever reviews them to see whether they are still fit fit for purpose. Don’t just keep the status-quo. Experiment with boards, participation, timings etc. and always inspect and adapt if you find more efficient and effective ways of doing things.