Alistair Cockburn - Agile Software Development

I prefer the middle of the three choices. Jim prefers the latter of the three. None of us intend the first of the three, which comes from a misunderstanding of the word emergent as "lucky." Our common point is recognizing that the details of system design surprise even the most experienced designers.

We insist that the architecture be allowed to adjust over time, just as the requirements and process are. An architecture locked down too hard, too early, will not be able to adjust to the inevitable surprises that surface during implementation and with changing requirements. An architecture that grows in steps can follow the changing knowledge of the team and the changing wishes of the user community.

9. Continuous attention to technical excellence and good design enhances agility.

A tidy, well-encapsulated design is easier to change, and that means greater agility for the project. Therefore, to remain agile, the designer shave to produce good designs to begin with - and -also have to review and improve their design regularly, to deal with the better understanding of their design that comes with time and clean up from when they cut corners to meet a short-term goal. Managing Technical Debt

Ward Cunningham sometimes compares cleaning up the design with paying off debts. Going further, he discusses managing the technical debt on the project.

Making hasty additions to the system corresponds to borrowing against the future, taking on debt. Cleaning up the design corresponds to paying off the debt.

Sometimes, he points out, it is appropriate to take on deb and make hasty changes, in order to take advantage of an opportunity. Just as debt accumulates interest and grows over time, though, so does the cost to the project of not cleaning up those hasty design changes.

Cut corners in the design, he suggests, when you are willing to take on the debt, and clean up the design to pay off the debt before the interest grows too high.

Given the deep experience present in the room, I found it interesting to see this attention to design quality at the same time as the attention to short time scales, light documentation, and people.

The conflicting forces are resolved by designing as well as the knowledge at hand permits, but designing incrementally.

10. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

There are two sides to this statement. One relates to social responsibility side, the other to project effectiveness. Not everyone at the meeting was interested in signing onto the social responsibility platform, but we all agreed on the effectiveness issue.

People tire as they put in long hours.Their rate of progress slows, not just during their overtime hours, but also during their regular hours. They introduce more errors into their work. Diminishing returns set in with extra hours. This is part of the non-linearity of the human component.

An alert and engaged staff is more agile than a tired, slogging staff, even leaving aside all of the social responsibility issues. Long hours are a sympton that something has gone wrong with the project layout.

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

Simplicity is essential. That much is easy to agree on. The notion of simplicity is so subjective, though, that it is difficult to say anything useful about it. We were therefore pleased to find we could all sign up for this statement.

In the design of development processes, simplicity has to do with accomplishing while not doing, maximizing the work not done while producing good software. Jon Kern reminds us of Pascal's remark: “This letter is longer than I wish, for I had not the time to make it shorter.” That comment reveals the difficulty of making things simple. A cumbersome model is easy to produce. Producing a simple design that can handle change effectively is harder.

In terms of methodology and people, Jim Highsmith likes to cite Dee Hock:

“Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.”

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It is fitting to end where we began. How light is right for any one project? Barely sufficient, and probably lighter than you expect.

How do we do this on our project? Bother to reflect on what you are doing. If your team will spend one hour together every other week reflecting on their working habits, you can evolve your methodology to be agile, effective and fitting. If you can't do that, well ... you will stay where you are.

Reflecting on the Support Statements

Getting 17 people to agree on any set of words is difficult. The more detailed the advice, the more we different backgrounds and philosophies come into play.

We hope that the four leading value choices and the twelve supporting statements will give you enough information to build your own agile work habits.

Peter Naur and Pelle Ehn wrote the two most compelling and accurate accounts of software development I have yet seen:

Peter Naur's "Programming as Theory Building" neatly describes the mental activity of creating software, and explains Extreme Programming's "metaphor" activity.

Pelle Ehn wrote the wonderful book Work-Oriented Design of Software Artifacts, in which he considers how Wittgenstein's idea of language games informs our development of software.

Naur's article is not nearly as well known as it needs to be, and Ehn's book is out of print. I am happy, therefore, to present extracts from their two works here, for wider readership.

Miyamoto Musashi, the 17th century samurai champion, never wrote software. The competing schools of swordfighting in his day sound painfully like today's schools of methodology, though. His admonishes people to avoid getting infatuated with tools and schools, to use different tools and strokes for different moments, and to just "cut off your opponent's arm." His admonitions apply directly to software development -- if you realize the opponent is the problem, and not your office-mate.

Peter Naur is widely known as one of the authors of the "Backus-Baur Form" (BNF) notation, used to describe programming language syntax.

His 1985 article, "Programming as Theory Building" was reprinted in his collection of works, Computing: A Human Activity. This article is, to my mind, the most accurate rendition of what goes on in designing and programming. I regularly refer to it when discussing how much documentation to create, how to pass along tacit knowledge, and the value of the XP's metaphor-setting exercise. Understanding programming as theory building also illuminates the economic structure of methdologies.

In the following article, note the idea that the quality of the first programmer's work is related to the match between his theory of the problem and his theory of the solution. Note, even more, the idea that the quality of the later programmer's work is a function of the match between his theories and the first programmer's theories.

These ideas convert the task of passing along "the design" to the more useful appropriate task of passing along "the theories." This latter task captures the need to pass along both tacit and external knowledge, and shows that the knowledged is clearly tacit in the owning. Look for the different ways in which Naur covers the idea of "tacit knowledge."

Here is his text:.

"Programming as Theory Building"

The present discussion is a contribution to the understanding of what programming is. It suggests that programming should be regarded as an activity by which the programmers form or achieve a certain kind on insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.