Agile Work Products
The survey also asked about the effectiveness of various work products, summarized in Table 3 (the rating strategy from Table 2 is used). It was interesting to see that the agile rhetoric around the importance of working software and source code was validated by the survey. More interesting, at least to me, was that developer tests and whiteboard sketches pretty much received the same score-developer testing seems to receive at least an order of magnitude more discussion on agile forums than does whiteboard sketching, confirming my observation that agilists sometimes fail to describe what they actually do in practice.
Work Product | Average out of 5 |
Working Software | 4.22 |
Source Code | 4.22 |
Developer Tests | 3.96 |
Whiteboard Sketches | 3.90 |
Iteration Task List | 3.87 |
Customer Tests | 3.87 |
Arch SpecHigh Level | 3.66 |
Defect Reports | 3.61 |
Velocity (Metric) | 3.56 |
Requirements Spec High Level | 3.52 |
Use CasesLight | 3.52 |
Test Plan | 3.39 |
Burn Down Chart | 3.35 |
Paper Models | 3.22 |
Use CasesDetailed | 2.96 |
Requirements Spec Detailed | 2.90 |
Arch SpecDetailed | 2.88 |
Gantt ChartHigh Level | 2.70 |
Gantt ChartDetailed | 2.21 |
There's clearly a loud message that detailed documentation (in particular, requirements and architecture specifications) have little value to add on agile teams. High-level architecture and requirements models, as promoted by Agile Model Driven Development (AMDD), do seem to be effective in practice, as do whiteboard sketches. I was surprised that paper models didn't seem to be as effective, although in hindsight, I suspect that had I asked directly about user-story cards, CRC cards, and paper UI prototypes, user-story cards would have done well. There's always next year.
On the project-management side of things, both detailed and high-level Gantt charts came in dead last, something our good friends at the Project Management Institute (PMI) should pay attention to. Task lists were very close to the top, an indication that agilists prefer simpler approaches to project planning. Burn down charts, for all the attention that the Scrum community gives them, don't prove as useful in practice as we would be led to believe, something I wouldn't have expected.