What I’ve learned about: Stand-ups

Photo by Eden Constantino on Unsplash

You’re the captain of a ship that has just set sail from Southampton to New York on a 7-day journey across the vast Atlantic Ocean. You plot a course, sail out of the harbour and point your ship in the direction of New York. You’re done! Now you can relax, safe in the knowledge that in 7 days time you’ll arrive in New York because that’s the direction you set sail in. Right? Well of course not! It’s necessary to constantly re-evaluate your progress in case currents or winds have hampered progress and it might delay your arrival. Perhaps you’ve drifted off course and need to change direction to ensure you’re still pointing at your intended destination. In many ways, delivering a project is like sailing a ship. You know the destination – your deliverable – and the schedule, and you know how you plan to get there, but it’s essential that you keep track of progress so you can make important corrections early and avoid disaster. Even better – if the whole crew is keeping track of progress, then everyone can pull together to deliver the outcome everyone wants. What’s more – with the whole team keeping watch and fully informed, the captain can afford to spend time away from the bridge confident that everyone knows what they’re doing.

The daily stand-up is a staple of most modern technology teams, and many teams in the growing circle of agile adopters outside the tech industry. Done right, it informs and energises the team and creates a cadence of accountability and progress. Done wrong, and it’s a regular opportunity to disengage, disrupt and dishearten the people you depend upon most.

For the uninitiated, the daily Stand-up is one of the “ceremonies” from the Scrum agile framework – and is sometimes referred to as a “daily scrum”. The point is for the team to gather around a visual board of the current work items and discuss progress since yesterday. It’s called a “stand-up” because everyone generally stands up – rather than sitting around a meeting room table as it’s a brief meeting, and standing up encourages brevity.

Most stand-ups happen when the team is working with either a Kanban or Scrum board – where tasks, written on cards, move from a “to-do” column at the left side of the board, via a number of intermediate “in-progress” columns to the “done” column at the right of the board – and the aim of the meeting is so that everyone can report on their progress to the whole team, and discuss any “blockers” and how to remove any obstacles to progress.

I first implemented stand ups on one of my teams in 2014, and since then I have participated in about 1,500 stand-ups both as a leader and as a developer. I’ve learned a lot, and if you are about to implement stand-ups in your team – or want to increase the value you get from them – I’d like to share five things I’ve learned that might help you get a little more juice.

1. Stand up

No, really. It is called a stand-up for a reason. As soon as it turns into a sit-down meeting – people ramble on. Some teams even do their stand-ups in busy office corridors rather than a meeting room, because everyone wants to get out of there as quickly as possible. One of the most common gripes among developers is the time spent in seemingly unproductive meetings. Stand-up should be as short as it is possible to make it. If you have a team of 5-6 people, 15 minutes is plenty. And when it’s done, it’s done. Don’t “use up” any remaining time that was allocated for stand-up by dragging it out. The first time I implemented stand-ups I time-boxed them by scheduling them at 12.50pm. Everyone was definitely in work by then, and we all wanted to go for lunch at 1pm so there was no room for getting off the point. This leads me nicely on to my next tip.

2. Keep it to the point

The traditional format of a stand-up is “Yesterday I did X, today I will do Y and I am blocked by Z/I have no blockers”. Each person says their piece and the leader or Scrum Master may offer to help unblock any obstacles, or other team members may volunteer advice or help, but that’s it. Move on. A big no-no is allowing discussions to develop about implementation details, potential upcoming features or in-depth discussions about individual items on the board. The reason these are taboo is that not everyone on the team needs to be involved in detailed discussions about particular tasks – and forcing them to play gooseberry in this situation wastes their valuable time. Crucially, this encourages them to disconnect from the meeting and diminishes the value they get from participating. Put a pin in the discussion and invite anyone who needs or wants to participate to pick it up right after stand-up. Another important principle in keeping it to the point is not to allow anyone – even senior managers to hijack the meeting. At one start-up the CEO liked the idea of stand-ups which I’d introduced on the tech team, and decided the entire company should have a daily stand up in her office. This turned into a 1-2-hour company-wide discussion of the entire business that left everyone feeling shattered. She meant well, but strayed far from the ethos of a stand-up, and rather than feeling energised and informed, we felt burned out and overwhelmed. In agile delivery, having developers work hand in hand with businesspeople on a daily basis is a key tenet of success. I recommend inviting stakeholders to observe stand-ups if they want detailed progress updates, but it’s also very important that they understand the invitation is a privilege and they are required to remain silent and observe. If they have questions or input, they can pick this up right after the team have finished, and it’s a win-win. Fast-feedback, and minimal meeting time for busy people.

