Date: Fri, 29 Mar 2024 07:35:42 +0100 (CET) Message-ID: <1155046954.17781.1711694142702@09e9d69a2016> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_17780_105255367.1711694142702" ------=_Part_17780_105255367.1711694142702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A document is considered = to follow the agile principle if it is valuable, essential, and created or = updated just-in-time. A documentation is created and maintained in an agile= way, if all its documents follow this practice.
Agile methods are not opposed to documentation, only to valu= eless documentation.
Michael Nygard. Documenting A= rchitecture Decisions. 15. November 2011
The agile manifesto states that running software is more valuabl= e than comprehensive documentation. So comprehensive documentation has valu= e. But there is no hard-and-fast rule of how much documentation does meet t= he expectations of all stakeholders. In order to get it right we need a cou= ple of rules for guidance, create valuable increments, and then iterate.
We categorized Agile Documentation as a practice and not as a p= rinciple. The reason for this is that the structure presented here is to co= mplex to be a principle= . One violated aspect of a principle is that it must not be further reducib= le. Therefore it needs to be considered a practice.
The whole site is dedicat= ed to the topic of agile documentation. However we consider this practice a= valuable tool since it focuses on the three main aspects to get started wi= th. In our view everything else on this site still applies to agile documen= tation, but the structure described here is simply the starting line for wo= rking on documentation with an agile mindset.
Agile documentation requires that each document is valuable, essen= tial, and created or updated just-in-time.
Teams need to determine the information needs of the stakeholders and pr= ovide the necessary information accordingly.
Therefore the first step for creating a document is the search for a sta= keholder. Better yet, stakeholders identify their information need by thems= elves and ask the team for documentation. So there is at least one stakehol= der required to justify the existence or maintenance of a single piece of d= ocumentation. This makes sure that at least one stakeholder values= the document or knows an audience that values it.
These stakeholders with an information need typically know exactly= what they need to know. This way the document can be adjusted to exactly m= atch this need. Create an essential instead of a comp= rehensive documentation.
Last but not least documentation quickly gets out of sync with rea= lity. Time runs forth and a document needs to be maintained to keep up with= the pace of time. Therefore it is wise to wait for creating documents unti= l they are needed. This keeps the maintenance costs low. In order to delive= r documents just-in-time, teams need to employ automa= tion and single sourcing to create documents quickly.
The following practices are related to this practice.
For more information regarding this practice please refer to: