Alistair Cockburn - Agile Software Development

With time, this should change, and as it does, I hope they will reduce the paperwork and increase the conversation. In the meantime, they need the paper.

Six Months Later

I present this methodology as it was constructed as the starter methodology. We would expect to see some drift over time, both as people thought up new ways of working, and as they drifted away from the high-discipline practices.

Michael Jordaan, CEO of eBucks.com, made these comments about the group's work habits six months later: "Obviously, when you left some disciplines survived while others did not stand the test. The survivors include the forthighly heartbeat with carefully planned cutoff times, which allows for developers and business owners to plan, testers to test rigorously and customers to be informed upfront of scheduled upgrades.

We discussed a three week heartbeat, but this was considered too long. More complex issues than can be solved in two weeks are run at twice the heartbeat (four weeks), but we still encourage incremental rollouts. The post-heartbeat meeting is strictly enforced and it has become one of the few times that I get to speak to the entire team. I have made quite a point of paying tribute to those involved in succesful upgrades. Hopefully this public recognition is motivating.

Whether you use Crystal or not, increase morale and communication on your project so that the people trade information a little bit better. This applies for any base methodology.

Mistakes are discussed and suggestions for improvements have been made at every meeting, supporting the learning culture we are creating. The quality of code going live has improved greatly as the testing team has a veto power, to prevent bad code from going live (and this can be embarrasing). The SWAT team, dedicated to eliminating live bugs have also made great strides in responding to customer and call centre queries.

Focus time is still adhered to (and we still ring a bell every morning at ten). If I go a single day without these two hours I now start panicking, so useful has it proven to be.

Some things that did not survive was the habit of posting current priorities/ work progress on a board. Maybe interruptions are less of an issue now, as people work from home or maybe relationships between business owners and developers have stabilised. Maybe people are just lazy.

Most developers have a maximum of three tasks at any given time, except for the two key people working on the back end, who may easily have a list of 15 each. Moreover they are still interrupted by live issues, which interfere with their completion of tasks and lead to much frustration by other developers and business. The issue here is lack of skilled resources. It is the age-old problem that training employees to assist, while undoubtedly the right medium term solution, takes longer than simply doing it yourself."

In those comments, what I notice with some satisfaction is that the team still uses the core elements of the process: heartbeat with learning, and have found ways to modify even that heartbeat to fit their needs.

I notice the discussion of talent and skills as being critical to the project, and I notice the drifting away from what probably was embellishment in the methodology.

Get your experienced developers at Level 2 in methodology design. If your project doesn't have anyone at that level, do two things: Study your base methodology.

Start holding reflection workshops so that someone Compare what your team is doing with the three gets up to Level 2 soon. methodology samples given in this chapter. Choose a few ideas to apply on your own project.

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactionsover processes and tools

Working softwareover comprehensive documentation

Customer collaborationover contract negotiation

Responding to changeover following a plan.

That is, while there is value in the items on the right, we value the items on the left more."

Seventeen advocates of lightweight development processes gathered in Utah in early 2001 to discuss what they might have in common, or if they would just agree to disagree. I was one of them.

We agreed that the word "lightweight" too much of a reaction against something, and not enough of a belief in something. Agreeing on the importance of being able to respond to changing requirements within the project timeframe, we chose the word agile. We agreed on the above four values and on a dozen principles to support those values. We agreed that we were not interested in agreeing beyond that. We nicknamed the group the Agile Alliance. This appendix discusses that meeting, the values and the principles.

The meeting happened at Snowbird, Utah, in February, 2001.

The 17 people were Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave "Pragmatic" Thomas. (If Dave A. Thomas from Object Technology International had been able to make it that week, we might have had two Dave Thomasses as signatories!)

Each person there saw their own version of the meeting. What follows in this appendix is mine (but I did pass this text in front of the others).

The reason we met was to see whether there was anything in common between the various light methodologies: Adaptive Software Development, XP, Scrum, Crystal, Feature Driven Development, Dynamic System Development Method (DSDM), and "pragmatic programming."

Kent Beck, Ward Cunningham, Ron Jeffries, James Grenning and Robert Martin brought their views of XP, along with their considerable other experiences and their own personal wishes.

Martin Fowler brought long experience in both XP and methodology evaluation in general.

Jim Highsmith represented Adaptive Software Development and ideas around the emergent properties of complex, adaptive systems.

I was there, protecting my interests in methodology-per-project and just-in-time methodology construction.

Jeff Sutherland, Ken Schwaber and Michael Beedle represented Scrum (Schwaber 2001).

Jon Kern of TogetherSoft represented Feature-Driven Development, the method described in Java Modeling in Color with UML (Coad 1999).

Arie van Bennekum, from the Netherlands, represented DSDM (Stapleton 1997).

Andy Hunt and Dave "Pragmatic" Thomas, authors of The Pragmatic Programmer, protected the interests of experienced programmers who have no affiliation to any one method.

Brian Marick represented the software testing perspective.

Stephen J. Mellor was there to protect his interests in model-driven development. He was perhaps the most surprised to find himself able to agree with most of what was said, and signed both the manifesto and the principles.

There were others who had been invited, and would certainly have contributed and signed, but those were the people who were there, argued, crafted and signed the agreements.

We hoped against hope that we would actually agree on something.

None of us was interested in merging the practices to create a "Unified Light Methodology (ULM)." Given the individualism in the room, it was actually surprising we agreed on anything.

We agreed on four things:

· We agreed at the first level, on the need to respond to change. We agreed that agile reflected our intent, and permits discussion of heavier-agile methodologies for larger and life-critical projects.