3. Refine it to work for your team

As I mentioned above, the usual way to do standup is to recount what you did yesterday and what you will do today. We found early on that this has a number of problems. If people take time off – even for the weekend – they often forget important details of what’s been done, and this gets lost in the noise – missing opportunities for observing progress and celebrating success. It also encourages people to tune out. Using this format, each person is mentally formulating their own update rather than actively listening to the updates given by their colleagues. After stand-up, many of our team had no recollection at all of what had been achieved since yesterday. Instead, we opted to use a “walk-the-board” technique. In this format, we’d start by discussing any tasks that had been moved into “done” since the last stand-up, offering a chance to celebrate delivering particularly difficult or important tasks and see real progress happening. Then move backwards across the board, talking about each card in turn. In this way, everyone pays attention to the important updates and everyone discusses each card much more fluidly. It is slightly more time consuming than the traditional formulaic approach, but about ten times more valuable. It affords a chance to spot cards that haven’t moved for a while or that have become “orphaned” on the board, and invites collaboration between team members to help unblock any problematic issues. Above all, check regularly with the team about how stand-ups are working and make tweaks where necessary. Encourage the team to own their stand-up and do what works for them. At the end of the day, it is a team meeting – not a meeting with the boss.

4. Make it matter

I worked on a team where stand-up happened twice a week. It was about 11 o’clock in the morning, and the project manager would just call everyone to the board when enough people were around. We stood and looked at a physical board full of post-its that bore no resemblance to the work we were doing (as we also had a digital tool that had slightly more relevance), and talked about what we’d done over the last few days (if we could remember). Not a single post-it note moved in the ten weeks I was on that team. Not because no work was done – but the “board” didn’t reflect what was being done, and this bi-weekly stand-up was little more than a box-ticking exercise. In my experience, stand-up should be scheduled with some intelligence – and treated as though it is immovable. It’s common to have it first thing in the morning, but if people start at variable times or work in different time zones, pick the most appropriate time to suit everyone If someone can’t make it, have them send their update ahead to be read-out by someone else or better yet – dial in via video call. At Relative all our stand-ups were on a video call, even when we worked full-time from an office. The calendar invitation was scheduled for the same time every day and had a Google Hangout attached. This way, if someone was working from home – or even running late – they could dial in and participate in the brief update with very little fuss. We rarely rescheduled a stand-up, and I encouraged all of the developers not to wait longer than a minute if either I or the project manager were late to the meeting. There’s no need for leadership at these meetings – it’s predominantly a peer-to-peer exercise, and in fact I often encouraged a junior developer to organise and facilitate stand-ups to foster a sense of responsibility and ownership of the process. I was occasionally late or absent for stand-ups, but always made an effort even to dial in via audio from the car – primarily to show that I cared about the team’s efforts; because of course I could simply look at the board later for a synopsis of progress. Making stand-up immovable created a cadence of accountability. We encouraged flexible working, and everyone wasn’t always at their desk on the 9-5. This fixed daily deadline created a focal point for people to measure their progress every day, rather than finding out they were getting nowhere at the end of the week. Stand-ups can deliver a lot of value to the team for minimum effort if they are managed properly. Make them second-nature. Nobody should doubt when stand-up is, or be un-prepared for the updates they need to give. It’s an opportunity for progress, learning and networking and I’ve found it works best when everyone buys in with sincerity.

5. Keep it flat

I can’t stress how important it is that the team owns their stand-up. The worst scenario is that you create a sense that the team are reporting to you on their progress. They are not. They are accounting for progress to one-another. Stand-up is about team-work and seeing how you as a team are progressing towards your goal. When it turns into a “update the boss” meeting, then the second your back is turned it will not happen. When it doesn’t happen for more than one day, opportunities are lost to correct course on floundering tasks and people begin losing track of the bigger picture. When you keep it flat – that is, facilitate the meeting rather than leading it – and encourage the team to own it themselves – it becomes a habit and a tool the team use to keep the project on course. Consider showing up late occasionally to check if the team proceeds without you, or if they stand around silently waiting for someone to take control. If you’re struggling to get the ownership and autonomy up and running, consider a daily rota of facilitation. It’s clunky but it’s better than falling into the command-and-control trap.

I hope you found some of the things I’ve learned about stand-ups valuable. Let me know if you have other insights, or if you see improvements in implementing any of mine. The key takeaway I’d like you to get from all this is that stand-ups are a tool for team accountability and should be as short and useful as possible. They should become habit and without a doubt they are a great way to kick-start a day productive and collaborative work in almost any industry.

If you want to see a stand-up in action, check out this video of an agile team at Microsoft doing a daily scrum in Seattle.