The 4 characteristics of agile ‘documentation’

Let’s face it, compiling reports suck. My earlier years as a project manager scarred me deeply where I was coerced into creating weighty project management plans, maintaining detailed registers and ensuring lengthy weekly project status reports were updated. My bitterness started to fade when I transitioned across to working on agile projects where the approach to documentation and communication was refreshingly different.

If I was asked to summarise, there are four big differences in how documentation is viewed and created in an agile organisation:

Lightweight — people in an agile organisation view documentation with a lean lens to ensure ‘just enough’ information is created to satisfy stakeholders. Similar to a new car, there is a depreciation factor with heavyweight documents and information becoming outdated and irrelevant, especially in environments with high change.

Visual — research indicates that humans process visuals much faster than words. In agile environments, preference is for visuals over words, colour over monochrome to help emphasise key messages. Take a product backlog - an agile artefact that allows consumers to interpret progress quickly and meaningfully, compared to a traditional and wordy requirements document.

Simple — agile artefacts are designed with simplicity at its core, containing only the relevant information that needs to be known at or around that time. Iterative design and development allow for emergent practices which drives the principle of simplicity. A short glance at a team’s release burn up provides a richer and quicker snapshot than a traditional project gantt chart.

Adaptable — because of their lightweight nature, agile documents can be adjusted to incorporate change easily. Change is embraced in an agile environment: a change is raised, followed by a conversation, which is usually followed by some change to the backlog. Now consider the same change being raised in a traditional project environment whereby a change request is raised and logged in some legacy system. This is followed by a lengthy approval period by a project manager who then finally approves the change. The amount of hand offs and people involved are wasteful and disempowering to the project team.

Live the agile values by being courageous

For those of you reading this who may be working in a more traditional environment where you spend excessive time creating, preparing and maintaining heavy documentation, my advice would be to be bold and challenge the status quo.

Why not consider these 5 tips to help be the agent of this change:

1. Collect data — creating a baseline is important — keep a basic spreadsheet containing the time you spend on those key documents that you believe could be leaner.

2. Quantify the results — after you’ve collected sufficient data, place a $ figure next to each document based on the number of hours you and the team have spent creating and maintaining the document

3. Conduct A/B testing — during the relevant sessions with key stakeholders, provide an alternative version of the document containing some or all of the attributes listed above and ask for quick feedback. Position this as though you are running a number of small experiments to determine if we can improve the way that we work.

4. Introduce small changes — avoid any big bang approach, so apply incremental changes to the documents, gain feedback and feed these learnings into future changes.

5. Build an army of passionate people — Why not find other enthusiastic change agents and start running a string of small experiments, and from there you’ll be learning and introducing positive change across your organisation.