"Proving that the true skeptics are indeed truly skeptical achieves nothing, except that you've dented your pick and probably permanently diminished your credibility (and failed to appreciate the vital importance of building a fragile momentum)." [Peters, 85]

Introduction.
We have been coaching software development organizations for 10 years. In that time we have observed successes and failures as groups try to improve how they develop software. This paper provides advice for people who are trying to improve software development within their organization. Leveraging on our experiences, we will give you advice on how to make wise choices when helping people adopt new practices. Specifically, we will explain the adoption curve, what it is and how to use it. When you use your knowledge of the curve, you are better able to plan your approach as you work with people who need to adopt new practices. Using the curve you can avoid some of the pitfalls that have frustrated so many other process improvement professionals. These pitfalls include resistance to change, inappropriate mandates, wasted time, and overly complex process solutions that are eventually ignored.

This information is designed for Software Engineering Process Group (SEPG) members and other people who champion change. SEPG's provide a focal point for software process improvement in an organization. They plan and co-ordinate software process improvement. If you are trying to get people to improve things, this information will be useful to you.

When we say adoption, we are referring to changing behaviors. If you are currently doing something and you would like to improve it, then adoption encompasses the entire process from learning about a new idea or practice, trying it out, through to deciding that you want to continue using it. In the end, a new practice has been adopted when it is being used, and the user is getting the intended benefit. Using the adoption curve can aid you in helping people adopt new (or improved) practices, such as, a new estimation process, a new inspection process, a new configuration management tool, or an improved trouble reporting system.

Regardless of how big your organization is, it is wise to plan your approach. The adoption curve will help you select how to proceed, with the least resistance and most useful results.

The adoption of any practice can be represented by the bell curve in figure 1 [adapted from Rogers, 1983]. Five distinct groups can be seen during the adoption of a new practice.

Group 1: At the leading edge you have a few who may be perceived as early champions or fanatics. These are the people that will try anything new, or ones that have a desperate need for your solution.

Group 2: After the fanatics there are people who would like to try the new practice but are not quite ready. The timing might be poor or further evidence might be needed. Beyond group two the challenges are greater.

Group 3: This group is typically the largest. This group needs considerable evidence from the first two groups before attempting the idea. Change is not seen as a priority, either because the current practices are comfortable, or there is no perceived problem to solve.

Group 4: This group consists of heavy skeptics who resist every change. There might be considerable mistrust regarding the motive for the change, or resentment built up from previous changes that have failed./p>

Group 5: This group contains the laggards, the people that would kill, or would like to be killed, before changing. Group five also contains people 'retired on the job'. A laggard sees a paycheck arrive in the mail whether the change occurs or not.

An individual can be placed in one of the categories by assessing his or her willingness and need for the proposed change.

Using the adoption curve.
There are three primary uses of the adoption curve when deploying a change:

1. To increase the speed of deployment, by determining who to work with, and in which order.
2. To reduce the risk of failure by building and deploying the solution in increments. The early adopters can provide specific requirements for, and feedback on, early versions of the solution.
3. To determine when a policy should be developed and an edict issued.

Who to work with, and in which order
Always target the early adopters first. The early adopters are the people with willingness and need to try the new idea. If you pick people in the beginning that do not have a willingness or need, this is about all you will prove. For example, one company decided to do a process assessment of two sister organizations. One sister loved it; the other hated it and learned nothing. In hindsight the second sister should have been ignored. There was never a willingness or perceived need.

The people in group one will typically be more willing to help you improve any inadequacies in the idea or solution you are advocating. The solution you provide to the other groups will then be better tested and more robust. To increase the receptiveness of the next group, success stories from the previous one should be well publicized.

If you are the manager of a group of people, the adoption curve tells you who needs which solution, when they need it, and whom to avoid until the majority of the people have adopted the new practices.

If your solution is complex you might want to consider breaking it up into components. The audience you have in mind for the complete solution will probably not need every component immediately. For example, if you are developing a planning process, you might have components for estimation, risk management, negotiation, tracking, metrics, reviews and approvals. Identify the components that the early adopters need and develop these first. Use the feedback from the early adopters to design and refine the next increment.

