Alistair Cockburn - Agile Software Development

Swifty, self-organization emerged. An entire wall became a pinboard with every remaining day calendared across the top. Someone grabbed an unwashed coffee cup and suspended it on a long piece of string pinned to the current date. Every element of work to be done was listed on a scrap of paper with the required completion date and name of the person who had accepted the work. Anyone could revise the elements, adding tasks or revising dates, provided that they coordinated with others affected. Everyone, at any time, could see the picture emerge and evolve. They could see how the whole depended on their work and how their work was connected to every other part of the effort. Groups constantly assembled in front of the board as need and inclination arose, discussing and deciding in continuous flow and then dissolving as needs were met. As each task was completed, its scrap of paper would be removed. Each day, the cup and string moved inexorably ahead.

Every day, every scrap of paper that fell behind the grimy string would find an eager group of volunteers to undertake the work required to remove it. To be able to get one's own work done and help another became a sought-after privilege. Nor did anyone feel beggared by accepting help. Such Herculean effort meant that at any time, anyone's task could fall behind and emerge on the wrong side of the string.

Leaders spontaneously emerged and reemerged, none in control, but all in order. Ingenuity exploded. Individuality and diversity flourished. People astonished themselves at what they could accomplish and were amazed at the suppressed talents that emerged in others.

Position became meaningless. Power over others became meaningless. Time became meaningless. Excitement about doing the impossible increased, and a community based on purpose, principle, and people arose. Individuality, self-worth, ingenuity, and creativity flourished; and as they did, so did the sense of belonging to something larger than self, something beyond immediate gain and monetary gratification. No one ever forgot the joy of bringing to work the wholeness of mind, body, and spirit; discovering in the process that such wholeness is impossible without inseparable connection with the others in the larger purpose of community effort. Money was a small part of what happened. The effort was fueled by a spontaneous expansion of the nonmonetary exchange of value. ... No one ever replaced the dirty string and no one washed the cup. ... The BASE-1 system came up on time, under budget, and exceeded all operating objectives."

According to traditional software engineering methods, this project should have been a shambles. According to the cooperative game theory, it is clear why it works.

Is it a repeatable process? The answer depends on how well the group manages to keep those key factors alive.

Heroes as Ordinary People

One point I wish to make is that in well-run projects, people in any job description can notice when something is out of kilter and act to correct it or notify someone who can.

Although heroes who work overtime are necessary to save poorly run projects, there is a much more interesting phenomenon to observe: ordinary people doing their work with a sense of pride and community and in doing that work noticing something wrong, passing information to someone who can fix the problem, or stepping out of their job descriptions to handle it themselves. This is an indicator of a community in action, not an indicator of a poor development process. Note the strength of this community effect in the VISA story above.

Pride-in-work, citizenship, and communication even have an effect in strongly "engineering" cultures. Here is an example, from computer hardware design: Finding Errors in PC Boards

When designing computer hardware, one person has the job of examining with a magnifying glass the photographic negatives used to produce the printed circuit boards. The person is to any find hairline cracks that may be in the negatives and to paint over them with black ink.

One day, the woman who was doing this work noticed a strange looping pattern in the line she was following. Deciding that it couldn't be correct, she notified the department head. He first dismissed the idea that she could have found anything substantive, but at her insistence took the time to investigate further. As it turned out, a circuit drawing error had resulted in two signals being tied together. The error showed up in the original circuit design. It had somehow slipped past all the design, drawing, and board layout reviews.

I wish to draw two morals from this story: The first is that everyone on a project is in a position to detect a mistake, regardless of the type of system being designed.

The second is a lead-in to a key topic in the next chapter: After a person detects a mistake, the cost of getting that information to the right person starts to drive the cost of the project.

I close this section with this summary from NASA's "Deorbit flight software lessons learned" (NASA 1998, my italics added for emphasis).

"Perhaps most important for the long term, during the course of the project, a capable core team for rapid development of GN&C systems evolved. This included finding talented team members; training in and gaining experience with the tools, processes and methodology, and integrating into a cohesive team.

After working together in the RDL for a year, team members have acquired expertise in methods, tools and domain. A helpful and cooperative atmosphere has encouraged and enabled cross training. A willingness on the part of team members to address any and all project issues has proven invaluable on many occasions... this team can be a long-term asset to the division and to the agency."

Tomorrow, start noticing the strengths, weaknesses, and oddities of the people around you. Notice

· How some fit their jobs well and some don't

· How some people are good at being consistent and others aren't

· The presence of both list-makers and those who dislike lists

· Some people taking unnecessary risks, and more people being conservative

· What your boss says the next time you offer a suggestion for improvement

About the time you start to wonder how on earth anything gets done in your company with such a mixture of fit and misfit, notice

· The teamwork in place

· The citizenship displayed by people

· The initiatives being taken spontaneously (what process could you possibly put in place that would eliminate the need for such initiative-taking?)

Improve your environment:

· Collect a few work samples: an example of some good code, a well-written class comment, use case, project plan, meeting minutes, design memo, or user interface.

· Enlist a few others to do this, and put the small collection of work samples online for everyone to copy from.

· Reduce interruptions. Create a small period each day, just two hours long, in which you don't take interruptions. See if a larger group in your office will do the same.

· Reduce the need for mechanisms that rely on the weaknesses of people.

· Increase the use of mechanisms that draw on the strengths of people and let them use their talents.

This chapter considers the effect of the physical environment, communication modalities used for jumping the inevitable communications gaps, the role of amicability and conflict, and subcultures on the team. These issues deal with a project's need for people to be able to notice important events, and to be both willing and able to communicate to others what they notice.

"Convection Currents of Information" examines the similarities of moving information with heat and gas dispersion. The comparison yields several useful associations: the energy cost of information transfer, osmotic communication, information radiators, and information drafts.