Producing Acceptable Documentation

Agile was developed to help developers deliver a more acceptable product in a more reasonable time-frame. Agile was not developed to get programmers out of documenting the development process entirely. All because agile values certain things over others, such as working software over documentation, does not mean they that completely shun documenting anything. The key is to generate just enough documentation to where delivering software is your primary focus yet the project’s documentation is barely sufficient.

When the agile manifesto was originally created, it entailed a list of principles. It is in these principles that working software is deemed the proper measure of progress. Originally documentation would be the measure of progress, because everything that was ever done was documented. Another principle states that you should meet the customer needs in the form of early and continuous delivery of valuable software. A portion of these principles are aiming to emphasize that agile is a big advocate of rejecting documentation of a measure of progress.

This is an important emphasis of agile because agile was designed to respond to change. If documentation is your sole measure of progress then you’ve got to document everything you do before you can advance in the project further. If any changes are to occur then documentation must be changed, often retrospectively as well. While these changes are occurring precious time and money is being lost that could be investing in producing working software.

One of the biggest disadvantages to prioritizing documentation over software is that a big change could occur, possibly even making the project fail, and code/documentation might be tossed. Then the code could still possess value while it’s almost guaranteed that the documentation will possess no possible value. The code that was developed in the little time before the major change occurred could be used in a different project, or part of software to create a smaller product. Documentation without software has a very small chance to hold any business value if the software is never to be developed.

When agile teams actually document, they should document on a consistent basis and not wait until the end to develop a large final draft. If documentation is never given enough attention and procrastinated too much then poor documentation will be developed as a result. Another strategy agile teams should implement is making all documentation collaborative. This tends to assist with everyone staying in the loop about what is going on with the project. Often agile team members can get very busy with their own tasks and forget about how their tasks are affecting the entire team and project.

In summary documentation for agile projects should help individuals outside of the project better understand the work. Documentation should not be providing insight for the project, if written insight is to be created a report will be generated. Agile team members should be focused on their deliverables and not bottle necked by documentation, however documentation should never be the reason a project doesn’t do as well as it should.

Work Cited:

"Agile at Work: Planning with Agile User Stories." www.lynda.com/Business-Skills-tutorials/Producing-acceptable-documentation/175074/387224-4.html. Accessed 12 Nov. 2017.

Image Provided By:

https://easternpeak.com/blog/agile-documentation/