What Is "Working Software", Anyways?

When discussing fast feedback loops and continuous delivery, the question often arises: What is the result of an iteration? What is the artefact that is continuously delivered? The common answer is “working software.”

This terminology comes from the Agile Manifesto, particularly the value of “working software over comprehensive documentation.” But what exactly does “working software” mean?

The Misconception

In many cases—often intentionally—it’s misunderstood as barely running software and nothing more. This interpretation is especially common in established industries like manufacturing or automotive, where it’s followed by arguments about why agile or continuous delivery “won’t work here” and how such approaches are actually reckless. It’s often judged as something suitable for low-risk contexts, like web development, but not for ‘serious’ projects.

And based on that minimalistic interpretation, they might be right. It would mean putting the first working prototype into production and calling it a day.

As is often the case, the catchy phrase “working software” makes this misconception easy. Especially when it sits next to “responding to change over following a plan”—and traditional waterfall processes are all about planning—or “individuals and interactions over processes and tools,” where regulated industries often revere process.

But surely, “working software” can’t simply mean a hastily cobbled together, barely functioning piece of code. That’s not what the manifesto intended, is it?

Putting “working software” into context

A look at the Twelve Principles of Agile Software suggests something else. While it states that “working software is the primary measure of progress,” other principles highlight the following:

"Agile processes promote sustainable development.
Sponsors, developers, and users should be able
to maintain a constant pace indefinitely."

Development should be sustainable and allow for a constant pace indefinitely. This wouldn’t be possible if we were piling up technical debt and bugs. This directly contrasts with the misconception of ‘barely functioning’ software. Sustainable development demands automated testing and a high level of software quality to prevent the accumulation of issues that would slow down progress.

"Continuous attention to technical excellence
and good design enhances agility."

Here, technical excellence and good design are crucial. So, working software is not just a prototype—it’s something state of the art.

"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly."

Teams should aim to become more effective over time. If a team neglected testing, documentation, and other artifacts necessary for a release, they wouldn’t be meeting the true intent of working software.

What “Working Software” Really Means

In my experience, “working software” goes far beyond the literal interpretation. After each iteration, the software should be releasable. Achieving true releasability means meeting all quality criteria, fulfilling documentation and audit requirements, and ensuring that it could, in theory, be shipped. Many misunderstand ‘releasable’ software as merely being feature complete but lacking necessary testing or readiness. However, true releasability requires technical excellence, compliance at the point of change, a high degree of automation, and a strong Definition of Done—aka discipline.

Of course, since this is an incremental approach, tests, documentation, and architecture diagrams should only cover the current state of the software.

Focus on what you own and can influence

In some contexts, especially in existing brown-field projects of regulated industries, processes are as extensive as they are ridgid. Transforming organisation and teams towards a more agile interpretation of working software can be quite challenging, as the teams building the software are often not responsible for mandatory artifacts, processes, or even steps like testing. While these are far from ideal starting conditions, it is still important to start. Effectiveness trumps efficiency in these situations, e.g., even if regulatory requirements mandate a dedicated test departnment, the development teams ideally have their software tested before it is ’thrown over the fence’. This allows to get the transformation flywheel spinning. Waiting for another department or even multiple to create the ideal conditions almost certainly result in no change.

Conclusion

“Working software” doesn’t just mean that all the parts work individually—it means all the parts work together. Continuous integration and testing ensure that everything functions in concert. Software is only done when the rest of the application can consume it. If it’s just sitting on a branch or is currently unreachable, it’s still half-finished—not done.

So, the next time you hear the term “working software,” think of it as releasable software—including all the required artifacts for a complete release and all the necessary steps to make the next release (at least) as sustainable as the current.