CORE ELEMENTS OF WOULD-BE AGILE

14 May 2002

by Alistair Cockburn

The standard mechanism for reducing the trauma of ongoing requirements changes is to break the project into subprojects, each ending with delivery of running, useful sections of the system. This early and regular delivery provides the team with feedback about both the development process and the system being developed.

Early and regular delivery helps build safety into the project. By delivering several useful releases within a short time span, the sponsors, customers, and developers gain confidence in their way of working. Pausing and reflecting after each subproject, they have opportunities to fix mistakes in their way of working and try out new ideas for becoming more effective.

Early and regular delivery also allows the people to get feedback about the system in operation and, particularly, which of their initial thoughts were mistaken. The deliveries also provide points at which they can uncover and react to new requirements, whether those come from users' reactions or from changes in the business environment.

A common recommendation among agile methodologies, therefore, is to run small (3- to 12-week), time-boxed subprojects and to reprioritize the requirements after each time-box. This gives the projects half of the agility they need.

The other half of their agility comes from replacing some of their written documents with enhanced informal communication among team members, shifting the group's organizational memory from external to tacit knowledge.

External knowledge is the kind we can look at in paper or online documents. Examples are the project plan, the requirements document, interface definition documents, design documents, meeting minutes, design review results, test plans, test scripts, defect reports, and many others. Tacit knowledge is the kind people retain in their persons. It includes not only what each person knows about the project plan, requirements, design, and so on, but also who they know to talk to, when various people are available, and the social and technical conventions in place.

All project teams rely on tacit knowledge, usually to a far greater extent than they suspect. Agile methodologies, though, place a deliberate reliance on tacit knowledge. Through the use of informal communication channels, such as colocated teams, pair programming, or daily stand-up meetings, they demand that the people on the team keep each other abreast of ongoing changes to the plan, the requirements, the design, the code.

When it works, it makes agile teams far more maneuverable. A short discussion at the stand-up meeting can suffice to indicate a change in corporate policy or system goal. A discussion between a few developers informs them of changed requirements or a change in the design. Not having to update the external knowledge base means they can make many changes in a short time period.

When it works.

To make it work, the team members build not only on sitting close together, but also on maintaining open communication among themselves. The tacit knowledge base doesn't track very well if people are being secretive with each other.

In other words, group amicability, morale, and community become first-order concerns for the group. To the extent these are in place, the informal communications channels may suffice. To the extent they break down, the communications suffer, and so does the team's maneuverability.

This, then, is the biggest difference between agile and other sorts of development processes. Agile processes put the topics of people, community, amicability, and morale front and center. Standard process descriptions don't have a place for discussing these topics.

It is this line of thinking that brought developer Andrea Branca to write, "Other processes may look agile, but they won't feel agile."

--Alistair Cockburn, Senior Consultant, Cutter Consortium