After reflecting on how recent assessment reports evolved, I realized that the process felt surprisingly familiar. Not because it resembled traditional report writing. Because it resembled Agile software development.
The Waterfall Model of Reporting
Most report writing follows a waterfall mindset. The process is typically assumed to be:
- Gather information
- Analyze findings
- Draw conclusions
- Write report
- Review report
- Deliver report
The underlying assumption is that understanding precedes writing. First we figure out what we think. Then we document it. Writing is treated as the final step. The report becomes a container for conclusions that already exist. This model feels natural. It is also how many assessment reports have traditionally been produced.
What Actually Happened
My recent experience was very different. The report did not emerge from a completed analysis. The analysis evolved together with the report.A finding would be challenged. A recommendation would be reconsidered. An alternative explanation would emerge. A new perspective would change the interpretation. The assessment model itself might evolve.
The report became less of a documentation activity and more of a learning process. The conclusions were not fully understood before writing began. They emerged during the process.
A Familiar Pattern
This should sound familiar to anyone who has worked with Agile software development. Traditional software development assumed that requirements could be understood completely before implementation started. Agile challenged that assumption.
The Agile insight was simple:
- Understanding emerges through iteration.
- Requirements evolve.
- Design evolves.
- Architecture evolves.
- The product evolves.
- The team learns while building.
The final solution cannot be fully understood at the start because the learning happens during development.
The Same Principle Applied to Reporting
I increasingly believe the same principle applies to assessment reports and other forms of knowledge work.
The traditional reporting model assumes:
Understand first, write later.
An Agile reporting model assumes:
Write, challenge, refine, learn, and repeat.
The report becomes a vehicle for exploration rather than documentation. Each draft becomes an experiment. Each critique becomes feedback. Each revision increases understanding. The objective is no longer to document existing conclusions. The objective is to discover better conclusions.
AI Changes the Economics
Historically, this approach was difficult. Each review cycle required significant effort. Feedback was expensive. As a result, most reports received only a limited number of iterations.
AI changes that equation. Ideas can be challenged immediately. Alternative interpretations can be explored continuously. Reasoning can be stress-tested throughout the process. The number of feedback loops increases dramatically. What was previously impractical becomes routine.
A Working Hypothesis
This leads me to a hypothesis:
Reports should be developed the way Agile teams develop software.
Not through a sequence of analysis followed by documentation. But through continuous cycles of exploration, feedback, learning, and refinement. The report is not the final step in the thinking process. The report is part of the thinking process.
Perhaps the most important lesson from Agile was never about software. Perhaps it was about learning. And if that is true, then assessment reports, strategy documents, presentations, and even books may benefit from the same principle.
They are not written once understanding is complete. They are iterated into existence.