Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 3. Communicating, Cooperating Teams Teams as Communities
-
Часть 1
-
We have looked at what it takes for someone to notice something of value on a project, and what it takes for someone to communicate something of value. It is time to consider whether the person cares to notice and communicate anything.
On an effective team, the people pull approximately in the same direction. They actually all pull in slightly different directions, according to their personal goals, personal knowledge, stubbornness, and so on (Figure 3-17). They work together at times, against each other at times. The directions are more aligned on a more effective team than on a less effective team.
Figure 3-17. An average team working to pull towards a goal on the right.
We can create a large overall effect on the project from small changes in each person's behavior. This is "micro-touch" intervention: getting people to make changes they don't mind making, in ways that gets amplied by the number of people on the project. As each person pulls in a direction closer to the desired and common direction, the changes felt by any one individual are small, but the composite effect is large (Figure 3-18). in a lecture about technology transfer, "The way to get effective technology transfer is not to transfer the technology itself, but to transfer the heads that hold the technology! "
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
-
Навигация [ Часть 1. Глава 14. ]
Закладки
Types of Methodologies Rechtin (1997) categorizes methodologies…
It follows that on the Theory Building View, for the…
Figure 4-1. Elements of a methodology. Roles. Who you…
Crystal Clear is the most tolerant, low-ceremony small-team…
The industry is littered with projects whose sponsors did…
That it is people who design software is terribly obvious.…
13. (FIRST TECHNIQUE). .. your sword now having bounced upward,…
Agility implies maneuverability, a characteristic that is…
Games are not just for children, although children…
After much coaching for six months, his programs still looked…
Using the planning game in this way, the sponsors can properly…
Accepting program modifications demanded by changing external…
We see an example of needing these normalizing rituals…
The complete discussion about when and where to apply concurrent…
The chart shows the state of the user stories being worked…
1. Project name, job of person interviewed (the interviewee…
For us as designers, it was possible to express both propositional…