Playing Someone Else's Game

Try to be different, but it's always the same. End up playin' someone else's game.
— Descendents (I'm Not A Punk)

Mark,

64 days in. I'm encouraging some change. Uniform sizing, throughput, buffer management. Always ship something deliverable.

It's worked before. The books say it should work. Critical Chain. No Estimates. DevOps Handbook.

But every company is different. Every trap has local variations. Every rescue mission has unique constraints.

Am I adapting to this context? Or am I just solving the problem I think I know how to solve?

I won't know for months. Maybe longer. The buffer will tell me if throughput is real. The business will tell me if transparency matters. The team will tell me if the protection works.

But will I have the chance to find out? Management may decree that divination and prophecy is the way. I might find myself on the wrong side of a re-org.

You asked three questions. Here are my answers.

The Gantt Chart Conversation

I don't want to kill Gantt charts. They solve a real problem. Marketing needs to know when to plan campaigns. Sales needs to know what to tell customers. Product needs to sequence releases. The business needs to synchronize.

I don't want to kill Gantt charts. I want to stop feeding them lies.

Right now it's fed by false prophecy - someone eyeballs story points and converts them to dates. "Three, five, eight... yeah, two weeks sounds right." That's not a plan. That's guesses about guesses.

So change what feeds the chart. Start with the timeline instead.

Launch date is eight weeks away. Set aside 30-50% as buffer - let's say three weeks. That leaves five weeks of work time. Not a promise, a constraint.

Buffer management is the key. Each week we track how much buffer we've consumed versus how much work we've completed. If we're burning through buffer faster than we're shipping tickets, that's a red flag. Time to look at what's slowing us down. If we burn through our buffer entirely, time to talk about what's not going to ship.

We look at three things: work completed, work remaining, buffer status. Not "on track" or "behind schedule" - just the facts. This many tickets done. This much buffer left. This is when we'll likely finish.

It's not prophecy. It's measurement.

But it still requires trust that we're measuring the right things. It still requires the company to take action when the warning is given.

What Buys Time

Product needs dates and story points aren't dates. One developer's "3" is another developer's "8" and neither of them is a customer's day. The grab bag of estimates becomes prophecy through eyeballing and hope.

So let's do uniform sizing.

Break every story until it's roughly the same size - can a developer get this done in a day? Yes or no. That's an easier question than "How many points is this?" Yes or no beats open to interpretation.

Once tickets are uniform, just count how many are completed. Last week: 12 tickets. This week: probably 11-13. That's your throughput. It's predictable because it's based on what actually got done, not divination.

Uniform sizing requires the team to be able to break a story into deliverable slices. Can they?

It seems simple enough, but I've had trouble explaining it before. We split stories during refinement. If something won't fit in a day, break it in two. If it's too small, combine it with something else. Everything becomes roughly the same size. Then we count how many cross the finish line each week.

That number - throughput - is what buys time. It's what I can point to when someone asks "When will it ship?" I can say: "We complete about 12 tickets per week. This epic has 60 tickets. Add three weeks of buffer in case we're wrong and a story takes an extra day or two. We take it from the buffer. About 8 weeks."

There's still uncertainty, but it's based on what actually got done.

Protecting the Team

The new trap happens when the buffer is exhausted but the company won't face the new reality.

Under the old system, you don't know there's a problem until it's too late. March 15th arrives. The epic isn't done. "Why are you late?" The prophecy was made months ago from story point divination. Nobody saw it coming, until it was too late.

Under this system, we know immediately. Buffer consumption is tracked weekly. If we burn through buffer in week one, that's a red flag in week one. Not week eight. Not at the deadline. Week one.

The business gets actionable information as quickly as possible. "We're consuming buffer faster than we're shipping. Either scope needs to be cut, or the timeline needs to extend, or something needs to change."

That's transparency. Transparency has to matter here, but what if it doesn't? False certainty might be more comfortable than transparent uncertainty. The prophecy lets them plan, the reality forces them to act.

If the business ignores the warning and pushes for the original date and the original scope anyway, the failure isn't the team's fault. The data was visible for weeks. The team kept shipping. The buffer got consumed. The choice to ignore reality was management's.

Getting the business actionable information as quickly as possible is the best the team can do.

For Mark

Mark, you've watched transformations fail. You've seen consultants come in with playbooks and leave when the company reverts. You've seen patterns that work everywhere and patterns that work nowhere.

I keep saying "this has worked before." But that's what every consultant says, right?

They arrive with their fence in hand, ready to replace yours. They never ask why your fence is where it is. They just know theirs is better.

Am I doing that? I see story points becoming prophecy, so I'm pushing to change that. But what if story points are serving a purpose I don't understand yet? What if the prophecy problem is a symptom, not the cause?

I've deployed the playbook. The same moves I've run before.

Am I adapting to this context? Or am I just another consultant who thinks understanding the pattern means understanding the fence?

How do I know if I'm solving their actual problem - or just solving the problem I know how to solve?