Don't chew the developers' food

Very little of agile will survive, just like very little of waterfall survived, just as there are scant echoes of OO and every other local toolset that became an infamous global phenomenon.

We're still 3–7 years from agile's extinction. Basic, boilerplate, thoughtless agile lumbers on, and will persist until a future paradigm collapses the current deficiencies, inefficiencies, and loathings into a bright and simple new scheme.

I don't have a new paradigm to propose. In my engineering group, I run a very stripped-down version of agile. We're broadly considered the most productive team in our division — by a large margin. When asked about it, I say "we barely run agile". When asked what I recommend, I say "keep only the parts of agile you'd absolutely need to reinvent if you got rid of agile altogether".

I actually believe in agile, by which I mean only: the agile manifesto and its spirit of responsive minimalism. I also love the scrum backlog — catalogs of crap ideas and great ideas all reduced to a sorted bullet list. I believe in daily standup, the opportunity to rapidly mind-meld with brilliant people who are on fast trajectories of creative output.

I look suspiciously at every other aspect of the agile-scrum industrial complex. Overthought planning, underthought standup, thoughtless retrospective, and the unending buzzword b.s. of sprints and points and even iteration — these are the sources of cringe and waste that plague the productive class in this field.

My goal is to make work 100% about work, and as close to 0% paperwork as possible. (I use the terms agile and paperwork interchangeably.)

There's one belief I have that fixes the semi-lousy agile present and shows the way to a bright post-agile future. One phrase.

Don't chew the developers' food.

Sprint Planning

The biggest culprit is sprint planning. The multi-hour ordeal that never ends. Never. Ends. Drag 5 to 10 people or more into a single room, and think through every story until it gets a planned implementation and story points. Repeat every 5 or 10 days.

Ad-hoc Planning

At sprint planning, you'll see most developers tuned out on their laptops, while each story is taken through a gauntlet. When it comes time to speak to a particular story, a developer is typically asked to think through most aspects — the behavior of the new function, its architecture, its output, error states — often around the first approach that came to their mind.

It's a ripe time for debate, which can go on for quite some time. I mean… the dev had just thrown out one idea. The time to sand off all rough edges is exactly when the tree fell. Devs sense this farce instinctively, and will express it via gripes and bikesheds.

But we don't like any disharmony in team, so the conversation will continue until it ends. A 2nd and 3rd approach will be discussed and refined — all while consuming the time of the entire team, days or even whole weeks before the actual work will begin.

This what I call chewing the developer's food. Solving the work before doing the work. Doing the thinking before having time to think.

Plan-ahead Planning

This won't happen for every story — because by the 3rd or 4th go-around, the team gives up, has had enough, and will say just enough to escape the room.

So some teams take alternative approaches. Acceptance criteria can be pre-written before the meeting. The outcome of the story is predetermined, and the developer is asked how they will get to this result.

Do we remember why we got into this field? Was it to become a builder who had the end state thought out for them?

But voila, after 15 years of this, we have a generation of "modern" developers have been trained to need exactly this. How unhappy they are when the food is not already chewed for them.

We have developers, good engineers, who intimately know systems. They built them with their minds. They know what is adjacent, within reach of existing code — aka: low-hanging fruit. They know what is near and what is far away.

Even if you have high-level acceptance criteria, very frequently developers will have alternative thoughts on what can and should be achieved. If you're a poor product owner, you'll insist on your way most of the time.

It's so much better to collaborate. Define a story as a quest, set in an open world — watch what your talent does with it.

Devs love when you share a vision. They love it less when they are asked to fashion a widget. No one learns multiple languages and mindsets so they can work in a widget factory. By breaking down a vision into widgets, you are chewing the developer's most delicious food. Whatever wildlife the mother bird ate from across the terrain, the baby's food all tastes like the same thing.

Story Points

Why does all this food-chewing take place? Typically it's in service of the story point.

For a new creation, a developer is expected to provide an approximate construction time — typically for something they haven't done before. So they are asked to walk much of the journey in their mind, until they can spot most of the rabbit holes they expect to fall into and climb out of.

They express the expected duration of the journey in story points. Why? For a velocity — which in theory prevents a team from taking on more work this sprint than they should.

In practice, it's so that developers provide little screw heads to their scrum master / manager / team lead, who can turn that screw as hard as they please. If the lead wants all stories done by sprint end, they can have it — after all, this work "should" fit in the sprint.

Story points were rejected by their very creator. I consider them evil. Why? Because velocity is tautologically tied to time — ultimately it's a measure of everyone using a time tracking system. A sprint is just a time clock, and stories are the punch cards, just of different sizes. Story points ultimately boil down to hours, velocity is just a percentage of person-hours in a period. If we sized everything perfectly, points would simply sum to the number of hours we're already working. Tautological. Pointless.

The only way to accurately predict story points, and hence to provide a "correct" velocity, and do our jobs "right" by delivering all the points in a sprint (god these words), is that each developer must closely pre-chew all the work in the sprint. The more we fail to chew, the more volatile our estimate is, the more we're at risk. Evil.

Do story points and velocity help us deliver the right software? In absolutely no way. Story points and velocity are inherently antithetical to the agile spirit — which is: disrupt anything that gets in the way of delivering the right software. In Lean terms, story points are waste.

Stop using them today.

If you really want a correct estimate from a developer about how long the work will take, ask them when they're 80% done. The next best time to ask is when they're 50% done. No other time will get you a useful answer. Maybe stop asking and leave them alone. Have fewer ceremonies and they'll get done faster.

Retrospective

Retrospectives are where we talk about the regret about everything we chewed — we get to taste it again.

Retrospectives should be about one thing — figuring out how to do less chewing.

Standup

Reprising the previous day's work is rechewing food, previewing today's work is prechewing food, and it's almost never useful for anyone.

You get the idea now. Use standup to talk with fellow humans. Be human.

Conclusion

All the diatribes above are slight strawpersons — most teams have the good sense to tune down the obsessiveness that can go into a full story definition, and to not bother specifying the full exact end-state.

But that actually demonstrates my point — by failing to meet industry-standard agile ideals, we save critical time and decrease developer unhappiness, and end up producing more.

Why not go further? Dispense with as much agile as possible.