Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, IT Project Management, Scrum
How much documentation is enough?
Network:783



"Working software over comprehensive documentation"

One of the Agile value that in my experience is misinterpreted. Working software needs maintenance, operational support. If for the build documentation may become irrelevant when the software is deployed in production fro maintenance and operational support proper documentation is still very important regardless of the approach used.
Is the support documentation part of the 'working software'?
Sort By:
Network:323



Yes, the support documentation is part of the "working software" and should be included as DoD.
Network:137



Hi there,
Of course your experiences were well practices. But I can contribute you a thing: this value does not mean we do not use any documentation. It advises us like this: do not "come out" too many paper works, focus time and our efforts on product developement, test, debug, ... Documentation is just enough for recording key things and to be used in the current iteration.
Network:783



Thanks Truc. I don't believe that Agile imposes testing and debug but rather seek quality assurance which is ensuring quality during the build process with the goal of eliminating the need for testing as a separate phase.
Network:2245



Stelia, different project and different scope require different documents the main thing to remember is not to over kill it.
If you are doing DOE then each result of the stimulus must be recorded that's the sensitivity of predefined requirements.
...
1 reply by Stelian ROMAN
Feb 04, 2019 1:50 AM
Stelian ROMAN
...
DOE is R&D in manufacturing I will be very interested in more details of an Agile software DOE project.
Network:149



You have to ensure it should not hinder teams progress. Agile says produce documents (not comprehensive but enough) that provides value at the end. Ideally focus should be working software(business value)

In a demo to the client, working software is important than documents.(no matter small or big)
...
1 reply by Stelian ROMAN
Feb 04, 2019 1:58 AM
Stelian ROMAN
...
Thanks. This is the answer that I was afraid of. On paper it makes a lot of sense. This is also what a Scrum/Agile trainer will preach. Reality, especially in large complex projects is different. For one finding the money require a Business Case and I will be very interested to see a 2 pages BC for a couple of million dollars. 2 Pages are more than enough to describe one or more epics and how much money you want. BC is project Documentation.
Then you have a "demo to the client" that works perfect (every good demo works perfect) and the client thinks that the job is done and they can have it next week in production.
That's where 'working software is important than documents' become blurry. A professional Operations team won't accept software without design documents, test results and sign off from the system owner.
Network:783



Feb 03, 2019 1:28 AM
Replying to Riyadh Salih
...
Stelia, different project and different scope require different documents the main thing to remember is not to over kill it.
If you are doing DOE then each result of the stimulus must be recorded that's the sensitivity of predefined requirements.
DOE is R&D in manufacturing I will be very interested in more details of an Agile software DOE project.
Network:783



Feb 04, 2019 1:41 AM
Replying to Milind Patil
...
You have to ensure it should not hinder teams progress. Agile says produce documents (not comprehensive but enough) that provides value at the end. Ideally focus should be working software(business value)

In a demo to the client, working software is important than documents.(no matter small or big)
Thanks. This is the answer that I was afraid of. On paper it makes a lot of sense. This is also what a Scrum/Agile trainer will preach. Reality, especially in large complex projects is different. For one finding the money require a Business Case and I will be very interested to see a 2 pages BC for a couple of million dollars. 2 Pages are more than enough to describe one or more epics and how much money you want. BC is project Documentation.
Then you have a "demo to the client" that works perfect (every good demo works perfect) and the client thinks that the job is done and they can have it next week in production.
That's where 'working software is important than documents' become blurry. A professional Operations team won't accept software without design documents, test results and sign off from the system owner.
Network:233



The Agile values are often misunderstood. I often read/hear that Agile is the absence of planning, which is a complete misstatement of "We value responding to change over following a plan." Similarly, when the Agile Manifesto states "We value working software over comprehensive documentation," it doesn't mean no documentation, although a lot of people like to think it does!. It simply means there's more value in good software than there is in the documentation. It's like saying I value my car more than the owner's manual. There is definite value in my car's operator manual, but there's more value in the car.

The real question seems to be "How much documentation is enough?" The answer will vary, and will probably require collaboration with the customer (another Agile value). If you're building a web page, you should design it in such a way that users require no documentation. If you're building a new system for a bank, it's reasonable to expect you'll need compliance documentation both for the development team and the customer.

Certainly, the days of 500 page manuals for a work processor are gone. Large volumes of documentation are waste, and often an indicator of bad design or bad code. Similarly, if your team has to meet with itself or with stakeholders to decipher previously written code or designs, it probably indicates an insufficient amount/placement of documentation... or maybe bad code. A large number of user support calls may also indicate an insufficient amount of documentation or bad design.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Never hold discussions with the monkey when the organ grinder is in the room."

- Winston Churchill

ADVERTISEMENT

Sponsors