A Developer’s Guide To a Stand-Up That Doesn’t Suck
It is almost universal that you’ll experience a 15-minute daily stand-up meeting every day as a developer. It is nearly as universal that these meetings will take longer than fifteen minutes and fee like a waste of time. Well, that is because most of the time, they aren’t running correctly. So, here are some tips to turn those meetings around.
The Main Problem
I consult in many companies and help development teams finally do all the great work they always could. That means a lot of the time, I go and fix poor meetings and communication. The stand-up is one of these things I fix.
Think back to your last daily stand-up and when you were about to speak. Now, answer this question, “Who were you talking to?”
Almost every time, the answer to the question is either: Scrum Master, Product Owner, or a manager.
That is the main problem. The stand-up or daily scrum is for the development team to get their day organized and help each other. It is not for those other three people.
So, when everyone is talking to them, it winds up being a pointless status update.
This is called the Hub-and-Spoke pattern. The pattern is where all information is flowing to a central point. A better stand-up doesn’t have this pattern at all and instead is developers talking to developers.
Still not sure I’m right? How many times have you spoken in the update in terms of the ticket identifier? Something like “Yesterday I worked on Jira 1123, today I’ll work on the same. No blockers.”
I’ve never met a developer who talks to another developer that way. You’d talk to your peers by saying something like, “I’m trying to fix that schema thing. Its used in a lot more places than I thought, so it’ll take time.”
The bottom line here is that this meeting sucks because everyone is talking to the wrong person.
Look Somewhere Else
This sounds simple, but the way to get the stand-up fixed is to look at someone else.
I’m dead serious about this. When you do your next meeting, instead of looking at one of the troublesome triad, force yourself to look at another developer. If you’re doing this remotely, look at their name on the attendance list.
When you force yourself to talk to someone, the awkwardness of saying nonsense to them will become crystal clear to you. So, stop speaking nonsense and speak to them like you would after the meeting is over.
As small of a change as it is to look at someone else, habits don’t change instantly, so give yourself a few tries before noticing a difference.
What About the Manager
Depending on where you work, people will either not notice your change or demand to hear the ticket numbers again.
You can do both for a little while if you want.
Or, you can begin to put your foot down about things and force the issue. If you’re going to take this bold step, here are some things you can point out.
- The daily scrum says it is for the development team, not the other people. Stop doing scrum poorly
- Its the dev team’s job to complete their sprint, so let you talk about it the way that makes sense
- We already have our assignments in the tool. Why do we need to tell you that we still have those assignments?
- If they have questions AFTER the meeting, you’d be happy to answer.
- The quickest way for me to get help is to get it from my peers, so let me tell them what the problem is
Now, these kinds of statements will not likely make anyone suddenly change their tune, but one of them will likely make someone go, ‘Oh!’
The most common objection you’ll hear is, “I need to know what everyone is working on.” To that, you can show them and assure them of two things. First, the tool you use is up-to-date. Second, if there is something specific they need from that person, they will explicitly tell them.
If most developers start talking to each other, you’ll get the value back from that time, get more help, and help the others with the sense that they lost control.
It Is Your 15 Minutes
An excellent 15-minute meeting is harder than it sounds, but it truly is possible to go from one that is a chore to one that sets up the rest of your day well. The key is to talk to your development team instead of other people.