Agile Myths: If we are doing Agile, we don't need documentation.

Expressing the view that documentation is unnecessary in software development is blatantly untrue as well as unprofessional. Documentation is a necessary and valuable element of software development and always will be.

The agile manifesto places an emphasis on the delivery of valuable, working software whilst advising against unnecessary, comprehensive documentation in favour of producing necessary, valuable documentation.

In other words, we don’t want to get caught up in producing reams of documents, we want to focus on producing exactly what is necessary for a customer or end-user. Nothing more. Nothing less.

A lot more people who are using Agile don’t work with software, so let’s incorporate a working product into the equation.

Agile recommends that you deliver a working, valuable product to a customer and iterate on that OVER getting bogged down in unnecessary documentation and administrative quicksand.

We need to produce something valuable at the end of each sprint, which allows a customer to review and validate that it does meet their requirements or enables them to do the job that they need to.

Once that is done, focus on producing the necessary documentation to support that product. Keep it simple. Keep it effective. Limit the documentation to what is necessary to enable the product.

Simple.

Complex environments.

When we build software, we know we are dealing with uncertainty and complexity. We know it is hard. We know it takes a lot of effort. We are solving complex problems and producing complex solutions.

It’s hard.

We know that we don’t have 100% clarity on every tiny detail of the problem, and we know that we must navigate complexity and discover the best possible solution.

So, it is unrealistic to expect that people know 100% of the requirements upfront and can simply check boxes against a predetermined list. It doesn’t work that way. This is why we can’t produce comprehensive documentation upfront.

We simply can’t know what we don’t know, and as we discover the answers and develop the solution, we update the documentation that accompanies the working product and ensure that it fulfils the client’s requirements.

If you attempt to write the requirements upfront, you may discover a better solution or more valuable path to follow, and so you are going to end up rewriting the documentation as a consequence.

That doesn’t contribute value to the customer or the organization, so you shouldn’t attempt to predefine the entire solution and document that upfront.

It’s counterproductive.

So, our focus is on building working software and products, and as we validate that this meets the customer requirements, we attend to the documentation to ensure it is relevant and up to date.

Documentation that is relevant to your industry.

I’ve worked across a wide variety of industries.

• Energy
• Pharmaceuticals
• Healthcare
• Defense
• Oil and Gas
• Software
• Finance
• Government

And so forth.

Industry specific documentation and solutions

And I can tell you that each industry has it’s own, unique requirements in terms of documentation because in some of these instances, it truly is a matter of life and death. In other instances, you only need to focus on what is necessary.

So, apply the relevant governance protocols for your industry and use that as a measure of what is necessary for the product or feature to be considered done. Completed in full.

I’ve witnessed Agile working incredibly well in these environments, and the documents are updated in an incremental and iterative manner. There is no need for comprehensive documentation upfront.

Updating it as you make progress is more than sufficient.

Teams are creative in how they provide the documentation too.

In some instances, a video library makes sense. In others, a wiki is far more valuable to clients. It doesn’t need to be reams of paperwork, it could be an incredibly creative and collaborative approach to discovering the best way to support your clients with the information they need.

So, in summary, it is a myth that agile doesn’t value or need documentation. It is instead a necessary and valuable element of software development; it just doesn’t need to be comprehensive.

About Advanced Product Delivery

APD offer private, tailored training courses as well as business agility and coaching. Our public training courses are delivered by practicing Agilists: Product Owners, Scrum Masters and coaches who are expert trainers and facilitators.

Whether you are looking to become a #scrummaster or #agilecoach, we have a range of internationally certified and recognised #agiletraining courses that are perfect for you. Visit https://www.apd.coach/training-courses/ for more information.

If you are looking for professional, deeply experienced and skilled #agilecoaches and #agileconsultants to help you transition from traditional #projectmanagement to #agile #productdevelopment, we've got the ideal team to help you make that transition a success. Visit https://www.apd.coach/about-apd/ to find out more about us.

If you have identified Lean Agile Procurement as a great opportunity to enhance #agility within your organization, visit our Lean Agile Procurement page on https://www.apd.coach/training-courses/lean-agile-...

#agile #scrum #agilecoach #agileconsultant #agiletraining #agilescrumtraining #scrumtraining #scrumcertification #scrummaster #productowner #leanagileprocurement #apd #businessagility #organizationalagility #productdevelopment #projectmanagement #agileprojectmanagement #agileproductdevelopment