Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.

The seventh Principle of the Agile Manifesto reads:

Working software is the primary measure of progress.

On the surface, this appears like a well-worn and overly trite axiom. Who wouldn’t agree that working software should be the primary measure? What else could there be?

Enter the software-industrial complex!

Hold My Beer

Points, epics, velocity, backlogs, bug counts, test coverage, pull request review time … there’s no end to the things that might “act as proxies” (read: distract) from the truest measure of progress. It’s human nature to measure progress in order to measure progress.

Let me be clear, velocity and all those other KPIs hold value. They give us insight into the process. They help highlight where more attention is required.

But ultimately those measurements can’t save us. At best they are second order metrics to whether the software actually functions.

Just Add It to the Roadmap!

I once worked at a global software company where I found out coworkers knowingly lied to a client to placate them about whether a desired feature was coming (or not!) in the product roadmap. While that is a terrible thing to do to a client on many levels for many reasons, the worst thing it did was deny that client agency in finding working software — or encouraging them to bring that working software into existence themselves.

Roadmaps can be hand-waved. Backlogs can be re-groomed. Standups can be glossed over. Progress reports can be exaggerated. Documentation can be overrefined. Tests can be gamed to pass. On and on …

EITHER secure credit card processing works for an online store OR their potential customers are onto a competitor.

EITHER the Enterprise Resource Planning system sends data downstream for a team of analysts to consume OR the analysts aren’t able to do their job.

No amount of “we’re working on it” will bring back that missed e-commerce sale. No amount of “just a few weeks more” will recover the lost productivity from a non-functioning application.

EITHER the software works OR we are not focused on the right priorities.

Code Don’t Lie!

Bad boy of the National Basketball Association Rasheed Wallace was known for taunting opponents by yelling  “[That] ball don’t lie!” after a missed shot.

It’s a brutal, yet simple ontological truth. There’s no lying about whether the ball went through the hoop or not. The same goes for working software. Code don’t lie!

Existence precedes Essence

For millennia, philosophers discussed which comes first: essence or existence.

Historically, philosophers thought essence — the truest nature of what a thing is or becomes — was determined before existence.

Then along came Jean-Paul Sartres and Sören Kierkegaard who argued that only through existence can individuals and their determinations unlock their “truest essence.” Existence precedes essence.

Could this also apply to designing and building software?

Minimum Existential Product

First we must build out a system in a simple way and then progressively add functionality. Existence.

Only through existing as working software, can an application and its product team find its way to an application’s truest expression. Essence.

Should we make the interface better?
Can we add that new reporting module?
We’ve added a new client; can the API include more endpoints?

That journey to essence is what people mean when they say “iteration.”

When it comes to software, I’m an existentialist and as best I can tell I work among a team of product existentialists.

A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.

Dr. John Gall, Systemantics

Does it Work?

Over my career I’ve had many people apologize for some measure of subjective ugliness of their software. Over the years I’ve learned to ask in reply. “Yeah, but does it work?”

Upon approaching any software — be it a greenfield application or a FoxPro benzene plume — that question must be the first and most important one we ask ourselves.

Maybe it is not built in the Hacker News fanboi stack du jour. Maybe the team’s branching strategy is a nightmare. Maybe it has heaps of technical debt. Maybe the UX should be tried in a court in The Hague.

… but does it work?

The signers of the Agile Manifesto knew the value of working software, knew how much effort goes into building a system that can adapt and grow with a business. They knew how big bang rewrites are often a mistake and why an iterative approach to replacing systems is usually best. We shouldn’t distract ourselves with the wrong measures of success or casually throw away systems that work. Instead, we should ask ourselves if our KPIs, OKRs, and goals are really measuring the one thing that matters… working software.