Standup Braindump

The standup is a short recurring meeting used to (re-)focus the team-mind on effectively moving stories through our workflow. Here's my recommended approach to having standups be useful and brief.
The general sequence is 1) address team-wide emergency issues, 2) work story-by-story, 3) distribute new work, 4) address team-wide non-emergency issues.

Note that, quite often, there is no part 1, and no part 4. Sometimes there's not even a part 3.

Some general tips, then.
1) Don't over-engineer standups. Stay relaxed with pep. Don't go telling people I said these were the rules. All meetings involve humans, and once humans are involved, we have to flex.
Rules are far less important than the people in the room.

Think hard about what Benjamin Zander calls Rule Number Six.

"Don't take yourself so #$@&%#!$ seriously."
2) Timing: Same bat-time, same bat-channel. Fix the time and place, virtual or otherwise, and don't move it around often. (Cancelling is fine.) The regularity and stability is an important factor. Start on time, as you don't need to wait for someone to be in charge.
If we regularly have teammates that are shared by another team, stagger the standups so they don't overlap. There is no particular merit to having your standup first thing in the day. (A great technique I've used, have it right before lunch. Makes it go much faster. :) )
Best time for a standup is a time such that there's nothing immediately pressing in the 15-20 minutes right after it. This keeps us all free to have important after-standup conversations offline.
Juniors will need help with one key aspect of this: if you are blocked, don't wait for standup to tell us. Reach out to your PO, your SM, or your lead as soon as you block. In flow, wait states are the enemy.
3) Story-by-story: Work story by story rather than person-by-person. The stories are the primary focus. In particular, the standup is not for the purpose of establishing each individual's value to the team.
It's not that we don't care about how our members bring value, it's that this is not the right time, right place, or right info for that conversation. We're here to update our sense of how/if stories are moving, not to justify our existence or rationalize what we did yesterday.
Work stories "right-to-left": from the ones that are closest to shipping to the ones that haven't even been started. On most boards, the rightmost column is either "shipped" or "ship it", and the leftmost column is "I wish", and all the columns in between are "plugging away".
What to say about a story is a judgment call. Important signals we need, in rough order: a) needs more eyes or hands on it. b) entered or left a wait-state. c) went backwards. d) went forwards. e) is proceeding normally.
4) After we've walked through all of our WIP, we may have individuals who are looking for action. Because we have a decent picture of our status at this point, we can easily talk about what they should take on next.
The preferred answer, if its possible, is to send that person to pitch in on a story we already have in progress. If you work by pull-request or technical review, that's the second choice. If you're a test-after shop or a refactor-whenever shop, that's the next choice.
5) Questions will come up. Many of them can be answered in two sentences, and that's fine. If it can't be answered in two sentences, or we give two sentences but it still didn't quite get answered, learn phrases like: "Ping me right after."
It means, let's talk about this after the meeting, at your convenience. Nothing kills standup like a detailed answer to a detailed question.

If you think others *might* care, try "Anyone else who wants to work through this, ping me right after and we'll do it."
6) Parts 1 and 4. In a perfect world, there's never a part 1. This is not a perfect world, tho. Outages, freezes, and other brushfire situations happen from time to time, and can dramatically alter the thrust of the standup, that's why they come first.
On the other hand, issues that are simply the normal global events we encounter, these should be addressed, if at all, when all other business is dealt with. The standup is not "a convenient opportunity to say anything to the entire team".
7) Practice. It's not some biological gift to be able to speak in short declarative on-topic sentences, it's a skill, and we can learn it if we practice it.
"How were the standups?" is a perfectly legit question for a retrospective to take up.
And there ya go. That's me dumping what I believe I about the best standups. Have at it, have fun, ping me if you have questions, comments, controversy, war stories, or whatever.

Remember Zander's Rule #6.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

11 Apr
The ultimate making app for a shipping multi-service system is actually a one-machine monolith with a UI. If your team is experiencing the most common pains from working in a large SOA environment, the productivity payback will be enormous.
It's important for me to take a second to remind you that there's much more to this world than geekery. Please keep working for change all around you, including, especially, outside the monitor.

Stay safe, stay strong, stay angry, stay kind.

Black Lives Matter.
We've talked a lot about the idea of having a shipping app for our customers and a making app for us. We can use the same source base to make multiple binaries. We target customer needs with one of those, and we target developer needs with the rest.
Read 43 tweets
9 Apr
Ahhh, yes, the first thunderstorm of the new year. Spring is spranging. I love spring so much. But I hate thunderstorms. I'm here with Wally & Molly. Wally is indifferent. Molly is terrified.
I grew up in Kansas, and I'm with Molly.

Squishing against her, her against me, we manage.
I try not to freak out, cuz I'm taking care of her. She tries not to freak out, cuz she's taking care of me.

We both freak out, tho, really.
Read 10 tweets
4 Apr
My rice'n'garlic advice, "take many more much smaller steps," can be said another way: reject any proposed path that requires a step size larger than the limit you've set for that particular domain of activity.
Time for Sunday geek comfort. It's meant to be respite. There are more important things than geekery, so please remember to think outside the monitor.

Stay strong, stay safe, stay angry, stay kind.

Black Lives Matter.
"Rice'n'garlic advice" is blind advice, for when people ask you what to do, but you're not there & can't see. You have to guess. A professional chef I know, when asked to give blind advice, always says this:

1) That's too much rice.
2) That's not enough garlic.
Read 33 tweets
2 Apr
q: how many ways are there to partition a 5x5 tile square into 5 pieces, each containing 5 orthogonally contiguous tiles?
(Asking for a self who is considering a brute-force algorithm.)
I figure there's a tree. Every such partition has [0,0] in A. There are only three one-steps away, [0,1] in A, [1,0] in A, or both. And so on. If we mapped that tree one time, we'd have a number of cases. Times 4 for rotational symmetry. Times 2(?) for diagonal symmetry?
Read 5 tweets
28 Mar
Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making.
It's Sunday, which is geek comfort food day for me. Remember, tho, to think and feel and work outside the monitor. Please help me in opposing the multiple ongoing efforts to suppress the votes of millions of American citizens.

Black Lives Matter.
A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app.
Read 39 tweets
28 Mar
My friend Steve, I was spozed to be the pro from dover, told me this thing, and for, idunno, 17 years or so(?), I've been holding on to it. He said it boils down to two things. Don't waste time. Accept the whole person.
NB: It doesn't mean "accept everyone". It means, if you accept my geek chops, or you accept my sex appeal, or you accept my brilliant theorizing, you gotta accept my (considerable) doofusness.
You can't take my good days and not accept my bad ones. And if you can't handle my awful, why are you prepared to cash in on my valuable?
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!