Each component of your solution might have a different group of early adopters. For example: Some of the managers will be the early adopters for the negotiation piece. Some of the developers will be the early adopters for the estimation piece. The adoption curve provides information to help one set priorities.

In one company, a group was developing a process for subcontract management. After studying the adoption curve it was realized that there were different audiences for each part of the process. The subcontractor selection piece had a different audience than the subcontractor tracking piece. The subcontract management process was broken into components and each component was developed and refined using a different set of early adopters. Some components, such as the subcontract auditing, were not needed by anyone until much later.

Determining when to develop a policy and issue an edict
Many process improvement teams develop policy statements at the start of their process development activity. A policy states under what circumstances a practice will be used. For example, a policy on risk management might say that the risk management process should be used on projects that cost greater than $50K. At the beginning of developing a risk management process it might be very difficult to predict all the conditions where the practice would be most beneficial. It is much easier to develop a policy when some experience has been gained using the solution. One option would be to delay developing the policy statement until groups one and two have collected experience using the process.

Issuing an edict for a solution might be premature when only the early adopters have tried it. Since edicts cause resistance, delaying the edict until later in the adoption curve can reduce the amount of resistance. A good time to issue an edict is when approximately 50% of the organization are using the solution effectively. At the 50% point the success stories can be used to influence the remaining people in groups three and four. It will be difficult, but not impossible, for them to resist in the face of such evidence. At 50% there is no majority opposing the idea.

You might decide to use an edict earlier if the consequences of not using the solution could lead to a severe business impact. You could even stagger the deployment of an edict. For example, one organization decided that all system interface descriptions should go through formal peer review, while the decision to mandate peer reviews on other aspects of the system was delayed until more peer review experience had been gained.

Whom to avoid.
Some people believe that to implement change it is better to attack the most difficult groups first (the laggards and heavy skeptics) because they will need the most time to be convinced. There is also a common opinion that if you can 'crack' these groups the remainder will follow.

It is usually a mistake to start with the most difficult people. Ideas that are new to the organization take time to become credible. Successes from groups one and two will have a better chance of convincing a skeptic than all the preaching and memos in the world. If you were to work with the most difficult group first, you would not only encounter resistance, you would increase the likelihood of failure stories spreading across the organization. Bad news travels fast.

As for the laggards, ignore them. If you have individuals or teams that think your solution is the dumbest thing ever invented, ignore them (other than understanding their resistance). If you have a good solution you should be able to find early adopters. By the time you deploy the solution to groups one, two and three, some of the laggards will have changed positions or left the company. If they are still in the organization, either the evidence so far will have converted them, or they will comply, albeit superficially, under the edict. You may need to leave the conversion of laggards to management. An alternative career path for laggards might be necessary.

I don't have time for adoption curves!
You may be feeling that using the adoption curve is too slow for your organization, which has set a goal to have 120 practices adopted in the next six months to be able to achieve the next process standard or maturity level. It is important to note that many organizations that rush adoption usually do not actually adopt the practices long-term. Someone might think that the practices are being used, "because the deadline says so." If you ask the developers and managers, you will find that some of the practices are being used, some superficially, but many not at all. One cannot master and internalize a new technique in a day, but one can pretend!

Not using the adoption curve can slow down the deployment of new ideas. The more resistance you encounter, the longer deployment will take. It is much quicker to work with people who do not resist.

Increasing the number of knowledgeable staff providing the expertise (often called process champions or a Software Engineering Process Group) can accelerate adoption. Some organizations use training companies so that more people learn the skills in parallel. Even so, the adoption and practice of the new skill takes time. A proportion of the audience will always believe that the new idea is a total waste of time.

Where to go from here
In summary, we suggest you study your organization and use the adoption curve to facilitate your improvement program. Start with the early adopters and don't worry about the laggards for now.

Bibliography:
Rogers, Everett M., Diffusion of Innovation, Free Press, New York, NY, 1983.
Peters, Tom., Austin, Nancy., A Passion for Excellence, pp357, Warner Books, 1985.