Channels ▼


Survey Says...Agile Has Crossed the Chasm

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 Spec—High Level 3.66
Defect Reports 3.61
Velocity (Metric) 3.56
Requirements Spec— High Level 3.52
Use Cases—Light 3.52
Test Plan 3.39
Burn Down Chart 3.35
Paper Models 3.22
Use Cases—Detailed 2.96
Requirements Spec— Detailed 2.90
Arch Spec—Detailed 2.88
Gantt Chart—High Level 2.70
Gantt Chart—Detailed 2.21

Table 3: Effectiveness of various work products on agile teams.

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.