How do you prioritize working software over documentation?

Working software represents tangible progress. It's not just lines of code but a functional product that brings your vision to life. By focusing on working software, you enable early validation of concepts and ideas. Users can interact with the software, providing valuable feedback and insights. This iterative approach minimizes the risk of building features or functionalities that don't align with user needs.

Yes, this explanation is spot on as to why working software is preferred over comprehensive documentation in agile development. It should be noted though that constant releases are not always advisable nor realistic to do this so frequently. It will depend on the nature of the project, external customers, and internal stakeholders.

Prioritise by value. Working software usually comes top when you do that, but sometimes (rarely) we need just a little documentation to achieve the value we should get from delivering working software.

And more. It shouldn't be called "working software" unless it meets at least some of the needs of the customers and users. And ideally should be delivered highest value increments first, in terms of those needs.

The biggest mistake most teams make is they’re stuck in a SDLC mindset, producing project related documents for the development team, which is mostly useless once the project is done. The people that need good documentation are the ones maintaining and using the software going forward. Put yourself in the shoes of the person that IT will outsource maintenance to in five years that has never even heard of the software before and figure out the minimum amount she needs to know to maintain and/or make small updates to it.

We once measured (by page access on the website) who and how often our documentation was read. We found it was accessed rarely and chiefly by its original authors. We stopped writing documentation. Treat each need for documentation as a failure to avoid the need for documentation. Likely you won't eliminate all the needs, but much can be eliminated.

My experience shows that the developers prefer to look directly into the code in case of doubts. They don't like to read the documentation or even watch the recordings of knowledge transfers. They prefer live experience. In case your team is more or less stable, you do not need to invest a lot into the documentation. Also, if the product you are developing is in it's early stage, the documentation is extra, as it may never fly.

Documentation has to be re looked as code comments, workflows and DFDs too. Since majority of the code is written towards migration of features from one platform to another- angular to react, monolithic to micro-service based, maintaining existing applications with new features, patches and bug fixes etc - it becomes really necessary to have documentation.

How do you know when a document is needed? One way: You know the name of a person who needs to read it. Like, the name of an actual person. Marketing or sales or your internal customer stakeholder can give you a name. And sometimes the name might be someone in operations or someone on another team. Or, maybe your own name. How do you know the document is just enough information? Ask that person.

Documentation is actually the most challenging part of software development - IMO. Who is the owner of the document i.e. who is responsible for keeping it/them updated? If you ask anyone on a development team or who is involved in the project, you get everyone to point the finger at others but in fact, everyone is responsible. Sound familiar? Just enough document is what most people try to do but who defines that it is enough? So in essence, a document should be within well-defined scope and audience. Authors must be held accountable for keeping it updated by the project manager, tech leads, or program manager. The document must be a live document and evolves along with software.

Read the "TAGRI Principle" - there's not enough room here to give an adequate response other than to say almost all documentation is over-valued. Much of what is considered "essential" is never read other than by its author. One internal experiment we did with online documentation: over the course of a year only 40% of it (by page) was read by anyone else but the author.

The alternative to documenting things is to re-create the information when it is needed. If we accept that such an approach is expensive when information is needed, we should also accept that we save much cost and effort by not creating documentation that turns out never to be needed. Understand that balance. In a sweeping generalization with all the usual caveats, what costs is creating the information the first time. Re-creating it is always cheaper because there are always breadcrumbs to be found.