3.4 Agile CDRLs and Delivery
One of the four agile manifesto values is that "working products are valued over comprehensive documentation". Many times this is viewed by the agile purist as a justification for not doing documentation. However, even in agile, there is a value for doing documentation. Documentation exists to support the development teams work in creating the product and supporting the product after release. Prior to looking deeper at agile content and delivery recommendations for CDRLs, here are some general considerations to keep in mind when determining the format, content, and delivery schedule for CDRLs within an agile framework -
"Just in time"
a. Document late (based on design completion) - Consolidate deliverable design documentation as late as possible (though can be iteratively updated) - better to have the stable concepts versus speculative ideas which are constantly changing as part of the agile framework and would require constant document revisions and submissions.
b. Document continuously (based on iteration) - iteratively update development related documentation (i.e. user guides) in parallel with development efforts to not lose critical ideas. A key concept here is the idea of a living document, which is discussed below.
"Just sufficient" - Sufficiency is defined by the document owner (provide the necessary useful documentation elements). Additional thoughts:
a. Provide the fewest CDRLs possible with the least amount of overlap (I.e. considering combining the Interface Requirements Specification (IRS) with the Interface Design Description IDD).
b. Better communication means less documentation (collaboration is key to agile - often a conversation between engineers can eliminate the need for a staffing document).
c. Working software does not eliminate the need for documentation - the software delivered still needs to be improved, operated and maintained in the future - documentation's value is transferring product knowledge gained in development to users, operators and maintainers or to new development personnel when contracts change.
"NOT Just Because" - Treat documentation as any other requirement that needs to be justified by the government document owner (since resources will need to be allocated to produce it). Documentation work efforts can then be prioritized within the product backlog based on the value it provides.
Agile is built to be fast and flexible, and the contents of the CDRLs must be able to keep up with this development framework. CDRLs should not be an after-thought - they must be incorporated into the process. In other words, we don't want big CDRLs that are out of date by the time they are published. We need documents which can be frequently updated based on the ongoing iterative development efforts. Updates for CDRLs should be provided incrementally by the team when it is fresh in their mind, versus producing documentation at the end of the release when much of the valuable information has already been forgotten. In the military, this is a mindset switch.
In order to maintain the current value of CDRLs, these documents should be flexible enough to keep up with an iterative update approach
(versus long periods of time between updates). In that case, the best methodology is to establish a system to enable CDRLs as "living documents".
This can best be enabled by re-thinking the methodology of delivery for CDRLs. By considering alternate digital delivery methodologies, CDRLs can be
more quickly updated and maintain their relevance throughout the agile development process.
One final note to this section is while Sharepoint or a shared drive may fulfill the CDRL requirements above, a further shift from the
traditional mindset is to provide appropriate dashboards or reports within an existing system to provide the CDRL information requirements.
An example of this is the Test Descriptions / Scripts. Executable test cases are normally already stored in a digital format within the test management software.
The following link is to an attachment which provides a more detailed list of CDRLs normally associated with a software development project.
The list contains the associated DID, waterfall description, agile recommended modifications, and normal delivery timelines
(i.e. are the documents delivered one time for the project, at specified design reviews, with a delivery, or on an as needed basis.