Back to the Basics: Working Software

The next value pair starts fairly easily with working software.

Working Software
over
Comprehensive Documentation

 While there are nuances that can be debated over it doesn’t take long for the act of debating them to devolve into little more than meaningless mental exercises. Changing this from “Working Software” to “Complete Products” may help when trying Agile in non-software environments.

The second half of this one, comprehensive documentation, this is the one that most people miss the meaning of when looking at Agile. This one could be debated for a long time. Unfortunately the only generic “right” answer for what it truly means is “it depends.”

Agile started with software development. As such working software was an obvious choice for the short list of top values. It is worth noting that in the end “Working Software” is a product delivered to a customer of some kind. This value and it’s implications can be re-worded for any industry. For brevity’s sake I will stick to the Working Software definition. As the second value listed it becomes clear that while software development was the main job of the team creating the manifesto, they valued people over the software they were building. For that software they valued having it working though. The real question becomes, what is “working” software?

In general working software delivers the value it promises without problem. The actual value it needs to deliver is up to the product owner. The development team designs and develops software, but the product owner defines and measures value. Some best practices for delivering the required value are to do it in small pieces as often as possible. In general smaller pieces of development work are going to be built faster than larger ones. They will also be less likely to have defects. When defects are found they usually are easier to fix.

The more difficult part of this value pair is Comprehensive Documentation. Software Documentation is not dropped. It is less important than the software itself. The level of documentation and what it looks like can vary wildly and still be in line with this value.

There are still teams in regulated industries that feel Agile cannot work for them due to a lack of documentation. This is simply not true. Part of the value required from the software for these industries is the documentation. For their software to be considered working it needs to have the proper level of documentation. Any documentation above that is values less than getting to that point. Any documentation below that is not providing working software.

Without regulation the waters can become a little more murky. There may be corporate standards that need to be adhered to. Perhaps the users require there to be a certain amount of training materials provided. It could even be that the developers want to create a documented history of the product. None of these is wrong. The right amount of documentation for an Agile team is the level that team needs to provide proper value. This can be in the form of documentation describing the code, the user needs, the application, or none of the above. Some programming methods result in code that seems self-documenting. (I would argue that no code is self-documenting over time, but that is for a different post.) Comments in code may be enough documentation for some teams.

At the end of the day this value pair is about providing value. A development team writes software for others to provide them some kind of value. Just as the food at a restaurant is more important than the menu, software providing value is more important than a document about the software. However, just as the menu is also important documentation in software development is also important.