Thunderdoming

A lot of project frameworks look like theatre to me. Theatre’s fine and all, but it’s not my job.

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

It’s trash, it’s stupid, but it’s just “cognitive function in a kanban”. which is why it works for me, because I have cognitive function. Maybe your team doesn’t. That’s ok, stick with your epically productive standups.

Workflow Overview

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

Doesn’t need a polished pitch. 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 sounding ideas have some nuggets of awesome in them.

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”.

This usually comes from understanding wtf is going on in the business, and one very uncomfortable 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.

Slop the finished product onto a silver platter for your team.

Refinement: The Thunderdome

I think normal people call this “grooming”. I call it beating the shit out of ideas until they’re ready. Or, if you want to be nice in front of execs, “Thunderdoming”.

This is where the idea does battle to get to a stable path forward. Poke the idea, question assumptions, look for re-use or potential landmines.

Don’t be too proud to say ‘I don’t know’. Because if someone acts like they know everything, you should probably laugh loudly at them. They’re jackasses.

Anyway, if the task survives, 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.

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

Once it’s in todo, it can be claimed (tho it prolly should have been claimed inherently in the thunderdome, but w/e, you do you)

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.

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

y not just let pms do all this

Because a lot of them chase tickets like it’s some real measurement of anything when the real impact is just drag.

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

And when I’ve worked with the PM who brings real context and domain insight?

A worthwhile partner. You know who you are.

2 hard 2 care, y bother

yeah pretty much it’s just “do everything yourself and now you’ve got no exec visibility for 3x the work”.

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

In a place that focuses on theatre instead of results, yeah this is gonna flop. You can always 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 some killer impact, and the results aren’t screaming louder than some dumbass powerpoint, always be open to the idea that you aren’t as good as you thought.

Because that means you’re good. Or you’re shit. Or maybe not?

Maybe I’m trash. Which means at least I’m self aware enough to improve.

Look, at least I’m not chasing ticket velocity thinking it actually means anything.