Alistair Cockburn - Agile Software Development

The small changes come from people being given

· Additional information about the direction they should pull toward

· Additional information about the effects of their actions, so they can notice which actions pull in a different direction

· A better reason to pull in the desired direction

The result is that people start contributing to each other's work, as opposed to ignoring or accidently working against each other.

Figure 3-18. A slightly better aligned team.

People see greater project output for similar amounts of energy, and without having to learn major techniques or philosophies. As they notice this, they develop greater pride in their work and trust in each other. Usually, morale improves, and the project becomes a better community in which to live.

The Project Priority Chart

The project priority chart is one simple mechanism that every project team should use to help align their effort (this chart is also described in Adaptive Software Development (Highsmith 2000) and Crystal Clear (Cockburn Clear)).

At the start of the project, the executive sponsors and the developers discuss and write down the single aspect of the development that everyone should attend to. It may be: time-to-market, defect reduction, response time, ease of learning to use, speed of expert usage, memory used, extensibility, or ease of maintenance. They may write a second one, for example: time to market and ease of casual use.

They then select, from among all the other desirable characteristics the team should strive for, those three or four that the team should be willing to sacrifice in order to achieve the main two.

From this exercise, each person sees what sorts of trade-offs are permitted on the project, and how to prioritize their actions. With a modicum of goodwill between team members, simply writing the choices down in a joint meeting and referring to it periodically gets goal alignment close enough.

The project priority contract addresses the common problem that the sponsoring executive sponsors wants the software out soon (to hit a market window), but the programmers want "design it right" (delaying their output to improve the design aesthetics). Or the reverse, that the programmers are used to working fast and sloppy to hit market windows, and the sponsors want them to take a bit more time and make fewer mistakes. In these cases, the entire organization suffers for a simple, correctable miscommunication of the desired priorities (you may notice that I assume the reward structures in place align with the priorities being requested).

Sometimes the priorities need to change in the middle of a project. For example, a competitor may come out with a new product. At that instant, it may become important to reverse priorities, shifting from development speed to defect freedom, or vice versa. Should this happen, the sponsors will get the team together again and announce the shift in priorities.

Amicability and Conflict

Amicability is the willingness of people to hear the thoughts of another person with good will, and to speak without malice.

Amicability is the weaker cousin to trust. Trust is wonderful, and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.

When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost opportunity cost as well as the overall cost per idea developed.

Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.

One might think that removing all conflict from would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems! I was surprised to find one organization that suffered from too little conflict: Not Enough Conflict

In a church organization I visited, each staff member was employed for as long as they wished. The group cherished virtues of humility, peacefulness, and amicability. The unsuspected negative effect that accumulated was the absence of both disagreement and initiative!

Each person would think twice (or more) before criticizing someone else's idea, for fear of being seen as seeding discord, or of disrupting the group. People would also think twice (or more) before taking initiative, lest they be considered glory- or power-hungry. The net result was that projects moved very slowly.

Before you start offering suggestions for this group, recall the values of the group. They will only improve their development practice when they can find ways to disagree without jeopardizing their values of humility and amicability.

Schrage (2000?) describes the intentional use of small doses of conflict to get people to meet and learn to talk with each other. It reminds me of introducing a weakened form of a virus so that the body can build ways of handling the stronger virus: Deliberate Conflict

"...according to some reports, engineers on the 777 design-build teams deliberately introduced conflicts with other systems into their proposed designs.

"...Although Boeing officially acknowledges only that interferences naturally evolved, according to at least one mechanical engineer, some of those interferences were intentional. Why? So that engineers in one part of Boeing could use the interference to find the people in other parts of the company with whom they needed to discuss future design issues. ... the software's ability to notify appropriate parties about interferences became, at least in some instances, a tool to forge interactions between various groups within Boeing. "...The resulting conversations and negotiations resolved design conflicts before more serious problems could emerge."

Citizenship within Working Hours

Good citizenship is a matter of acting in ways that benefit others. Citizenship shows up with people

· Getting to meetings on time

· Answering questions from other people

· Bothering to mention things that one notices

· Following group coding conventions

· Using code libraries Citizenship permits programmers who disagree on coding styles to nontheless create a common coding standard for themselves. As many lead programmers have said, "It's not what I would like, but I recognize that there many ways work, and selecting any one of them is better than not selecting any at all."

Helping other people in the company is a characteristic of citizenship. Dixon (2000) reports on the strong effect of taking time to help other people. She cites, among many examples, a woman at Tandem Computers who was asked about taking away from her work time to answer questions posted on the corporate discussion boards. The woman responded, "Answering questions like this is part of being a good company citizen"

I would suggest increasing citizenship levels to get better project results, except that I usually find workers already show citizenship and sacrifice, and management already takes too much advantage of it.

People join a new company and work overtime, thinking that after they contribute this extra work, the company will repay the compliment and give them more recognition and time off. What they don't realize is that their bosses and colleagues assume that however they work in the first month is how they will work and act forever. As a result, people regularly get poor evaluations for dropping their working hours from 65 down to a mere 50!

I am afraid that managers will use the pretext of good citizenship to coerce people into working yet more overtime. Read Death March (Yourdon 1998) for examples of this.