Better standups

At work the engineering community of practice have been doing fortnightly lightning talks about a wide range of subjects including favourite developer tools, infrastructure automation, DNA data storage and hypothesis-driven design. They are only 10 minutes each, but have been incredibly interesting and a fantastic way for people to do a quick presentation of things they are currently working on or are interested in. I did one recently on tips for better stand-ups after I heard it had come up in the retros for most of our teams, and have written them up to share my thoughts.

The stand-up is for the team not for the manager

For me this is number 1, and the quickest way for a team to disengage with standups is for them to feel that they are just status updates being done for the benefit of a manager.

The standup should be for the team to keep themselves aligned with the current landscape and progress, and to ask for help. Obviously, this does help managers understand progress if they attend, but the time isn’t for them to interrogate people about progress, it is about the team identifying what they can do to progress the ongoing work.

The focus should be “what do we need to do to progress this”, rather than “update me on what you have done to progress this”.

Work right to left, discussing what needs to be done to move each card along

I’ve discussed this before here.

With a focus on what the team needs to do to progress the work, the focus should be on the work not the individuals. This also means team members should feel safe and willing to ask for help with anything they are working on as it’s the responsibility of the whole team to deliver, and the team should be eager to offer that help.

##Stand-up should not be run by any individual This is related to the first point, and we’ve had some discussion about what running the standup means. Some teams find value in having one person coordinate and ensuring that everyone contributes, but I find this often ends up being the delivery manager or similar, and can too quickly slip into prompts for status updates. However, I think this depends a lot on the maturity of the team, and will also vary if you have remote attendees.

My team doesn’t have anyone running the standup as such – we use the order of cards on the board to know who speaks next, but we do find ourselves relying on our tester to get started (as he often speaks to the cards furthest to the right of the board) and can sometimes get a bit lost if he isn’t there!

As part of this, every team member should feel empowered to keep the standup focussed by speaking up if they feel it is going off course, and if they feel a conversation has started that should be done outside the standup.

Consider the scope of the stand-up

One big pitfall I’ve seen is having standups with too many people, which makes it tricky to coordinate, and will contribute to standups that take way too long. This is probably a wider team composition issue which needs to be addressed at the same time, but it is worth considering what is in scope of the standup, and what could be split off.

I’ve found that if I have a specific sub piece of work that is being done by specific people and has few dependencies on the rest of the work going on, it can be worth splitting it off into a separate standup. There is often resistance to this as people want to keep up to date with everything the team is doing. However, consider if there are better ways to do this – as I said before the focus should be on what the team needs to do to progress something, rather than status updates. In this case it is turning the standup into a status update for the whole team rather than just a manager, but it is still worth considering if there is a better way of doing this.

If the standup is often overrunning because of team notices or other information, consider as well if these can be done in another way, if the team feels they are getting in the way of their standup.

Everybody involved in that scope should be there

Once you’ve decided on the scope and who is involved, those people (if available) should be at the standup, and the timing of the standup should be set for a time everyone can make.

Coming back to the focus on progression not on updates, even if someone doesn’t have an update, they might be needed by someone else to progress something, or might be able to offer help.

Setting a time can be hard. We have flexible starting times, so the time team members start work varies from 7.30-10am. To ensure everyone can make it, we try to start it at the earliest people are in. However, we are tight for space and must work around other teams pushing our standup to 10.30. This feels too late, some people will be in meetings by that point, at those who started earlier end up having their day broken up. This particularly impacts people who don’t feel they have really started the day until after standup. If you have more space and aren’t competing for standup times this shouldn’t be as bad a problem!

But if it isn't relevant to them, they should feel free to walk away

This contradicts the previous point, and was the most controversial one I discussed in the lightning talk. It is a rule I generally have for meetings – we are all adults, and we know how our time is best used, so we should feel free to walk out of any meeting if we don’t feel the need to be there.

Whilst it does seem to contradict my point that everyone in the scope of the standup should be present, the should is the main point – if people should be there but don’t feel it is a valuable use of their time, this is a useful indicator for me that something is going wrong, and is something for me to identify and work on.

Keep asking what needs to be done to improve

As with everything. These are tips that have helped my team improve their standups, but we keep an eye on how things are going and discuss it regularly. They can be a starting point for other teams, but everything should be adapted for what works best for you.

If we feel things aren’t working, we often try new methods as a 2-4 week experiment, then revisit it and discuss how things went. If it didn’t improve things, fine we can drop it. If it did, fantastic we can incorporate it, but that doesn’t mean it can’t be revisited again later.