What’s half of it?

At the heart of iterative and incremental delivery, lies the ability to make things smaller. We want to make things small, because we value optionality. We don’t know that we will want to — or should — keep building “the thing” six months from now, so we make sure we can make new decisions often.

As a first step, simply cutting things in half is a good path towards this. We can keep asking the question until we’ve reached the “smallest useful half”. Obviously, simply cutting stuff up in halves won’t make much of a difference until the halves themselves provide some value. That’s the follow-up of this question — “what’s a useful half?”. Gradually this moves the conversation toward making smaller incremental versions of the bigger thing.

Inevitably we’ll encounter some counterarguments:

• “Why bother chopping it up into small pieces? It’s way less efficient.”
• “What’s the point of making a crappy version first, instead of the proper version?

Here are some responses:

• Have you ever experienced that priorities change, leaving you with a half-baked useless pile of code slowing you down?
• Have you ever experienced that halfway through the project, it becomes obsolete because a new technology emerged that solves the problem much better?
• Have you ever experienced that some of the stuff you thought was important early on, was never used and is now referred to as “Technical Debt”, and you need to pitch hard to get the time needed to remove it?

Efficiency under uncertainty is deceptive. We can look back and see how we could have been a lot more efficient, but that’s the hindsight bias fooling us. In software product development we rarely know up front what is the best way, what will be valuable, what will change and what will cause problems. We should still have grand ideas, bold ambitions and audacious goals, but we need to limit the cost of being wrong. The best way to do that is to incrementally build better versions of things that actually work. Much of that involves refactoring and rebuilding, which is why I really like the old saying

“Optimise for Speed of Change, not Speed of Work”

I’ve found asking “What’s half of it?” to be a very useful question to begin exploring the path toward delivering value with less risk, more innovation and more resilience.

Variations of this question:

• “What’s the 2-week-version of this?”
• “If you cannot continue after a month, what value will have been created up until then?”
• “What can we show in 2 weeks that will let us and our stakeholders know if we’re on the right track?”