Incomplete, with high quality

In a presentation I gave at a past job, I summarized the Agile philosophy as: "Deliver business value to real users faster."

Maybe because I came up as a developer around the time of the Agile Manifesto, I feel like I have Agile in my bones. I've never known any other way of looking at the process of creating software.

Get valuable, well-tested things to real users as fast as possible.

If you work for a company that makes hiking boots, then it's a big problem if you ship a product that has no soles attached. Hiking boots without soles are useless.

But hiking boots of the wrong color are useful. We can change the color of future iterations of the product if people like the hiking boots, but don't like the color.

Hiking boots of the wrong color are better than no hiking boots for someone who wants to hike, while hiking boots without soles are useful to no one.

When it comes to software, poor quality and incompleteness are not the same thing. All the hypothetical features we believe our users would want do not need to be present for them to get any value out of our work. The thing that we put out into the world does not need to be perfect, in fact, it would be weird if it was perfect.

I guess I'll be explaining this concept until the end of my career, but in software we must be okay with delivering the wrong thing quickly. Let's strive for making something incomplete, but with high quality.