Review the Board Right to Left

Scrum is like [C]ommunism. It fails everywhere, every time, but they tell you “you aren’t doing it right.” - @svpino on Twitter

Stand Ups Should Be Your Best Meeting, Not A Meme

You probably have too many meetings. I’m not here to argue otherwise. I dislike Scrum immensely. I’ve almost never seen it done well, and when I have it’s required an entire employee’s time making it totally not worth the price. The meetings are literally called ceremonies!

Ceremony noun: An action performed only formally with no deep significance

BUT…

Here’s my challenge for the stand up haters out there. What could possibly be a lower friction, lower time commitment meeting? If done right, stand ups eliminate almost all other meetings. Someone is stuck? The number one priority is blockers. Emergency work came in? We can adjust who is doing what in real time. No one is reviewing PRs? The (constructive) admonishment will occur. The key factor is that they mean things can never be going wrong for more than one day.

If you have a good stand up, you really will only need occasional backlog hygiene / reordering meetings. They’ll be shorter too, because the daily small effort keeps things cleaner.

I met Dave Thomas while I was in college, he was gracious enough to come speak to our class. It’s funny looking back on it, because at the time being young I didn’t actually know who he was or that he was kinda a big deal. Scrum was riding high at the time, and our college was shoving it down our throats. I couldn’t help but think how dumb and pointless it all was, especially after I learned about Kanban and the Toyota Production System.

There have been few times in my life where I have felt so validated as when I saw PragDave himself rail against Scrum with with great frustration, irritation, and flawless critique. It’s stuck with me.

Pseudo-Scrum

As bad as Scrum is, chances are what your company is doing is worse. Most teams practice what I like to call pseudo-scrum. You have monthly retrospectives, but this is about the only thing done right. Your stand ups might be decent, but even then it’s mostly a chance to stretch your legs. Well, pre Coivd it was anyway. Most teams will spend stand up on a mix of a redundant, low value summaries of what happened yesterday and the facilitator moving the cards around that the engineers failed to update themselves.

Then, the worst part. Sprint planning. A hodgepodge of arbitrary estimation, incomprehensible prioritization schemes, and moving things over from the prior sprint that allegedly were going to be done by now.

In Scrum’s defense, it wasn’t supposed to be this way. The point of tracking, estimating, committing to fixed sprints, and reflecting is to make delivery predictable. This is a noble goal. It’s not that there’s no value to be found here, it’s that it can’t be extracted at a low enough cost. Funny enough, much in the way that the S&P 500 outperformed every hedge fund in Warren Buffet’s challenge, simply estimating every task as 1 point tends to be equally or more correct than planning poker and the like.

It’s not that you shouldn’t plan, it’s not that you should break down work, it’s not that you shouldn’t have frequent check ins to readjust to new priorities. It’s just that you don’t need to bring a bunch of math and tools and dashboards into the mix to accomplish these things. Worse yet, these quickly take over and subsume the actual value of the process.

Better Stand Ups

I’m not going to go over what a stand up is, what isn’t, blah blah blah. That’s been covered to death and I have nothing of value to add. What I do want to focus on though is what are mechanisms that structurally incentive your team to do the things you already know you should be doing. Stand ups are bad when they don’t provide value. When the information is bad, inaccurate, or missing the meeting becomes pointless. When it’s pointless attendance drops. When the culture is that there’s no structure, it impacts the board too.

Soon, planning and basic state tracking become a comfortable lie you tell yourselves, a cozy sweater of ignorance and delusion as you collectively overlook the sloppiness and lack of direction that only the software world can produce from expensive skilled professionals.

Nailing Stand Up

Incentives drive the world. Structure for what you want to see.

Structure

Length	15 minutes
Frequency	Near daily; I recommend daily Monday through Thursday
Size	Aim for 2-6; 8 max (teams should never be larger than 6-8 this is well established across all disciplines)
Audience	Engineers actively working on that project this week (on that note, try to rotate people through things weekly rather than daily)
Active Participants	People with assigned work on the board
Facilitator	Ideally a lead of some kind (including ICs) and tie break by picking the one with the least context. This mixes authority, ability to ask questions, and probability of sniffing out issues

Go from right to left on the board. Remember, the main goal is to unblock people. What is preventing us from going forward? What was are we doing next? What came up that people should know? What did you do yesterday? That’s the order of priority here.

Go one column at a time, not one person at a time. Randomize the people order for each column. This reinforces the priority, ensures that if time runs out the least important parts are what’s caught, and keeps people from zoning out as easily.

Attendance is mandatory. Coordination is important, and this is the most efficient way to do it. You will have the occasional true conflict, but you always have enough time. After all, if you don’t have time for stand up, when are you going to have time for the meeting it would have prevented?

The meeting must end with the board accurately reflecting reality.

Above all else, never lie. That’s why you don’t speak if it’s not on the board. That’s why things get demoted back to the backlog when they’re interrupted. You may feel uncomfortable with this framing. Good. That gnawing feeling is you conscious goading you to do better and to grow.

Clean Slate

In my post on organizing tasks I recommended declaring email bankruptcy. Email is one of the few areas where the need for drastic action is high and the cost of that drastic action is low. The underlying spirit and power of this method isn’t the destruction, it’s drawing a line in the sand and saying we’re done with this crap.

This is the only way to address debt of all kinds.

• Gained a bunch of weight? You (*cough*, me) need to stop taking in so many calories.
• Found yourself in financial debt? You gotta stop spending so much money on things you don’t need (the true meaning of the word, not our cushy life version in rich countries).
• Feeling overwhelmed and randomized? Stop accepting more work.
• Test runs are too slow? Stop adding more slow tests.
• Not getting works items on the board done? Stop working on things that aren’t on the board.

Unlike with email bankruptcy, we can’t just take one step to start back at a clean slate. But by definition, if you want a debt based problem to go away you first need to stop making it worse. That’s what this style of stand up encourages. If you only discuss what’s actually on the board, you quickly will have to cut out the other crap that is randomizing people. It will be hard at first, and even people who have complained they’re randomized too much will make unforced errors not following the board state. You will see near daily improvement on all fronts though.

Make your initial planning meetings about cleaning up the board. Again, go right to left. Is the board still inaccurate? Does it have too many things on it? Well then you’re not planning today. You’re not pulling in new work. You’re not organizing the backlog. These are pointless motions. These are lies. Your current state isn’t reflected accurately, how exactly do you expect to make stronger claims about the future than you can about the present?

Further Listening

If you’d like a punchy, more positively framed, sharable version that explores the basics of planning in more detail, No Boilerplate’s You’re Doing Agile Wrong is excellent. You’ll notice some overlap with this post, that’s not a coincidence. It’s where I first learned of the idea of going right to left, which in turn inspired me to develop the portions of this post that are my own.