The surprising thing about human success modes is how nebulous and improbable they seem. They include
Are these the mechanisms that consistently pull projects through to safety? In my interview notes, I find that one answer showed up repeatedly when I asked what caused a project to succeed in the end:
For the first eight years of my interviews, I assumed that the speakers meant that they had messed up, and only personal heroics had saved the project. Slowly, though, as I kept hearing it, I realized that I could not explain why people did that or the overall role of this sort of action on the project. It was by investigating this sentence that I started to see the powerful effects of the human success factors just mentioned, effects that are relevant no matter whether a tight or loose process is being used. Let's look at these success factors. Good at Looking AroundThat people are good at looking around is reflected in the ways they organize the paper in their lives: books, reports, addresses, and so on. A common, human way of sorting is to use the "shell sort" algorithm: We build piles ordered according to the sorting criterion (for example, alphabetically, or by date) but leave things unsorted within any pile. We then break each pile into smaller piles and repeat until each pile is small enough to sort by eye and by hand. Except . . . we often don't do that final sort. When the pile is small enough to sort by eye and by hand, we often just leave it like that and find any item of interest just by scanning the contents of the pile. The standard address book is a perfect example of this. An address book is sorted into sections by starting letter, but the entries within a section are not sorted. They are just written in any order, and we scan the section to find the entry of interest. A more extreme example is the way many people sort papers in their offices. They have stacks of papers in general piles and locate reports by looking through the relevant stacks. The important thing to notice is that this lack of final sorting is not bothersome. Most people do not even notice it but work on the assumption that they can locate things fast enough through scanning and by memory associations. Trygve Reenskaug gave the following example of being good at looking around on a project:
A second example of people using their ability to look around is the way code maintenance is done. Keeping traceability and design documents up to date is very expensive and unreliable (particularly given the weakness of humans with regard to consistency). In most projects, it is not long before the documentation doesn't match the code. If keeping the two in sync were essential, project teams would not be able to continue through the maintenance phase. However, code maintainers expect this mismatch, and so they use the faulty documentation simply as a means of getting "close" to the area that will need changing. As soon as they are close, their eyes and intelligence take care of the rest. They plan on just looking around until they find the section of code to change. Inside the theory of the cooperative game, we can use this human ability and plan on making the documentation "good enough to get close," close enough to use the native human ability to look around and find the right place to make a change. A third place where we count on people being good at looking around is the role of technical lead. The title "Technical Lead" contains the assumption that this person has done something similar enough before, that he has a sense of when the project is all right and when it is off track. The Technical Lead is not given any instructions about to how to do this. He is simply supposed to "look around and notice" when something is not right and somehow invent a way to get back into the safety zone. "Looking around and noticing when something is not right" is something that everyone on the project does. I have found people in every possible job description who have detected something amiss with some aspect of the projectvery often not their ownand have reported it to the person who should deal with it. Or, they have just dealt with it themselves, specifically stepping outside their own job descriptions to take care of it. People LearnNovices don't stay novices forever. People who are novices on one project become experienced by the end of the same project and often are senior designers a few projects later. This ability to learn along the way helps many projects. Within a single project's time frame, the people learn new technology, new problem domain, new process, and how to work with new colleagues. Often, a team struggles through the first two increments, becoming stronger and stronger until successful results at the end are almost a given. In long-running projects and in situations where there is a steady flow of small initiatives, senior people leave and junior peoplewho have become seniortake their places. We take advantage of people's ability to learn within a project by splitting it into subprojects (incremental development again). This provides not only the small wins and feedback discussed earlier but also the opportunity for people to learn how the process works. "Oh!" they might say, "that's why we had to write the input validation fields in the data structures table." They use their ability to look around to detect what needs improvement, and then they invent new ways of working to try out in the next increment. MalleablePeople are remarkably able to act differently given new motives and new information. This is the mechanism in the two stories at the start of the "Overcoming Failure Modes" section: the small-goods shop and the C3 project. In the story of the small-goods shop, we don't have enough information to know why the girls changed their work habits. In the story of the Chrysler Comprehensive Compensation (C3) project, Kent Beck needed to shift the team's cultural values away from creating clever code to creating simple solutions, a notoriously difficult task. One technique he used was the peer-pressure ritual. In one such ritual, the group formed a procession, placed a propeller beanie on the head of someone with an overly clever solution, and then spun the propeller on the beanie, commenting on the "cleverness" of the solution. The negative attention from peers caused people to move away from clever solutions; appreciation for simple designs drew them to simple solutions. True to people being different, not everyone on the team was "malleable" enough to adopt XP. One person did not enjoy the new working style with its requirements for conformity and close cooperation and eventually left the project. Contributing and Taking InitiativeIn the previous section I discussed pride-in-contribution and pride-in-work as strong intrinsic motivators. Now I suggest that they are also core contributors to project success. People who have pride in their work do a better job than those who do not, and they are also more likely to step outside of their own job descriptions to repair or report some other problem that they notice. Even though their only reward may be that they have done a good deed, I continually encounter people for whom this is sufficient. Notice that we are back to the spontaneous behavior I mentioned at the start of the chapter. At that time, I described spontaneity as a difficulty in building a predictive model of humans working in a system. Now I include it as one of the human success modes. Start with some pride-in-work and a sense of citizenship. Add being good at looking around and acting spontaneously. With these, we see people taking initiative to get the job done every day, an ongoing activity that keeps the project operating at peak form. This is not an indication of process failure. Even the best process won't be able to account for every surprise that occurs on the project. Therefore, it becomes important that people notice, mention, and resolve problems that they see. The good thing to notice is that as the team gets better at pride-in-work, communication, citizenship, and initiative, the process can become less formal, based more on noticing what needs doing. Combining Success ModesIs it possible to construct a development methodology just around pride-in-work, citizenship, community, people being good at looking around, and taking initiative? It is. The following excerpt (Hock 1999, pp. 205207) is a description of how the first VISA clearing program was developed in 60 days. Note Dee Hock's use of the phrase "self-organization," synonymous with people taking initiative in a community.
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 PeopleOne 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 may be needed 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:
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).
|