Sure, though can we please not pretend that Agile introduced the concepts of talking to other people between the start of a project and delivery or of trying to get everyone involved on the same page?

If you have shared understanding, that is to say everyone understands the end goal it is easier to have less documentation.

But how do you know that everyone really does understand the end goal, and crucially understand it the same way, if you haven’t fully defined what that goal is? If you have fully defined it, great, you have a spec.

If you work in an old school environment where you get work packages and you just have to do the work. You will need more documentation. simply because you can't ask any questions to the requestor.

Has any such environment actually existed since before most of us were born, though? This seems like the big waterfall straw man again.

Value is not only measured at the end of a total delivery.

Agreed.

So for instance your car example. It could be really valuable to deliver the ABS part of the software to test it and any other safety and control functions.

Yes, it could. Then again, modern car control software integrates numerous effects that determine the actual response required from different mechanical components to driver inputs and environmental factors, of which ABS is just one case. What ultimately matters is that the overall system is working properly by the time the car is ready to drive, and everything else is a stepping stone towards that end goal.

If building incrementally and working on the ABS in isolation allows for early testing and feedback and that in turn allows for more efficient correction of any defects in the original implementation, yes, absolutely, that has value.

On the other hand, if that kind of isolation and early testing is unlikely to find important defects in the finished system, perhaps because it turns out that the way you build individual systems is fairly reliable and the defects mostly arise when integrating the different systems, and if building everything in isolation and then integrating later delays your overall progress and the time when you can start the integration testing, then the more isolated approach has actually cost time and money rather than saving it.

I want to emphasize that my point here isn’t about this specific example. It is that every software project has its own context and it is important to use a development process appropriate in each context. Sometimes, it’s OK to guess at what your software should do and see if it works out. The kinds of startups we talk about all the time on HN often do this, obviously with varying degrees of success. But I think we should recognise that the whole business model in that case is essentially built around permanent experimentation and high variability outcomes. It’s not a way to build better software as most of us might define the term. It’s a strategy of throwing stuff at the wall to see what sticks, which happens to be a commercially viable strategy for some businesses in the current economic environment, where the definition of “working software” is basically “software we can run that will make us enough money to continue”. Somehow, I doubt that is what the authors of the Agile Manifesto had in mind when they wrote that line.

Sadly I have seen work packages delivered to software teams without any context just specs. Sadly I have worked and seen projects that went down the documentation rabbit hole and spend years trying to come up with the ideal spec before any thing has been build. (and I'm not even that old). You would see that kind of stuff with in government but also large enterprise and even at mid sized companies. And it still exists today

I also have seen successful waterfall projects and I have seen failed agile projects (although those tent to fail faster and thus less costly)

The agile way is not the only way, there are instances that other ways of working might be better.

But for me personally the best work experiences where all companies that worked agile or where transitioning to agile. I worked this way (and helped in the transition) at companies ranging from scale ups to big enterprise.

A many a time I have had these same discussions with people at the beginning of a transition. Mostly people that never worked this way or had a bad experience.

My original comment on the Agile Manifesto, which seems to have attracted most of the responses I’ve read here today, was only intended to make the point that without knowing what you’re trying to build, you have no way to define whether or not you have succeeded. I therefore don’t think it makes much sense to talk about valuing working software over comprehensive documentation in general terms as the Manifesto does. You can only know your software is working to the extent that you know how it’s supposed to work in the first place.

The Manifesto is pretty explicit that “over” in the “over” statements means exactly what it says, and isn't a misspelling of “instead of”; the Manifesto very much does not claim that there isn't some degree of documentation that serves an essential role in defining and achieving correctly-functioning software and that that isn't instrumentally important.

I do wish, though, that rather than “over” statements with an explanation that “over” means “over” and not something else the manifesto had used something like “is/are served by” in place of “over” (with some light editing of the items on the sides to fit that structure):

  Individuals and interactions *are served by* processes and tools.

  Working software *is served by* appropriate documentation.

  Customer collaboration *is served by* contract structure.

  Ability to respond to change *is served by* planning.

like I said in the beginning of the discussing the manifesto reverenced to those type of environments.