Steamrolling the organization with process, or is there a better way?

Member Submitted

Many organizations try to implement change. This includes everything from the introduction of a new tool or method, to a company-wide process improvement program. Often these attempts fail because too much is attempted too quickly with little thought to the most effective sequence of events. When new ideas are introduced they are either abandoned after a short time or adopted by only a few people.

Whenever an SEPG (Software Engineering Process Group) or process improvement team wants to deploy a change, there are some key principles that it should consider to be successful. This paper covers the use of an adoption curve that categorizes an SEPG¹s target audience into five groups:

  • Fanatics and early champions
  • People that are almost ready for the change
  • People that need evidence
  • Heavy skeptics
  • Laggards

Understanding these groups helps the SEPG to:

  • Increase the speed of deployme

"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]

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


About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.