Alistair Cockburn - Agile Software Development

There are two problems with the make-them-change approach:

· The less serious problem is that it is really, really hard to get people to change their habits and approaches.

· The more serious problem is that we don't yet understand the subcultures. To force them to change their values is a bit like prescribing

A software project sets up a small ecosystem made of personalities from diverse cultures. We have seen some elements of the ecosystem, including

· Walls acting as barriers, open spaces acting as conduits medicine without understanding the defense mechanisms of the body.

In the face of this situation, there are things that the industry can do, things that a few individuals can do, and things that everyone can do. As an industry, we can

· Encourage more ethnographic studies of software development groups, as Grinder (199?) and Hovenden (2000) have done

· Identify and understand norms in play, showing the contribution of each to the organization

· Experiment with cultural changes Every consulting company would benefit from employing a social anthropologist or ethnographer. That person will help the consulting team understand the social forces in play on their projects, which will enhance the team's effectiveness.

People who are fluent in several specialties, such as programming and database design, programming and project management, or teaching and designing, can act as translators. These people help by converting statements phrased in one normative value set into sentences meaningful within a different value set. A number of people who perform this function have written to me, describing the difficulty, and necessity, of this role.

Finally, everyone can practice patience and goodwill in listening. Pretend that the other person's sentences, however crazy, make sense in the other culture's value system. Listen that way first, and then decide if you still need to disagree.

· People in their professional specialties acting as interacting subspecies

· Individuals with strong personalities changing the way in which the ecosystem works

Everything affects everything: the chairs, the seating, the shape of the building, whether people share a native language, even the air conditioning. Lizards and Penguins

At one company, moving from our old building to a new one nearly caused fights. In the old building, we each had a private office, and each office had its own thermostat. In the new building, we would still have private offices, but there was only going to be one thermostat for every two offices. Each adjacent office pair had to use the same temperature setting.

Suddenly, the work force polarized into those who liked warm offices (the "lizards") and those who liked cold offices (the "penguins"). People were jockeying for positions, so they could share the thermostat with someone of similar temperature preferences.

In some work situations, it is hard for people to change companies. In other situations, people change jobs every few months. The two situations create different attitudes and behaviors in the work force.

Every job role and every person affects every other. Key individuals play a more significant role in shaping the ecosystem than others. They focus, or more frequently, block conversations. When they leave, the entire network of relationships changes.

Each project's ecosystem is unique. In principle, it should be impossible to say anything concrete and substantive about all teams' ecosystems.

It is.

Only the people on the team can deduce and decide what will work in that particular environment, and tune the environment to support them.

Understanding some key characteristics of humans and of methodologies, the team can look around, introspect, and construct a best first guess as to what conventions and policies might work well for them, suiting their own strengths and weaknesses.

Mapping Methodology to Ecosystem

The people on the teams will naturally reexamine and adjust their conventions over time, periodically or whenever a major event changes their ecosystem (as when a particularly influential individual joins or leaves the organization).

The set of conventions and policies I refer to as the team's methodology. As we shall see in the next chapter, a methodology is a personal thing, "a social construction" to quote Ralph Hodgson.

Considering the methodology as the team's own social construction is useful. It highlights that no boxed methodology will work straight out of the box. The team will have to adapt both themselves and the methodology to work together, to create their own, local, effective ecosystem.

Ecosystems and methodologies have this interesting characteristic in common: If the team constructs many, complicated rules for themselves, they tie themselves to a narrow ecological niche.

However, narrow ecological niches are notoriously fragile, and the market has a nasty habit of changing the terrain around a company. The many rules that give effective behavior in one ecological terrain are ill-suited for another terrain.

In biology, we use the word "extinct." In bursiness, the phrase is "go out of business."

If, on the other hand, the team creates and periodically updates a few, well-placed guidelines, they can draw on the intelligence, pride-in-contribution, communication and spontaneity of their members. The people will adapt those guidelines to the situation at hand, achieving robust behavior in the face of technological, social and market surprises. Dee Hock, designer of the highly-decentralized VISA system in th 1960s and 1970s, wrote (Hock, 1999):

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

Walk around your place of work. Notice

· The convection currents of information,

· The drafts

· The information radiators

· The separate communities of practice

· The background conversation complimenting or denigrating other groups in the organization

See

· How you can improve the flow of information and reduce the erg-seconds required to detect and transmit critical information

· If you can colocate your team, or

· If you can partition the project so that teams are located around their communication needs

Try

· Removing partitions between people

· Pair programming

· Arranging for daily visits between programmers and business experts

· Micro-touch intervention (people making small changes that they don't mind making, but which result in their pulling more in the same direction)

· Listening to the words of someone in a different professional specialty according to their cultural norms, not your own

· Translating between two subcultures in their own cultural terms

Observe the interaction between your methodology's rules and your project's ecosystem. Note the fits and the misfits, and the influence of a few, key individuals.

Consider what conventions or policies might improve the way in which your group gets things done. They may be conventions about seating, tools, working hours, process, lighting, meetings, anything.

Do this, and you are half-way to tailoring your methodology to fit your organization.

The purpose of this chapter is to discuss and boil the topic of methodologies it until the rules of the methodology design game, and how to play that game, are clear.

"Methodology Concepts" covers the basic vocabulary and concepts needed to design and compare methodologies. These include the obvious concepts such as roles, techniques, and standards and also less-obvious concepts such as weight, ceremony, precision, stability, and tolerance. In terms of "Levels of Audience" as described in the introduction, this is largely Level 1 material. It is needed for the more advanced discussions that follow.