What is “Working Software”?

We have for decades now been informed by the Agile Manifesto, and its four guidelines. Guideline number two is “working software over comprehensive documentation”. I’m sure many folks skip over this with no more than a quick nod of agreement (and a implicit interpreting of “comprehensive documentation” as “reams of useless documentation”).

But what exactly do we mean by “working software”? A quick trawl through the Internet finds little in the way of a definition of this term, nor any explicit explanations of the why – the value – of “working software”.

For me, working software is simply any software that is actively being used by customers (a.k.a. users) in their real jobs. Until and unless it’s actually being used for the core purpose for which it was built, no one will be any the wiser as to its fitness for purpose.

Who Benefits from “Working Software”?

Developers

Developers get to understand how close they came to understanding the customers’ needs. Assuming, of course, that the feedback loop from customs to developers is a closed loop, rather than having no feedback from customers, or any feedback that is provided falling into a hole or getting hopeless garbled somewhere along the line from customers to developers. In the latter case working software is a pretty useless and ultimately frustrating concept.

Customers

Customers get to apply the software in the context it was intended. By which I mean their using it to help them be more successful (whatever that might mean in any individual case). They’re reassured that the developers are attending to their needs (although not necessarily fully meeting them). By applying the software in their work context, they get to see its true nature and fit. And they get to tell their story, or at least a part of it. Folks find telling their stories cathartic (assuming they’re being listened-to).

The Producers

The producers (the company supplying/building the software) get to exercise their channels to and from the market, and to and from active users. Shortfalls in the clear communication of needs (customers -> developers), smooth deployments (company -> customers) and clear communication of feedback (customers -> developers) can be identified and addressed. In principle, anyways.

Other Benefits

“Working software” as defined above, promises other benefits, above and beyond those already mentioned.These additional benefits  include:

• Provides a definitive and unambiguous definition of what has been shipped/deployed, in a way that written requirements or documentation (one of the forms of documentation mentioned in the aforementioned Agile Manifesto guideline) simply cannot.
• Promotes interaction and collaboration. Not just via feedback on the final version, but all the way through the evolution of the product or service under development. (Assuming the product or service deployed is capable of supporting real users in real work).
• Early & regular delivery of value:
  Value to the customer / user (the growing utility of the product or service, as it evolves through numerous deployments and instances of real use).
  Value to the producers (assuming the producers get paid for each deployment + live use).
  Value to the developers (kudos and the joy inherent in materially attending to folks’ needs).
• Flow (assuming iterative deployments + live use).
• The Check phase of PDCA (hypothesise -> experiment -> compare proposed results with actual results -> draw conclusions )
• A valuable measure of progress (“how well are we contributing to the success of our customers?”)

What “Working Software” is Not

It’s not:

• “works on my machine”
• “passes the test suite”
• “runs in the test environment”
• “runs in production”

None of these provide the acid test of real users doing real work with the thing.

Proviso

As with most things Agile, the label “working software” misleads as much as it helps. I’d propose renaming it to e.g. “deployed product or service” but that horse is already out of the stables and far over the hills. “Working” is ambiguous, and “software” omits mention of all the other elements of the deployed product or service necessary to put it to real use (user guides, release notes, other documentation, training, support, etc.).

– Bob

Further Reading