Take your stand-up to the next level
In my previous article, I wrote about how we should abolish stand-up meetings completely and instead use the tools we already have to keep everyone updated (whatever you use for tracking tickets and for instant messaging, or even email).
As part of that article I briefly mentioned a different kind of stand-up meeting to what most people are used to. I'm going to expand on that here. First let's look at what most people think of when they think of stand-up:
Round robin stand-up
Each person takes it in turn to answer three questions:
- What did you do yesterday?
- What are you doing today?
- Do you have any blockers?
There may be some variation on the questions, and maybe you spice it up by randomly choosing the next person to speak, but I can almost guarantee that you'll have the following comments:
- “I was in a bunch of meetings yesterday”
- “I've got some meetings today”
- “I made some progress on my ticket”
- “I'll keep working on my ticket”
These statements are a complete waste of everyones time. It's more than likely that most people are just waiting for their turn to talk as well. Maybe they're rehearsing their update while you're giving yours?
The best thing about working “agile” is the retrospective. This is your chance to ask the question “Why do we keep doing it this way?”, and as a team to come up with something that works better. If you can relate to any of the above, please bring it up at retrospective! Stand-up may not seem like a big deal, but if there's ten of you doing it for fifteen minutes, that's at least two and a half hours of productive time down the drain every day if it's used poorly.
Kanban stand-up
If you've not worked Kanban before, the main driving factor is getting stuff to “done”. You don't need to change sprint board, or add swim lanes or anything like that. You just need to change the focus of the conversation to the tickets. Here's how it goes:
- Everyone gathers round the sprint board (or someone shares their screen)
- The Scrum master (or a volunteer) points to the right side of the board and highlights any tickets that made it into the “done” column. If there's anything relevant to highlight here, people can speak up (for instance “Make sure and update your dependencies after I merged that ticket”)
- Then the conversation quickly moves on to the column to the left. This will vary based on your agreed work flow, but it could be something like “PO review”, “code review”, “E2E testing” or “Ready to merge”. Whoever is responsible for the ticket in this column will speak and share with the team what is happening with the ticket. This could be as simple as “I'll finish that this morning” or “I didn't realise that was there, I'll look into it”, or “I need help with this”
- If it's highlighted that help is required as the team works through the board, the strict rule of thumb would be that this becomes more important for the team to resolve than anything to the left of it. In reality however, it's never that black and white, so have the conversation as a team to decide if it's worth taking someone off another ticket to help, or if it should move to “blocked” until it becomes priority again.
- The conversation continues to move backwards through the columns, with people giving appropriate updates until you get to the “To do” column. At this point anyone who isn't working on moving a ticket to the right (by either helping or owning a ticket) should speak up and the team decide what the next most important thing to do is.
- The very last thing is to check if anyone has anything they need to share that hasn't been covered. This will usually be things like “Remember I'm off tomorrow”, or “I need to ask some questions about an upcoming piece of work on the backlog”.
As you get used to this method of stand-up, you should find that the conversation flows naturally from ticket to ticket, and you remove all the fluff. As the team gets used to it, the scrum master / volunteer will need to do less and less prompting.
If this sounds like it could be useful for your team, I'd encourage you to suggest it at your next retrospective. You don't need to change your sprint board, or any of the other ways you work, you only need to change the focus of your conversations to the work, instead of the person doing the work.
Other stories about Working Practices:
5 simple tips to speed up your development environment
I'm pretty lazy, but lazy in a productive way, so I spend a little extra time and effort once so I can be lazy in the future.
Confessions of a Lead Engineer
I hope my boss doesn't read this…
How two babies and a toddler made me a better mentor.
You don't need to be an expert to be a mentor
How to get stuff done when your brain says no
Some tricks to focus when your brain decides you have a million things you must do right now.
Has COVID killed the daily stand-up?
The meeting that was “for the developers, by the developers” has turned into another status update meeting for middle managers.
Richard Bell
Self taught software developer with 11 years experience excelling at JavaScript/Typescript, React, Node and AWS.
I love learning and teaching and have mentored several junior developers over my career. I find teaching is one of the best ways to solidify your own learning, so in the past few years I've been maintaining a technical blog where I write about some things that I've been learning.
I'm passionate about building a teams culture and processes to make it efficient and satisfying to work in. In many roles I have improved the quality and reliability of the code base by introducing or improving the continuous integration pipeline to include quality gates.