Thunderdoming

A lot of project frameworks look goofy to me.

I have my own “framework”, called “Thunderdome Kanban”.

It’s structured, blunt, and some would call it unrefined- I call it truth. It works because it’s honest, and I’ve used it for years to keep my teams cooking.

Workflow Overview

Backlog / Input: Reality Sucks; Let’s Fix It

You want complaints- the unstructured, vague type. Create tickets for these to shield the team’s time. If the request is lousy, it gets nuked into Will Not Implement. If it’s a maybe, keep it. It can age well too. What was true 2 years ago may not be true today.

Sometimes the worst ideas have some nuggets of awesome.

Requirement Analysis: Beating Clarity out of Ambiguity

Turn “i want better data” into something usable. e.g., “RSSI, CINR, GPS coordinates, on a 24 hour cycle, queryable on my phone.”

This usually comes from understanding the business, and one long pause where the request is calcified into reality when the target of your inquisition relinquishes what they actually meant to say in the first place. It’s an art.

Get the finished thought onto a silver platter for your team.

Refinement: The Thunderdome

This is usually called “grooming.” Weird. I call it “Thunderdoming”. It sounds harsher than it actually is, and I think this is the part that most people screw up.

The idea does battle to get to a stable path forward. As engineers, we facilitate their battle. Remember, this isn’t engineer vs engineer, this is idea vs idea. Super important to get this through- we’re not here to prove who’s smartest, cleverest, etc. We’re here to learn from each other as ideas get stronger.

Poke the idea, question assumptions, look for re-use or potential landmines.

Never be too proud to say ‘I don’t know’.

If someone acts like they know everything, you should probably laugh loudly at them. They’re jackasses.

Anyway, if the task has a path that makes sense, it moves to Todo.

If it gets beat up a little too much, maybe it goes back to requirement analysis. That’s ok. No penalty, it’s fine. You get to learn too. That means you get feedback on what you need to truly silver-platter up the ideas. It’s a good thing.

Execution: Just get it done, but don’t be stupid about it

Once it’s in todo, it can be claimed (probably could have been claimed inherently in the thunderdome too)

Engineers can and should push back or pivot mid-stream if the original plan turns out to be bad. That’s learning. It’s ok. Just make sure it gets communicated.

We're not here to do the stuff we already know how to do. Sometimes a ticket gets blocked. That's fine. Sometimes it becomes "Will Not Implement". This is also fine. Learning what not to do is just as important as "doing something". Sometimes more important.

I’m not going to describe ‘will not implement’, ‘testing’, or ‘done’.

isnt this just pm’ing yourself

Yeah, it is. Is this whole thing arrogance? A little, but mostly it’s just ownership. Know the system, the players, the business.

Are there pms that can mesh with this with real domain insight? Yeah. A worthwhile partner, for sure.

too hard 2 care, y bother

yeah pretty much it’s “do everything yourself and get no exec vis for 3x the work”.

Nailed it. That’s the issue. Caring sucks. It’s hard.

In a place that focuses on ticket count, this will flop.

And sure, don’t forget to throw together some slide decks to get wins for the quarter to show progress.

And if you can’t slop a deck together to show killer impact, and the results aren’t screaming louder than some vague deck, always be open to the idea that you aren’t as good as you thought. Use that to get better.

And still, I’d rather do that than fake impact to chase ticket velocity.