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/