The three ways to deliver software

There aren’t many universal truths in delivering value via software. One of those truths is that there are only three fundamental ways to do it: EnMasse, Incrementally, or Iteratively.

En masse

We know exactly what to build… let’s build it all as efficiently as possible.

Flow: Design => BuildEntireDesign => Ship

Collaboration Style:

Handoff-heavy. Product usually defines the “Why” and that is handed off to design. Design decides the “What” or the solution to the Why/Problem. Then design hands this off to engineering, who begins working toward implementing the designs.

Hi-fidelity, low-cross-functional-collaboration, and often-unchanging deliverables are used to ensure a smooth and efficient hand-off.

What defines Done: Output / design lives in production

Culture: Great for teams that believe their pre-validation techniques completely and care more about efficiency than continuous value delivery. It is all about the Big Bang approach.

Incrementalism

We know exactly what to build… but let’s build it in small chunks so that we can deliver value along the way

Collaboration Style:

Handoff-heavy at the beginning… high-cross-functional collaboration at the end. Product usually defines the “Why” and that is handed off to design. Design decides the “What” or the solution to the Why/Problem, but in a lo-fidelity way. Then design partners with engineering to decide how to break up the work and deliver the smallest valuable chunks of work to customers.

Hi-fidelity, low-collaboration, and often-unchanging deliverables are used to ensure a smooth and efficient hand-off from Product to Design. Low-fidelity, medium-cross-functional collaboration deliverables are created and handed off to engineering (and ideally design). A plan of how to break up the work and what will be delivered when is created. Then the hi-fidelity and building work begins.

Flow: Design => DecomposeIntoShippableParts => BuildFirstPart => BuildSecondPart => BuildThirdPart… so on until design is complete

What defines Done: Output / design lives in production (though progress is shown by having partially-done milestones along the way)

Culture: Great for teams that believe their pre-validation is so good they don’t need to measure to see if it actually worked… but they do want to deliver this “predetermined value” continuously

Iteration =

Everything we do is to deliver value and learn. We only trust the results of real people having real problems solved using real working software.

Collaboration Style:

Requires the entire organization to agree to be focused on hypotheses that are based on changing human behavior (outcomes). High-cross-functional collaboration all of the way.

Strategy is defined in the form of objectives. These objectives are given to a cross-functional group of Product, Design, and Engineering who work to “build, measure, learn” their way to the outcome they are entrusted with.

The only deliverables that are of any value are: Measures that show the value we are trying to achieve and working software that show the progress we are making and the experiments we are trying.

Flow: Build => Measure => Learn => Decide what’s next based on the learning

What defines Done: Outcome achieved or appetite exhausted

Culture: Great for lean, agile, learning-focused cultures where the “value hypothesis” is only validated by customer impact outcome data

All three are fine approaches based on your context.

However, most SaaS companies will find exponential success by striving for iteration.

I personally worry about the over-confidence in the pre-validation of the other two techniques.

I’d rather approach everything as a test.

Regardless of which you choose, the most important thing is to choose. Once your organization decides which is its preferred style, confusion will be reduced.

Please do not conflate/confuse iteration vs incrementalism. Neither is better or worse, but they are very different. One aims at outcomes while the other aims at output. This distinction changes everything.

Frameworks don’t dictate the delivery pattern

• Lean can work with any of them, but was originally intended to be focused on iteration (I’ve worked in environments where it was nothing but a cover for En Masse… I say this to say, just because someone claims to be lean, doesn’t mean they will do the hard work of being truly iterative)
• ShapeUp can work with any of them, but at its core aims at Incrementalism, but the cycles are smaller (6-weeks) than most never-ending incremental projects.
• Scrum can work with any of them, but tends to be focused on Incrementalism or En Masse.
• Cagan’s take on Empowered Product Teams is built exclusively for Iteration.
• Agile has become a word that has no meaning