How to Get the Real Value from Agile Methodologies – Part 2

Documentation Induced Comma

Documentation Induced Comma

In Part 1, I alluded to my belief that the use of a particular Agile methodology is less important than understanding and applying the underlying concepts. Understanding and application as opposed to a blind, paint-by-the-numbers mentality is why Agile seems to work for some organizations or teams but not others. Today we will explore an example of what I am talking about in regards to deriving value from the underlying concept behind a technique.

Does minimal documentation equate to more risk or less risk?

Consider the following tale of two managers, Annie and Trevor. Annie is a believer in the benefits of Agile. Trevor favors more traditional methodologies. Both believe that reducing project risk is a good thing and something that deserves more than just “lip service”. Annie believes that minimally sufficient documentation assists in decreasing the risk of missing deadlines or coming in over budget. Trevor believes that more documentation helps reduce the risk of missing deadlines or coming in over budget. Who is correct? Should we strive for more documentation or less? Before we head down a rabbit hole by trying to answer those questions, we might want to consider the purpose of documentation. Depending on the documentation you are referring to, some might say some common purposes include promoting a common understanding among stakeholders, meeting a legal compliance requirement, or surviving the unfortunate event of a key team member being hit by a bus. I would agree with the merit of any of those purposes, but what else should we consider that would make your time of reading this post worthwhile?

Getting the Value from Documentation

In my mind, the underlying concept of documentation includes the purposes mentioned above, but goes a little deeper. One underlying concept that is critical to keep in mind is having a satisfied customer. A big part of having a satisfied customer begins with understanding what they want and ends with giving them as much of what they want as time and money allows.

Documentation can be a tool to help form a common and prioritized understanding of what the customer wants. Documentation from an Agile point of view also takes into account the fact that things change over time. Sometimes customers clarify what they want as they understand more. Sometimes policies or processes external to a project change requiring adjustments along the way. If minimal, but sufficient, documentation promotes a common understanding of the customer’s needs and relative priorities, more time can be spent on implementation. If the concept of the satisfied customer is NOT kept in mind, it is easy to spend significant amounts of time on detailed documentation that might help legally defend against a disgruntled customer, but directly decreases the amount of time and resources that could be focused on functionality or value leading to a satisfied customer.

Stay tuned for Part 3, when we look getting value from Agile scope management…

 

“Software is usually accompanied by documentation in the form of big fat scary manuals that nobody ever reads. In fact, for the past five years most of the manuals shipped with software products have actually been copies of Stephen King’s The Stand with new covers pasted on.” -Dave Barry

Tags: ,

Post Author

This post was written by who has written 36 posts on Issue Tracking Software Blog.

Trackbacks/Pingbacks

  1. How to Get the Real Value from Agile Methodologies - Part 1 - March 9

    […] tuned for Part 2 when I share some specific insights to help you see beyond the Agile Voodoo rituals and get access […]

Leave a Reply