Ship usable software early

I’ve recently experienced quite a lot of resistance towards the “The Agile Movement”¹. The word “Agile” even ranks third among the most hated business-lingo in a survey done by the danish magazine Djøfbladet among 4.053 of their readers². And that is probably completely justified. I’m sure a lot of people have deep frustrations from running what they thought was agile projects. At the same time, I think there are some wisdom to be found in the Manifesto for Agile Software Development (despite the obvious lack of representation among the authors).

That’s why I’ve decided to write a short tribute to each of the 12 Principles behind the Agile Manifesto. And this is the first in this series.

The first principle goes:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Let’s bisect this, and see if we can figure out what the essence is. First, “Our highest priority” seems obvious. Skip that. Now, “satisfy the customers” sounds like something only a consultant would say. Gone. The word “continuous” seems implied if we deliver something incomplete early. That’s out. Finally, “valuable” feels a bit vague. Can we clarify this a bit?

So maybe, the first principle behind the Agile Manifesto, could be boiled down to:

Ship usable software early.

So, why is this good advice? Why not just wait until everything is done and deliver all the valuable software at once. This is how it works in so many other fields. Construction for example. I can’t imagine how early and continuous delivery would look like when building a house³.

When building software, we do have the luxury of getting something usable into the hands of people very early in the process. We can let real people use the thing we’re building before it’s done. Let them feel it. See if it has life⁴.

I often find, that it’s only when you use the thing you’re working on, that you can tell if it is right or wrong. “Is this what I think, this particular feature should do?”.

The feedback you get from having actual people actually using your software is invaluable. The earlier you can get this feedback, the better.

There is a catch, though. If you give your customer⁵ a chance to evaluate their product, before it’s finished, they might change their mind about what they want it to do. This can be challenging. Both for you and for them. Especially if they already spent a long time specifying exactly what they thought they wanted 🔮. And maybe you two even spent a long time negotiating a contract based on that specification.⁶

But what if you stop seeing the changing requirements as a problem and start viewing them as an opportunity? This is exactly what the second principle behind the Agile Manifesto is all about.

“The Agile Movement” is quite a broad definition. I don’t mean anything specific with it. ⤴
In June 2022 the danish magazine Djøfbladet made a survey among 4.053 of their readers, asking “What’s the worst word at work?”. The danish translation of “Agile” came in third. Here is the article: I har stemt: Her er det allerværste ord på jobbet (in danish) ⤴
I’m aware of my own incompetence here. It might make perfectly sense to deliver buildings early and continuously. ⤴
In this context “life” is used as the fitness criteria formulated by Christopher Alexander in his book Notes on the Synthesis of Form. ⤴
The word “customer” is used in its widest possible interpretation here, and I use it to refrain from using the word “end user”. ⤴
I often wonder if this 🔮 is the reason why so many big software projects fail. ⤴