Communications - April 2012

Simplicity, the art of maximizing the amount of work not done, is essential.

Some commenters on principle 2
suggested a project’s requirements
should change only at the beginning
of each iteration. Agile methodologies
aim to reduce waste associated with
“thrashing,” or progress implement-
ing a feature, stopping and starting
and maybe never being complete due
to constantly changing priorities. This
wasted effort can be reduced through a
rule stating that once a feature is start-
ed, it must be completed.

table 2. agile principles.

Continuous integration short iterations ( 30 days or less) "done" criteria automated tests run with each build automated unit testing iteration reviews/demos "potentially shippable" features at the end of each iteration "Whole" multidisciplinary team with one goal synchronous communication embracing changing requirements Features in iteration are customer-visible/customer-valued prioritized product backlog retrospective Collective ownership of code sustainable pace refactoring "Complete" feature testing done during iteration negotiated scope stand up/scrum meeting timeboxing test-driven development unit testing Just-in-time requirements elaboration small teams ( 12 people or less) emergent design Configuration management daily customer/product manager involvement release planning test-driven development acceptance testing team documentation focuses on decisions rather than planning informal design; no big design up front Co-located team team velocity requirements written as informal stories 10-minute build task planning Coding standard Kanban acceptance tests written by product manager pair programming Burndown charts Code inspections design inspections planning poker stabilization iterations

mean
4. 5
4. 5
4. 5
4. 4
4. 4
4. 3
4. 3
4. 3
4. 4
4. 3
4. 3
4. 4
4. 2
4. 2
4. 2
4. 2
4. 1
4. 1
4. 1
4. 1
4.0
4.0
4.0
4.0
4.0
3. 9
3. 9
3. 8
3. 8

Standard Deviation 0.8 0.8 0.8 0.9 0.9 0.8 0.9 0.8 0.9 0.8 0.8 0.9 1.0 0.9 0.8 1.0 0.9 0.9 1. 1 1. 1 1.0 1.0 1. 1 1.0 1. 2 1.0 1. 1 1.0 1. 2

3. 7

3. 6

3. 5

3. 4

3. 3

3. 2

3. 3

3. 1

3.0

1.0

1. 1

1. 3

1. 2

1. 6

1. 2

1. 3

1. 4

1. 5

Tier Five (mean 4. 1)

Principle 4 (standard deviation 1.0). Businesspeople and developers must work together daily throughout the project.

Principle 6 (standard deviation 1.0). The most effective method of conveying information to and within a development team is face-to-face conversation.

Principle 8 (standard deviation 0.9). Agile processes promote sustainable development; sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Concerning principle 4 several re-
spondents said that developers (often
seen as those writing the code) should
not be the only ones to work with busi-
nesspeople (a.k.a product owners).
Rather, the whole team, including user-
interface analysts, testers, project man-
agers, developers, and businesspeople
should collaborate. Others commenters
said, “Every day often isn’t realistic, nor
is it necessarily needed.”
Principle 6 was generally supported,
though some commenters said the “re-
quirement for face-to-face conversation
is a severely limiting factor for distrib-
uted teams, and it seems to be a genera-
tional issue as well.” In today’s connect-
ed world, synchronous communication
through instant messaging, Voice over
IP, and WebEx may effectively stand in
for face-to-face communication.

Several representative comments on
principle 8 indicating the commenters’
negative experience with relatively in-
tense iterations ad infinitum:
“Agile does not promote sustainable
development but increases the kind of
focus that leads to burnout”;

“Sustainable pace is extremely important, but we also sometimes have to slow down and think about things a little”;

“Emphasize scheduled downtime as
part of sustainable pace”; and
“The team should have dedicated ex-
ploratory study time that contributes to
its ability to produce innovation.”