mps and agile appendix on change

21
Boria et al. Appendix A 1 APPENDIX A. MANAGING TRANSITIONS “It’s not the strongest species that survive, or the most intelligent, but the most responsive to change” Charles M. Darwin A.1 If You Build It, Will They Come? All this book has been about process improvement. It could well be that this is a misnomer, since process improvement is not about changing processes, but behavior. Indeed, if the only thing that changes is the process do not expect performance to improve. Improvement comes from changing behavior in a manner that affects performance for the best. Besides, change is pervasive, it permeates everything everywhere, all the time. What we want to address is managed change, change with a purpose. We want to manage the transition from one state, the present state, to another, the desired state. We will deal with this in this Appendix. A common mistake is that the essence of process improvement is writing the new processes and publishing them in a Process Asset library from where everyone will joyously choose to pick it up and use it. This is akin to building a baseball field in a corn field and expecting gone by players to show up to play, with the added truth that you are not in a movie. There is a plethora of reasons why this will not happen. People build barriers to change unconsciously and on purpose. Change is disruptive even when perceived as positive. William Bridges, in “Managing Transitions; Making the Most of Change” points out that every change is not only a beginning, but an end. What hinders adoption is that during the transition the old and the new coexist and people have a hard time “letting go” of the past. People are asked to abandon the known ways, no matter how boring, impractical and lambasted they are, to embrace the unknown, a request that always creates anxiety. Machiavelli, in his oft cited and less read treatise “The Prince”, makes this clear when he says “There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things.” Change is what happens when we are trying to keep things stable. If we do not plan the direction of change, it will take its own direction, and just hoping for all people to understand the positives and negatives, make the decision to change and adopt the change in the right direction is delusional. Even when planning the transition, not considering the cultural aspects of the organization, that which needs to change and that which needs to remain in place, is setting the stage for a fiasco. 70% of the efforts to perform “business reengineering” have failed 1 and 57% of the efforts to introduce CASE tools have failed 2 because they failed to consider the human factor. Fichman and Kemerer discuss why this is so. They discuss what they call the assimilation gap between the acquisition of a technology and its deployment. A technology can be widely purchased but hardly deployed. The different curves, that of the purchasing and that of the deployment, show the assimilation gap. (Figure A-1) This is obviously important. We quote Fichman and Kemerer: “For innovations in process technology to have a positive impact on quality and productivity, they must be successfully deployed.” The question to ask is when is a given technology difficult to deploy. According to them, a combination that makes a technology have a large assimilation gap is that for it there exist ‘strongly increasing returns to adoption and substantial knowledge barriers impeding adoption.’ Increasing returns simply means that it becomes more valuable to any individual adopter to the extent that others also adopt. The more people that are familiar with the technology, for example, will increase the likelihood of finding trained people to deploy it. You might not have to train people in its use because they are already familiar with it from previous jobs or even college degrees. On the second factor, knowledge barriers arise because the skills and knowledge required to deploy complex process innovations typically goes far beyond simple awareness of the innovation and its potential benefits, such knowledge is usually acquired only overtime and with considerable difficulty. A stand up class will not provide all the skills to help all the people adopt the change. This distinction is made in some schools of thought related to training, in which there are defined remote and close behaviors. A close behavior is easy to acquire by observation and mimicry. A remote behavior requires a long period of apprenticeship. For example, in a modeling tool such as Enterprise Architect, the interfaces are linked to close behavior: you can teach someone with reasonable computer skills how to operate the tool; however, the modeling itself is remote, it requires training, coaching and mentoring plus a long period of working under close supervision for one to become a reasonable modeler. 1 Hammer, M. The Wall Street Journal, November 26, 1996 2 Fichman, R. and Kemerer, C. F., “The Illusory Diffusion of Innovation: An Examination of Assimilation Gaps”, Information Systems Research, v. 10, n. 3, pp. 255-275, September 1999.

Upload: jorge-boria

Post on 13-Jun-2015

637 views

Category:

Business


1 download

DESCRIPTION

A big part of process improvement is managing the transition. Many books have been written about how to do this, yet there is a paucity of strategies that can be tied to real life variables. In this Appendix to our book (in translation from Spanish) we explore such strategies and suggest a parsimonious approach whenever possible.

TRANSCRIPT

Page 1: Mps and agile appendix on change

Boria et al.

Appendix A 1

APPENDIX A. MANAGING TRANSITIONS

“It’s not the strongest species that survive, or the most intelligent, but the most responsive to change” Charles M. Darwin

A.1 If You Build It, Will They Come?

All this book has been about process improvement. It could well be that this is a misnomer, since process improvement is not about changing processes, but behavior. Indeed, if the only thing that changes is the process do not expect performance to improve. Improvement comes from changing behavior in a manner that affects performance for the best. Besides, change is pervasive, it permeates everything everywhere, all the time. What we want to address is managed change, change with a purpose. We want to manage the transition from one state, the present state, to another, the desired state. We will deal with this in this Appendix.

A common mistake is that the essence of process improvement is writing the new processes and publishing them in a Process Asset library from where everyone will joyously choose to pick it up and use it. This is akin to building a baseball field in a corn field and expecting gone by players to show up to play, with the added truth that you are not in a movie. There is a plethora of reasons why this will not happen. People build barriers to change unconsciously and on purpose. Change is disruptive even when perceived as positive. William Bridges, in “Managing Transitions; Making the Most of Change” points out that every change is not only a beginning, but an end. What hinders adoption is that during the transition the old and the new coexist and people have a hard time “letting go” of the past. People are asked to abandon the known ways, no matter how boring, impractical and lambasted they are, to embrace the unknown, a request that always creates anxiety. Machiavelli, in his oft cited and less read treatise “The Prince”, makes this clear when he says “There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things.”

Change is what happens when we are trying to keep things stable. If we do not plan the direction of change, it will take its own direction, and just hoping for all people to understand the positives and negatives, make the decision to change and adopt the change in the right direction is delusional. Even when planning the transition, not considering the cultural aspects of the organization, that which needs to change and that which needs to remain in place, is setting the stage for a fiasco. 70% of the efforts to perform “business reengineering” have failed

1and 57%

of the efforts to introduce CASE tools have failed2

because they failed to consider the human factor. Fichman and Kemerer discuss why this is so. They discuss what they call the assimilation gap between the acquisition of a technology and its deployment. A technology can be widely purchased but hardly deployed. The different curves, that of the purchasing and that of the deployment, show the assimilation gap. (Figure A-1)

This is obviously important. We quote Fichman and Kemerer: “For innovations in process technology to have a positive impact on quality and productivity, they must be successfully deployed.” The question to ask is when is a given technology difficult to deploy. According to them, a combination that makes a technology have a large assimilation gap is that for it there exist ‘strongly increasing returns to adoption and substantial knowledge barriers impeding adoption.’ Increasing returns simply means that it becomes more valuable to any individual adopter to the extent that others also adopt. The more people that are familiar with the technology, for example, will increase the likelihood of finding trained people to deploy it. You might not have to train people in its use because they are already familiar with it from previous jobs or even college degrees. On the second factor, knowledge barriers arise because the skills and knowledge required to deploy complex process innovations typically goes far beyond simple awareness of the innovation and its potential benefits, such knowledge is usually acquired only overtime and with considerable difficulty. A stand up class will not provide all the skills to help all the people adopt the change.

This distinction is made in some schools of thought related to training, in which there are defined remote and close behaviors. A close behavior is easy to acquire by observation and mimicry. A remote behavior requires a long period of apprenticeship. For example, in a modeling tool such as Enterprise Architect, the interfaces are linked to close behavior: you can teach someone with reasonable computer skills how to operate the tool; however, the modeling itself is remote, it requires training, coaching and mentoring plus a long period of working under close supervision for one to become a reasonable modeler. 1 Hammer, M. The Wall Street Journal, November 26, 1996

2 Fichman, R. and Kemerer, C. F., “The Illusory Diffusion of Innovation: An Examination of Assimilation Gaps”, Information

Systems Research, v. 10, n. 3, pp. 255-275, September 1999.

Page 2: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

2 Software Process Improvement with Agile Methods and Maturity Models

Figure A-1: Assimilation Gap (Fichman and Kemerer, op. cit.)

When the behavior to be acquired is remote, the conflict between the organizational knowledge needed to generalize, scale up, and institutionalize a technology and the knowledge needed to acquire it is large. This conflict leads to an initial loss of productivity. If the transition period is too long or too expensive, the change is abandoned and the improvement fails. The secret lies in how to bound and manage the transition. In such cases, change is systemic; change addresses the system, and any attempt to make local improvements can hinder the overall result.

Even if it is useful to implement “low hanging fruit” changes, sticking to such a policy without a framework of reference (of the change itself) can lead to a dead-end. When managing a transition, we should recognize interdependent variables and avoid sub-optimizing when interdependencies are evident. We can implement stop-gap changes if needed, be it because we need to show that we are making progress, or because the organization is suffering too much loss through a bad process, but we need to keep in mind and switch to a systemic change after the initial economies are realized.

A.2 Cast of Characters

Every transition costs money, whether in external support, the tools being introduced, an internal support infrastructure or the human resources involved. When money is involved in an organization there must be someone at a position of authority that legitimizes the change initiative, holds the reinforcing sponsors accountable for change and owns the change and the transition project. This is the Authorizing Sponsor.

Figure A-2: Change Management Roles in a Hierarchy

Page 3: Mps and agile appendix on change

Boria et al.

Appendix A 3

An authorizing sponsor has to establish and communicate and market the business case for the change to the organization. Arguably this has to be supported by convincing evidence that the change is pertinent and adequate to the culture. She therefore will have to lead the organization through the change by articulating the necessity of the change, modeling desired state behavior, and reinforcing change participants who make, or even seriously attempt the transition. She will review and approve the transition plan, project objectives and project scope included. She will be responsible for the reception of the plan, so she will have to communicate the plan and progress to business units and/or customers. Because of this, she will be required to authorize staff, budget, and resource requests.

Even when high enough in the organization, an authorizing sponsor can only do so much without creating and chartering a group of Reinforcing Sponsors. This group is something called the Management Steering Commitment. Reinforcing sponsors allocate resources, remove barriers, express, model and reinforce change per the universe of discourse of the authorizing sponsor. They are the ones that oversee the organizational change project from up close, by parceling the objectives and translating them to division or section objectives, and then review and approve their apportioned plans and activities. They are expected, individually and collectively, to review project status regularly. Since they represent the visible face of the organization to the line, they have to lead organization change by expressing the necessity of the change, modeling desired state behavior, and reinforcing change participants who make the transition, or even seriously attempt it. It is important to note that success is not the only possible outcome at the beginning, and that we humans learn a lot more from failures than from achievement, to which we give no second thought

3. Their closeness to operations should enable them to enroll

staff and subject matter experts to action teams and pilot activities, empower action teams and project teams to act on improvement recommendations and changes, remove obstacles to success, enforce compliance to new approaches once they are sufficiently institutionalized and, just like the sponsor, communicate and market the change to their customers.

Another role in the transition is played by Champions. A champion is someone who believes things can be different and act as advocates for the change, is respected by her peers and has a clear vision of what the problem is and which are the attributes of a good solution. Champions will not only act as subject matter experts in process asset teams, but also as coaches, mentors and in general help reinforce the behavioral change.

Change Agents are the ones who actually implement the change, keep everyone informed, make resistance surface and handle it. This role requires a lot of soft skills and hard knowledge. A change agent plans and implements the change roadmap, identifies resources needed for the implementation and makes those needs known to the reinforcing sponsor, builds support for the change throughout the organization, assists participants in their part of the change implementation, and reports progress.

Participants, or Process Users, are the people that will have to change their behavior, habits, emotions, and way of doing things. All these roles have to be identified and correctly managed during the transition to ensure success.

A.3 Getting Started

Assimilation is defined as the process spanning from an organization's first awareness of an innovation to, potentially, acquisition and widespread deployment. Planning a transition requires to estimate the size, duration and cost of the assimilation process. This is best represented by just one variable, the scope of the change, i.e. how large it is, or in the vocabulary of the previous section, how remote is the change from the current practice. It will be easy for organizations to assimilate complex technologies when the cost of organizational learning is effectively lower, be it because the organization already has much of the know-how and technical knowledge germane to the change, or because it can be bought in the market easily or, at least, economically. Organizations with a large scale of activities over which learning costs can be spread (for example the technology has wide application in different sections, such as a Document Management Systems), and/or possess more extensive existing knowledge in areas related to the technology in question (for example the organization has been using a proprietary Configuration Management System and wants to introduce a tool from shareware), and a greater diversity of technical knowledge and activities in general (specialists in diverse areas can easily see potential benefits of the tool in question).

3 A person who never made a mistake never tried anything new. Albert Einstein

Page 4: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

4 Software Process Improvement with Agile Methods and Maturity Models

Scope has to be measured from the cultural point of view. If the culture is familiar with the technology, or with a similar one, the chance of success is greater than when the technology is totally new and demands many changes in the process and the skills required to use it. What scope measures is the affinity, or lack thereof, of the proposed technology with the current culture. For example, certain organizations can show a propensity to create self-organizing teams and therefore assimilating Scrum will be relatively painless for them. Instead, a strict hierarchical organization with years of command and control values will find it very difficult. This is represented in Figure A-3. One could argue that change with high probability of success is little change, or no change at all, therefore there is probably little value in doing this type of change projects. The way we would like to tackle changes is aligned with the arrow that says “Moderate Probability of Success” and deal with it through a comprehensive plan to manage the transition.

Figure A-3: Probability of Success of a Change

The arrow in Figure 3 that reads “Very Low Probability of Success” represents the type of change projects that require years to implement, a large budget to complete and serious commitment from the top to succeed. Only few of these type of change projects succeed. What is characteristic of these situations is that they can be read easily by doing a field-force analysis, looking for obstacles to change and change reinforcements. In any organization this needs to be done quite comprehensibly, because it is possible that there is no full alignment with the current values nor with the proposed change. Alignment with the change or the status quo is to be measured person by person, and the result should paint a picture of the spectrum of believes about the change. Figure A-4 shows a graphical depiction of different situations that can be detected as measured by internal alignment. Visions, values and behaviors of the organization need to be aligned with the change to make for a successful transition.

Figure A-4: Alignment in Organizations

Organizational alignment enables an organization to move in the desired direction. “Unified” alignment means that the organization has identified objectives, with the commitment of the necessary parts of the organization to accomplish a change. This is the situation to which a transition plan has to arrive, there should be no expectation that that is the state of alignment upon initiating the change. The other three states of alignment depicted in Figure A-4 are: “Chaos”, that implies that the objectives have not been identified and different parts of

Page 5: Mps and agile appendix on change

Boria et al.

Appendix A 5

the organization have their own objectives that are not aligned with the overall objective of the organization. The job here is to sell the change, usually best done by selling the problems that have given way to the need for a change. “Tug of war” generally occurs when there are limited resources and competing objectives, and the directives from upper management are either vague or contradictory. The work here is in finding common ground and avoiding the conflict that looms over the horizon. Usually problem-solving activities can make this happen and avoid the otherwise disastrous next state, “Full-scale war”, that happens when different components of the organization have competing objectives and the components have a hostile relationship. Once the war has been declared it is very hard to stop and, as in any war, there will be casualties.

In an initial assessment of the readiness for change, the adrenaline must be perceptible in the components and individuals, and champions can be easily identified. Be aware that sometimes champions can appear as opponents of change because they can be very vocal against the status quo and not so articulate about the proposed future state of affairs. In a hierarchical organization, adrenaline should run on all echelons. Upper management is either worried sick by the situation or licking its jaws to jump ahead of the competition. If adrenaline is not in place, the job for the change facilitator is to sell the problem, seek its ramifications (e.g. how much money is left on the table by lack of quality control), a process known as lighting many fires; or, if there is no perception of any interest in solving the problem, seek another problem or seek another customer.

A.4 Assessing the Organizational Culture

If the only parameter being judged is the proximity of the skills required by the change to the existing skills, relatively simple tests of such gap can be devised and applied. However, cultural values might run deeper than that, and the scope might then be more difficult to judge. So what is culture, anyway? Culture is an attribute of the community of an organization, not of any one individual, culture is conformed of collective values, believes, expectations and commitments, yet it actually affects individual behavior at all levels. It is what makes people do what they do. It affects rituals around the coffee machine, how to, and perhaps who, to greet in the morning. Where and with whom go to lunch. Who to ask for advice other than your direct boss. It encompasses the unofficial network of influences in the office. So we are dealing with believes. In particular, when we are attempting to change behavior we need to know what is a desired outcome, not only just the present status.

Fortunately there is a tool developed to investigate exactly such values. The tool, thoroughly researched by Cameron and Quinn

4 and based on data from 1500 organizations that generated 58,500 answers that were

statistically analyzed and resulted in two variables that define four quadrants, is known as the OCAI: Organizational Culture Assessment Instrument. A good description of it can be found on line

5. It is a very simple tool for

diagnosing organizational culture based on the Competing Values Framework, and used by companies worldwide.

The Competing Values Framework that gives the OCAI its validity is described in a book (op. cit.) and in many articles. We particularly recommend downloading Professor Cameron’s whitepaper for a detailed explanation

6

with enough meat and no excess. For an even shorter introduction, we will attempt to précis his paper here. Twenty years ago several studies into the effectiveness of organizations and the role of leadership were conducted at the University of Michigan. To the researchers surprise there were only two dimensions that consistently showed up consistently in all of them. One of them “differentiates an emphasis on flexibility, discretion, and dynamism from an emphasis on stability, order, and control. For example, some organizations and managers are viewed as effective if they are changing, adaptable, and transformational. Other organizations and managers are viewed as effective if they are stable, predictable, and consistent.”

7

“The second dimension differentiates an internal orientation with a focus on integration, collaboration, and unity from an external orientation with a focus on differentiation, competition, and rivalry. For example, some organizations and managers are viewed as effective if they have harmonious internal relationships and processes. Others are judged to be effective if they successfully compete against others and establish a market niche. This continuum ranges from cohesion and consonance on the one end to separation and independence on the other. (Kim Cameron, op. cit.)”

4 Cameron, K. S., & Quinn, R. E. (1999). Diagnosing and changing organizational culture: Based on the competing values

framework. Reading, MA: Addison-Wesley. 5 http://www.ocai-online.com/

6 http://www.haworth.com/docs/default-source/white-papers/an_introduction_to_the_competing_values_framework_white_paper-pdf-28512.pdf

7 An Introduction to the Competing Values Framework by: Kim Cameron, PhD

Page 6: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

6 Software Process Improvement with Agile Methods and Maturity Models

The OCAI probes the perception of the culture using six questions that require a pondered answer from individuals. Results can be averaged and grouped to analyze different sections and a second answer requesting the desired state can be polled to measure the gap and also the desired direction of the people in the organization. We use it to establish whether a purported change project is actually running against the grain or not, thus giving us a clear dimension of scope. If the paradigm that defines culture is, overall, a composite of values that support behavior, plus manners of thinking, plus management styles, plus problem resolution frameworks, it is important to know how these dimensions are affected by the proposed change and how this runs counter or not to people’s expectations. It is not impossible to modify behavior under the most extreme conditions, but it is certainly a lot more difficult and requires more time, more effort and more resources.

Treating the results with some roughness we can identify four quadrants, that the authors have given names that match the emphasis they carry. On the upper left quadrant they have placed flexibility on the vertical axis and internal focus on the horizontal axis; this identifies values that emphasize an internal, natural focus. The lower right quadrant identifies exactly the antitheses; values that emphasize external bias and a tightly control focus. Similarly, the upper right quadrant identifies values that underscore external, organic focus whereas the lower left quadrant emphasizes internal, control values. These competing or opposite values in each quadrant give rise to the name for the model, the Competing Values Framework.

Figure A-5: The Four Quadrants in the Competing Values Framework

A.5 Planning to Change the Organizational Culture

As we will see later in this Appendix a plan for changing behavior requires actions at different levels: we need to plan activities that help individuals achieve the required level of skill, we need to plan activities that change the reward system to nudge it towards the correct processes, and we need to plan activities that change how the managers ask for information and reward behavior. Effectively, we are attempting to change values.

A simple change might involve updates in how a form is filled. It requires but a short communication at the individual level. Changing a procedure might require multiple changes that a team or set of teams must learn how to do. This is obviously more difficult and requires more participation and interaction, even perhaps a simple pilot to how it is done and make sure everyone has understood what is required of them. But when we want to introduce a change that demands moving from one quadrant to another the culture is in play. The game changes. It becomes full-contact, all court and no prisoners taken. It must be tightly planned and even more closely monitored. Expectation of immediate rewards must be abandoned, long term will have to replace short term, and

Page 7: Mps and agile appendix on change

Boria et al.

Appendix A 7

on course corrections will be plentiful. The change management team will have to learn from each step in the way and constantly recruit new champions, listening closely to all involved.

Figure A-6: The Four Quadrants in the Competing Values Framework

Changing culture requires leadership. While management is coping with complexity, leadership is coping with change

8. Normal steering will not change the culture. A bigger effort with a larger perspective is required. A leader

is humble yet persuasive, strong yet flexible, listens and communicates. We particularly like the leadership charter of the Bristol Group. it reads: "Leaders at Bristow are committed to:

• Leading by example in accordance with the company’s core values.

• Building the trust and confidence of the people with whom they work.

• Continually seeking improvement in their methods and effectiveness.

• Keeping people informed.

• Being accountable for their actions and holding others accountable for theirs.

• Involving people, seeking their views, listening actively to what they have to say and representing these views honestly.

• Being clear on what is expected, and providing feedback on progress.

• Showing tolerance of people’s differences and dealing with their issues fairly.

• Acknowledging and recognizing people for their contributions and performance.

• Weighing alternatives, considering both short and long term effects and then being resolute in the decisions they make.

9"

Leaders are rare and in great demand. To attempt a cultural change without one is risky and not advisable. Managers who are not leaders tend to stick to the script, where cultural change demands innovation and disruptive behavior. Cultural changes are usually coveted because they are in fashion, the flavor of the month. “We are agile now”. “We are doing SOA now”. “Our organizations is now Six Sigma”. It is easy to see the benefits of a well conducted change, but few will like to discuss the pains of a calamitous failure. To succeed, do what you can with what resources you have.

A.6 The Path to Building Commitment to the New Culture

Conner and Patterson10

created a model of three stages and two thresholds that defines the steps taken in building commitment to organizational change. The model is very simple and imposes good practices. It reminds the change agent of how important it is to prepare the way to make the change possible.

8 John Kotter, What Leaders Really Do

9 http://www.bristowgroup.com/_assets/filer/2013/07/22/cobi_june2013.pdf

Page 8: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

8 Software Process Improvement with Agile Methods and Maturity Models

Figure A-7: Phases, Thresholds and Steps in Building Commitment to Organizational Change

There is a tendency to presuppose awareness. It is interesting to note that more often than not when someone is confronted with a “we” statement of the kind “we are adopting a new Management tool” the reading in people’s mind is “they are adopting a new Management tool”. Such framing results in ignorance of the change. If change does not address me, why should I worry? Hence there is a strong need to make sure that the individuals in the target zone grasp that they are in the change focus. This is usually best done by communicating the change from different levels and in different manners. Ken Johnson coined a witticism that is very much true: “communicate, communicate, communicate, communicate, communicate, communicate, communicate”. Even when the individual has reached awareness that the change is directed towards his job, she could be confused as to what is expected: of the change, of the job, of the person. Clearing up doubts and discussing problems is the job of this phase. In “Managing Transitions” William Bridges underscores that change happens when we allow the transition from the present state to the desired state to take place. This means that the change agents need to allow for the transition to take place, not to force it, but to encourage and accept subjective losses. Only when the individuals have reached an understanding of what is in the change for them, both good and bad, can they cross the disposition threshold.

Understanding per se does not take the individual to change. It can be, and often is, that the change is perceived negative and there is little support from the individual. Under such circumstances it is very difficult that the decision to change will be reached, and pressing it will only bring disappointment later in the process. The way to move towards the decision is to sell the problems and encourage learning the new skills, while promising to support the learning. Even then, the individuals rarely cross this adoption threshold on their own.

The best known way is to insert champions in the groups to support learning and making it so that the change is adopted successfully with very little effort. Following the dictum of surgeons, champions will perform one, supervise one and monitor one of whatever is the change. The process iterates until the group is satisfied that they can perform without support from the champion, who then moves on to another project. Part of the benefits of this approach are that the process can end as soon as the team is satisfied, and another is that champions are being generated along the way.

One final benefit is that each of these learning events can be treated as a pilot, where not only the team learns to perform the new process but the change management agents can get immediate feedback on their proposal and updated as necessary. This iterated approach, illustrated in Figure A-8, accelerates the diffusion of the change and lowers the cost of the transition.

Once the commitment threshold is crossed it is easy to move forward with little effort. The first two phases of the model are the ones that demand planning and attention, contrary to what is typically the focus of change

10

Building Commitment to Organizational Change. Conner, Daryl R.; Patterson, Robert W. Training and Development Journal, v36 n4 p18-26,28-30 Apr 1982

Page 9: Mps and agile appendix on change

Boria et al.

Appendix A 9

agents, the adoption. Adoption should result as a consequence of good planning in the first two phases. Institutionalization and Internalization are part of the model but do not represent planned steps.

Figure A-8: iterated Pilots for Continual Improvement During Change Adoption

A.7 The Adoption Curve

In the book Diffusion of Innovations11

, Rogers suggests a model that classifies adopters of innovations based on their level of readiness to accept new ideas. Innovative adoption characteristics are assigned to groups to show that all innovations go through a predictable process before becoming widely adopted. The groups consist of early adopters, early majority, late majority and laggards. The adoption of an innovation follows an S curve, also known as a logistic function, when plotted over a length of time.

Figure A-9: iterated Pilots for Continual Improvement During Change Adoption

The adoption categories are not attached to individuals, they are defined by the way individuals react to a particular change. The same individual can be an innovator with respect to one change and a laggard with respect

11

Diffusion of Innovations, 5th Edition Paperback – August 16, 2003, Everett M. Rogers

Page 10: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

10 Software Process Improvement with Agile Methods and Maturity Models

to another. What the model tells us is that we will have people interested in the change very early, yet they might not be representative of the adoption in total. Each category of adopters has its own motivation. Innovators aggressively pursue new technology, oftentimes before it is even tried by the company, regardless of applicability. They are motivated by technology, newness, change for the sake of change: “New is always better”; they hold an unshakeable belief in linear progress. However, their support for the change process is weak, they cannot influence adoption because they have short-term commitment to any particular innovation, hence they are not seen as “players”. Innovators go through change very quickly and without doubts. They cross the threhsolds on their own, but are disillusioned right after installation and go after “the next big thing”.

Early adopters share some traits with innovators, both are visionaries, but they differ significantly in why they do what they do. Early adopters generally rely on their intuition and vision, choose carefully, and have above-average education level. They understand the problem and have a vision of the solution. Their “There is a better way” mentality focuses them in solving a problem, finding a match for their vision of a solution, and this willingness to try a solution makes them ideal target for pilots. If they communicate well they can become change agents, but they might have problems dealing with pragmatists that have no time for visions. Early adopters go through the steps of commitment fast too, but they are able to sidestep problems and usually end with adoption if the vision and the solution align. This is why they are not always good at communicating with either majority, who require a detailed explanation and a step-by-step process, or a holding hands period.

Between the early adopters and the early majority lies the chasm. Solutions that might work in the first two categories, the visionaries, might have to be repackaged for the pragmatists, all the other categories. The first of such pragmatists are the early majority. They are quite comfortable with technology, and have a strong sense of practicality, but are unwilling to spend effort on an untried solution, they see it as not “their” problem. This makes it sometimes difficult to use early adopters to talk to them, because their attitude towards the change project is at odds. The process of conquering the early majority has been dubbed “crossing the chasm” by Geoffrey Moore

12.

We will give our own process for crossing the chasm in this appendix. In the meantime, let us finish the definition of early majority. Their motivation lies in real, immediate benefits, small investment, short time to return the investment. Thy sport a “Wait and see” mentality. Their support for the change process is weak at most, they are the target of the real “beach-head” effort; once they’ve bought in, success is just around the corner.

The late majority is defined closely to thee early majority, with thee added factor of a mistrust for technology. They “only work here”. Their motivation is routine. They like it that newness is gone and the standards are set in. Their support for the change process is nonexistent; they have to be considered because there is no institutionalization, much less internalization, without their participation.

Laggards are enemies of change, technology is feared and distrusted by them, for whom there is one way of doing things and it is the traditional one. They are by definition dragged into change, if at all, and often left behind. They will not adopt change unless they are not aware of doing it. When you are planning the transition you will not consider the laggards.

A.8 Combining it all into a Strategy

Changing behavior requires at the very least three basic activities that need to be carefully planned and executed: providing the required skills, providing resources for the transition (remember that during the transition the old and the new coexist and productivity will suffer), and aligning the reward system.

Training for the Job

The first task is determining how much training is enough training. The tool of choice in today’s world is known as competency modeling. Competency models start by building an inventory of the skills required to perform in any given circumstance within an organization, and understanding the hierarchy of roles attached to it. From an initial model describing the ideal organization in terms of the competencies required the analysis can progress to defining what will the future composition of roles, in quantitative terms, will be. If an inventory of current skills (competencies) is kept for each individual in the organization, it is easy to use computing power to define the gap between the organization’s current skill profile (competency) and the desired one. This gap will have two dimensions: How many individuals are needed to cover the needs of the workforce and for each individual that can be trained to perform above their current level of competency what is the leap that is required.

12

Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Geoffrey A. Moore.

Page 11: Mps and agile appendix on change

Boria et al.

Appendix A 11

It is easy to see the application of this to a future state resulting of the change. (A tool that is used to assess that last gap is shown in what follows.)

In this context a competency makes reference to the skill set and knowledge required to perform a certain task. It is the capacity to achieve a goal or result in given context in a certain period

13. When using a competency

model the world model applies to the abstraction created by analyzing the needs of an individual role. Each role is expected to perform functions, which are decomposed into tasks. Such tasks require skills that identify the ‘competency’ for the role.

Armed with the knowledge of how many people need to be trained and how much training is needed and of what type the organization can identify its training needs. This is usually a list of competencies that need to be furthered or introduced into the organization. The next step is to identify the training itself. The mapping starts at the organizational needs level and cascades down to the learning objectives of the individual classes. The learning objectives have to be clear in order to understand how to select among different offerings, or how to develop a class. The case in point, as reflected in, for instance, Bloom’s Taxonomy

14, is that a simple mention of the subject

matters will not define the learning process required to reach the skill level required. Using bicycle riding as an example, let’s say a class has as its content: 1. Bike components; 2. Staying on the bike while standing still. 3. Propelling oneself. 4. Steering the bicycle. 5. Stopping the bike: The brakes and the braking process. 6. Getting off the bike. Even if it reads well, the class could be taught completely theoretically and the result could be far from the level of practice required to master the process of riding a bike. If that was the goal of introducing the class in the first place, as opposite to develop a theoretical model of cycling, the class could well be considered a failure. Hence, attention to the aforementioned Bloom’s Taxonomy of Educational Objectives is germane to a well-designed class curricula.

Figure A-10: Bloom’s Taxonomy of Educational Objectives

While a simple reading can cover the lowest objective of remembering, the ones above require special activities. Understanding goes beyond remembering in that links and relations between elements have to be explained and articulated. Applying requires to include in the curricula exercises that can allow both to practice the skill and evaluate if the skill has been learnt. The higher the objective the more complicated it is to create the training class or activities. From our point of view as soon as we start discussing applying we suggest mentoring as the means to achieving the goal.

13

Scott Parry defines it as “…a cluster of related knowledge, skills, and attributes that affect a major part of one’s job (a role or a responsibility), that correlates with performance on the job, that can be measured against well accepted standards, and that can be improved through training and development.”

14 http://teaching.uncc.edu/learning-resources/articles-books/best-practice/goals-objectives/blooms-educational-objectives

Page 12: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

12 Software Process Improvement with Agile Methods and Maturity Models

Of course once the training program is defined it has to be implemented to be of use. Here an organization is again faced with many choices. While there are many types of training, only certain classifications and types are useful. Small business owners in Canada were asked which training methods they found to be the most effective. Here are their answers

15:

Type of Training Rating

Mentoring with another employee 63.7

One-on-one with trainer 53.2

Workshops and seminars 41.8

Classroom courses 25.9

Booklets and information sheets 13.9

The above types reflect the means by which training was delivered. Another way of looking at types of training is by focusing on what is the purpose of training. Since our central theme is the effectiveness of training, this will be our choice in classifying trainings: When the training is done for strategic competitive advantage, it must be done “just in time”. If it is used to enhance communication and expand understanding of other people jobs we will call it “just in case;” and if it is done on demand as a reward for the individual we will call it “just for fun.” Only the first category will be studied for effectiveness, while the other two will not.

Just In Time is based on the fact that only 15% of the knowledge or skill acquired through training is retained after a week. As cited in the Journal Accident and Emergency Nursing

16, describing the retention levels of ATNC

trainining, “three months after the ATNC knowledge levels appeared not to be statistically significantly different from pre-course levels, which suggested that retention of knowledge was poor.” Although results vary on the retention period, there is evidence it is very short: Unless the skill is exercised in less than two weeks, the person will have lost more than half of the ability to perform that she acquired in the class. Other results state that 90% of the skill is lost in six months. In all cases, it is painfully obvious that unless the skill is exercised there is no need to retain it. A combination of Just In Time, Just Enough and On The Job is the perfect combination to avoid this. Since mentoring is one of the better ways to package such an offering, it turns out to be a winning combination. It is clear that mentoring, in the form of JIT Training should be used for most, if not all, types of technical training.

Just In Case training provides individuals with exposure and insight into a particular subject. However, there is no manifest intention to make a practitioner of the student. JIC training provides an employee with abstract knowledge about a subject, possibly a process he or she does not have to follow but could benefit from knowing it exists. For example, a developer might take an overview JIC testing class to understand how his or her product will be tested, as opposed to Java training, where JIT will be used. One day the process might change and the testers will pass the tests on to the developers and they will have to use their JIC skills to test their own products. However it is very possible that JIT will be needed.

The long term benefit of JIC training is giving employees industry perspective; a view of the proverbial “forest” rather than just a particular “tree,” and enhancing their ability to integrate with others in the organization who are designing and implementing alternative solutions.

Just For Fun training provides employees with opportunities to develop skills in areas that may not even apply to their job directly. Engineers could take a course on presentation skills, or fictional story writing. A project manager may enroll in a class on American History. JFF is usually linked to moral and employee satisfaction and it is

15

Source: Canadian Federation of Independent Business, 2002 16

Nurses’ acquisition and retention of knowledge after trauma training, Jane Tippett MSc RGN, (Senior Sister, Education) Accident and Emergency Nursing, Volume 12, Issue 1, January 2004, Pages 39-46

Page 13: Mps and agile appendix on change

Boria et al.

Appendix A 13

used to improve the quality and motivation of the workforce without having a direct impact on the projects (or the employee’s marketability!).

The process then is quite linear in that it starts from defining needs and ends in data analysis of the results. In what follows we will develop these elements further to facilitate their use.

Crossing the Chasm

You will start with the visionaries, since they will be the first to approach you anyway. You don’t really care for innovators, but since they will come anyway you must deal with them. Your focus, however, is the early adopter. The early adopter will almost always catch whiff that change is being planned and approach the change management team. Make this happen: start from a company-wide communication and offer opportunities to contact the change management team. They will reach out to you. To talk to them, sell the vision, ask for their input. This should help raise awareness both on early adopters and the change team. This is your chance to learn where resistance will come from, and plan strategies to deal with it. You should listen to grievances and redo your plans to adjust the vision to learn from their experience. Turn the early adopters into champions and with their help plan a pilot. Using the map proposed in the previous subsection, train in skills. A pilot is not an experiment, is a test. You can pass or fail, so you should procure resources to make the pilot successful. Success is not enough to cross the chasm, but failure will prevent you from crossing it always.

As mentioned before in reference 12, Moore proposed a process to cross the chasm. The first step is to identify your target market. From this you should move to understanding the whole product concept, end to end and distribution. Using this knowledge, you will be able to position the product, and building a marketing strategy. Choosing the most appropriate distribution channel or channels will lead to the most adequate pricing. Correspondingly, we have translated these steps to the change management process. Translation is as follows: identify potential teams for the pilots, understand both the good and bad parts of the change, sell the problem and structure support for the adoption, plan the pilot for success, use classes, coaching, mentoring and champions and lower the cost of adoption.

This seems overly elaborated when compared with some of the strategies that are commonly in use. These are some of the most used and less effective: 3-day training in a quality model, such as the CMMI=DEV; half a day orientation in the CMMI; publishing the processes and decreeing it a standard; placing all your hopes on the reward system; “selling” the benefits to the people; trusting that the benefits will become evident with time and people will embrace change (if you build it, they will come); and making the change mandatory under punishment of losing the job, on day one.

The right way to cross the chasm is to start with the visionaries, using that experience to re-arrange your vision. Carefully select the entry project into the early majority that will be the pilot. Make sure it is highly visible, and assemble a dream team for this pilot, because, we repeat, success does not propagate easily but failure does. You can use some of the people that participated in the pilots with visionaries only if they can communicate with pragmatists. If the local resources are not sufficient, make sure that the pilot has enough resources, add external resources when necessary. Use training to homogenize the team’s knowledge before jumping into the fray and then switch to mentoring mode. Based on your experience, re-package products to make the effort easy to digest, for example make templates simpler, make process easier to follow, split the effort in steps if possible, tailor as needed and hold the team together as much as possible. You must gear the pilot for success, because failure is unacceptable, you will not recover from it. Bear in mind that guaranteeing success is not cheating, this is not a game, you are in this for the money.

After the first pilot hold a lessons learned session, as illustrated in figure A-8, to continually improve the process and the tools used to facilitate the adoption. Use the members of the pilot team to discuss the innovations and adjust them to different needs. If the effort proves too large, split it into as many steps as possible and necessary.

Figure A-11 illustrates the evolution of productivity in a transition. Initially either the productivity is stalling, or downright dropping, as in the graph. The change project is started in period 1. If productivity drops at the rate shown, it will take 12 periods to recover the same level as in the initial period. If productivity drops below zero, as shown in period 3 through 10, the cumulative loss is symbolized by the pink area. The goal of a good change management plan is to shorten the time to recover the initial productivity and minimize the cumulative loss. Whenever possible this can be done by splitting the improvement into shorter, cheaper, easier to adopt improvement. Of course, this is not always possible. When it is not, it is necessary to load the team with champions to make sure the learning curve is as steep as it gets. If you can split the

Page 14: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

14 Software Process Improvement with Agile Methods and Maturity Models

Figure A-11: Productivity Loss, Repayment Period and Total Costs

This implies that traditional approaches to change management will probably sink before they succeed for lack of sustaining funding. This argument is not pointed towards giving up on small companies, but rather to bring a fresh look to the problem and suggest a different approach. To diffuse innovation (i.e. the CMMI) in a small organization, the CMMI knowledge has to be acquired more easily or more economically, or both!

There are three ways we’ve seen small organizations deal with these problems. All three are focused on amortizing costs of the knowledge acquisition. If a company cannot pay for the learning curve as it is, it has to:

1. Share the costs with others, 2. Buy the knowledge as a package, or 3. Modify the learning curve.

Sharing Knowledge

The first approach, sharing knowledge acquisition with other similar organizations, usually is sponsored by federal governments and funded by it in the countries where we’ve seen it. MOPROSOFT in Mexico, SOFTEX in Brazil, and similar programs in India, China, Argentina and many other countries work on the same principle: Find a group of companies that are willing to build a coop to acquire knowledge in the market. Usually this takes two forms. One is to acquire existing classes that form those skills in the market, where the cost of the class is divided amongst the participants or funded by the governmental initiative. The other is to identify and hire Subject Matter Experts (SME’s) and share these SME’s across the participating organizations.

This approach has pros and cons. Pro:

1. There is a flourishing of such experiments going on, which should make this easy to implement; 2. It is easy to imagine and build such coops; 3. It is simple to bring such a structure to a quick start, and since SME sharing breeds improvement quickly, 4. The payoff is easy to detect. However, there are the following Cons:

1. We have witnessed significant reticence to share any information of any kind amongst participants, making it hard to benefit from economies of scale.

2. Besides, with small companies that are acquired or go bankrupt quite frequently, loss of participants midway is common and it increases costs for the rest.

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

-15

-10

-5

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Series1

Page 15: Mps and agile appendix on change

Boria et al.

Appendix A 15

Buy the Knowledge in a Box

The second approach is to buy the knowledge packaged into a software product. Referred to ironically as “Maturity Level in a Box” by facetious process consultants, in most cases the software contains the totality of the knowledge that the processes that it defines demands, even with support of a workflow engine to enact them. The most expensive packages allow the user to adjust the workflow to their needs. Depending on how difficult their tailoring is to the organization (or, sometimes, vice versa), the software packages require support from specialized consultants for their installation. As in the previous case, there are pros and cons with such an acquisition.

Pros are:

1. Very fast installation time; 2. Is relatively easy to adopt; 3. The libraries are complete by design, and they are well structured. Cons are:

1. It is too dependent on the support of consultants; 2. Could be too expensive for a small organization to buy; 3. In most cases, the organization has to adjust to the product, not the other way around. 4. The road to growth is decided by the software provider, not the organization.

A.9 Partitioning the Transition

The third successful approach is the focus of this chapter. It is based upon breaking down the learning curve, as shown below with an imaginary example of activities. We have called it minimalism, since it is structured to introduce minimal change at each intervention to solve a particular problem every time. In this approach, the skills are not taught in a large, one-time, one-size-fits-all, encompassing approach. Instead, Just In Time, On The Job, Just Enough Training is provided in a coaching format. Every intervention deals with a particular problem. When the problem is solved, another one replaces it in the focus of the improvement team. These are the reasons for our suggested approach: Small organizations cannot fund large changes. The cost of the transition could prove to be too much, whether the ROI is large or small. Successful small organizations tend to have mastery of technology. Adding technology to support activities is welcomed. Small organizations usually have large returns on people’s time. If you free ten minutes of everyone’s time every day the payoff is significant to the bottom line. Based on these three hypotheses, we have developed and successfully implemented an approach that we now proceed to explain in detail.

Parsimony in Process Improvement

Our approach has the following characteristics:

1. It sells the problem, not the solution 2. It focuses on freeing resources, not in tying them down 3. It is based on implementing processes through technological changes (the total opposite of what is

recommended for most organizations) 4. Every intervention in process improvement solves a real business problem. It is important that this intervention be limited to the problem at hand and not to implementing the model.

The perception of a process-focused approach is that foreign elements are interfering with productivity by introducing unwanted changes. Solving problems, instead, is everybody’s business. It follows that this intervention should respect the organizational culture. As process improvement change agents, we are there to help. We cannot achieve successful changes if that change violates or attempts to transform the local culture. If those changes have to take place (and sometimes you cannot avoid them, e.g. one cannot jump a ten feet chasm in two five feet hops), they should be strategically presented by upper management and require a plan of their own.

So where is the change? The sum total of all interventions implements the model practices, as an end point and not as a starting point. The change agents are knowledgeable of the change target practices, and when selecting procedures to solve process problems, they keep them in mind.

The Parsimonious Process is as follows:

1. Identify a high-priority business problem related to some development processes 2. Identify actions that solve this problem or avoid its repetition 3. Implement these actions and adjust them to achieve the desired effects 4. Measure the effect of change

Page 16: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

16 Software Process Improvement with Agile Methods and Maturity Models

5. Iterate from step 1. This approach has obvious advantages in terms of organizational change. It brings immediate results, which in

turn make the next change easier to sell, hence it accelerates change adoption. The approach, since it focuses on projects rather than process, breeds growth of the company. However, the approach is not without cons. It requires high-end consultants that know how to frame and solve problems, with a strong interpersonal relationship skill set. These people are not, contrary to popular believe, a dime a dozen. Moreover, this person or persons have to be aware that the approach is subject to scope-creep: “Since we are changing the plan template, let’s include a new estimation technique. And since we are introducing a new estimation techniques, we could use this to introduce the Earned Value Method. And this brings me to a real nice improvement that we can also add…” You get the picture. Another possible downside of minimalism is that the whole organization might lose track of the maturity goal. This, after all, might not be a bad thing, but if the company is in need of the appraisal publication, this is unacceptable. For this last reason, we have found the approach difficult to sell to management focused only on the level.

Figure A-12: Short Interventions with Short Repayment Periods

Because change in a software product is linked to requirement management, configuration management and issue tracking, a process covering all of this is possibly a good idea. Therefore, it is tempting to try to implement all of the changes at once, resulting in a long repayment period and possibly a huge loss of productivity in the transition. By splitting the changes one can wait until productivity is regained, often with improvements, before introducing the next change. The resulting curve is much more manageable financially, looking a lot like the one shown in Figure A-12.

A Case in Point

We will now describe in detail an application of the parsimonious process of our minimalist approach in a small setting. This group was a small, highly specialized software development group within the confines of an international company. The company reinforced independent thinking and rewarded individualism. There was a large resistance to process and the people considered CMMI as a bureaucracy-inducing model. However, the projects were experimenting problems that showed the need for changes. These changes were analyzed and prioritized by the process improvement team. The list, shown below, was approved by the project sponsor and then implemented in many small steps.

1. Control tasks.

2. Establish individual assignments

3. Define artifacts associated to every task

4. Increase the task granularity (i.e. make the artifacts smaller)

5. Introduce simple measurements

Page 17: Mps and agile appendix on change

Boria et al.

Appendix A 17

6. Define base lines as a concept and in practice

7. Bring configuration items under change control

8. Add requirement development tasks to the work structure

9. Define quality attributes for requirements

10. Define completion criteria and make them be honored

11. Build indicators from the measurements already captured

12. Generate reports based in those indicators

13. Meet regularly to analyze the indicators and act upon the results of the analysis

14. Identify risks and include all action plans in the issue tracking system and, if needed, in plans.

Once approved, the team decided that any change should be introduced with a tool that supported it. This decision was based on the particulars of the organizational culture. Changes that were seen as facilitating the evolution of a product were easily accepted, and the culture had no problem with tools. Adopting a tool required a mere explanation of the problem to solve. Once the implementation began, priorities changed, so that in effect the previous list changed. The activities, as they were executed, follow.

1. An issue tracking system (ITS) was introduced; and everything was considered an issue (tasks, risks, action plans, etc.)

2. Each issue required attention. Assignments were introduced through the ITS. All activities were entered in the ITS and all completion was reported through the ITS. This established a monitoring mechanism on its own right.

3. Outputs were linked to issues. We simply defined a field on the ITS Issue definition screen to allow input of the associated artifact.

4. To turn the granularity up, we started by considering tasks that were longer than a week as “too long,” then broke them up to hold them to a week or less. As a consequence, the artifacts were broken up too, so that an item was linked to an individual task.

5. We then put the “plan baseline”, as defined by the collection of issues, under change management.

6. Consequently, the corresponding items were also put under configuration management.

7. We then added the tasks to create requirements that were related to items to the process. Before, these requirements were captured but this activity was not planned.

8. Next, we defined quality attributes for Requirements.

9. Using these attributes as a starting point, we defined the completion criteria for all of the items in a project. In effect, we introduced verification. (To verify that the items were complete, the team had to test and measure against goals, or inspect or peer review an item). Initially these were considered activities within the task of creating the items, but very soon these activities had become issues themselves. Furthermore, the activities were identified as a sequence of QA review, formal technical review and approval, each with its own responsible person and outcome.

10. By now a large number of items were regularly created and managed. It was then easy to create a structure of folders with privileged accesses that reflected the promotions an item underwent. A folder for each step was created, so that presence in a folder could be associated to the criteria defined above. These criteria were then strictly enforced.

11. These activities soon gave birth to a set of measurements. Considering them by themselves, they did not send any clear message, but combined into indicators from the base measures they indicated the rate of progress and were a great source of information for managers. We generated our weekly and monthly reports from these indicators.

12. The reports were analyzed in manager meetings to review them and act on them.

13. These meetings naturally evolved into identifying risks from all of the above. Using our ITS, we created plans to eliminate, trade, mitigate, track and/or use contingency to manage our risk.

Page 18: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

18 Software Process Improvement with Agile Methods and Maturity Models

14. Once the projects adopted these activities and saw their usefulness, we used the macro-activities in the ITS to define associated processes and saved them separately.

15. For every activity and task with defined responsibilities (and by the time we got to this point, they should have been all), we created a model of competencies required to successfully perform the task.

16. We then used this competency model to plan and execute training for all the team.

By following these individual steps the organization created an ever-increasingly stable environment, with little disruption in every intervention. Every time a step was introduced, the need for it was highlighted by pointing at the yet unsolved problems.

A.10 When Parsimony is not an Option

Not all projects can be designed and executed according to the needs of good practices. Sometimes external factors, political or otherwise, can interfere with the best intentions. In another customer the need for sudden and drastic change was too big to allow us to parse it into a cascade of steps and roll it through the organization. In that case we had to come up with a BHEP (Big, Hairy, Expensive Plan).

The following matrix shows how we operate under those circumstances. The basis for the matrix is the commitment steps. You might want to be careful in meshing this with the adoption curve, but you will have to operate very fast anyway, so your best bet is to work with as many members of the organization as you can. Of course, this brings up the need of a large number of well-prepared change facilitators, which is not an easy order to fill. Our matrix shows the scope of effort for each step, the tools of choice and the potential for failure of each step.

Step Scope of Effort Tool Potential Problem

Contact Organization, Sections, Teams, Individuals

Frequent repetition from the top

Denial

Awareness Teams Workshops, focus groups, Listen!!!!

Pain and fear

Understanding Individual or teams Training and coaching Negative balance

Decision Individual Recruiting through mentors or champions

Stalling

Installation Teams Phase transition workshops

Not enough well prepared facilitators

Adoption Organization Simultaneous push for change. Public announcement. Reward system change

Leave someone out of the process

Institutionalization Organization Share improvements and know how using champions

Silos

The contact phase should be initiated as a massive beach head operation, the landing of an army in hostile territory. An announcement that “something big is in the making” should precede a meeting in which the top echelons will announce the change, the plan and introduce the main facilitators. This announcement should be registered in the local media, bulletin boards, the initial page in the intranet and the internet, newsletters, a header in every email, something that makes it impossible to avoid noticing it. Immediately after the global announcement each section will hold its own meeting, interpreting “what is in it for us”, in order to avoid the “when they said we they did not mean us” syndrome. Even after that every team should get together and discuss the change and plan as in how they can help and how they will be affected. These meetings will continue at the individual level to make sure that individual roles are understood in how they change.

The awareness step is marked by organized workshops with semi optional attendance: individuals choose when to attend, but they can be coerced into completing a roster. By the end of the step, which has clear timelines, the whole organization has gone through them. The understanding level of Bloom’s Taxonomy should be complete in what is related to the vocabulary and nature of the change. It is not expected that the individuals can

Page 19: Mps and agile appendix on change

Boria et al.

Appendix A 19

transition, but that they understand what the transition means and what it entails. The purpose of these workshops is to raise awareness and to gather information on resistance. These workshops are short, one or two hour events that can be covered very quickly. The information gathered should steer quick changes in the next step.

Understanding goes beyond awareness in that there is an added goal of application of some of the skills required by the new roles and processes. These will imply toy exercises that familiarize the change targets with the future, but it does not expect that this training will give them what is required to go through the transition on their own. The workshops in this phase are longer and should build confidence in that the change is, at least, possible. During this step the trained eye will detect resistance and build a plan to deal with it.

Whenever possible the initial efforts will be dedicated to teams that show little resistance. However, this is hardly possible when the organization wants everything to be done in parallel. We deal with this by assigning champions to the most recalcitrant focus of resistance, to guide them through the decision to adopt. This leads directly to the next step, installation.

Installation in such cases is performed through the use of phase transition workshops, called launches. In these launches the goal is to do just-in-time, just-enough and on-the-job training. The result is that a large amount of effort is packed up front in the project’s phase, resulting in optimism and efficiency. Figure A-13 shows how workshops will affect results.

Figure A-13. Parameter Changes in Putnam-Rayleigh Curves With and Without Phase Launches

Most teams will need only one set of doses of champion-led launches, end to end; the second time around the new process, the team will run the launches themselves. Quality assurance will suffice to control that the process is well followed and that the results are good enough. Other teams will require more participation by the champions. The best teams will even provide the change team with fresh champions. Even when you are not using real pilots, the very first batch should be treated as such and the lessons learned applied to the next iteration, as in figure A-14.

Figure A-14: Lessons Learned Applied Between Cycles

Page 20: Mps and agile appendix on change

Software Process Improvement with Agile Methods and Maturity Models

20 Software Process Improvement with Agile Methods and Maturity Models

A.11 Resistance Happens

Whether change is perceived as positive or negative, it is always disruptive, and resistance inevitably arises as an answer to it. It comes from the fact that the old is known and the future is not. Resistance has many different faces. It can be passive: for example, the people at one very large car manufacturer are so used to quality fads that their attitude to the CMMI initially was disinterested – this too shall pass; there will be another change coming along soon. In many other places we have seen stalling tactics, excuses – too much real work to do, as if process improvement were not in their job description. Sometimes, resistance can be active, confrontational; sometimes even subversive. Managers who are not skilled in managing transitions tend to dismiss these symptoms as the ranting of a few. They operate under the assumption that if you build the “right” processes the people will use them

17. In turn, when it does not happen, these change agents are mortified and blame the rest of the world.

Resistance cannot be ignored – it too must be managed. A change agent must understand concerns and issues, and be able to explain the change from the affected groups’ points of view. Only by walking a mile in their shoes we can start to understand the pressure they feel. This is the role of the workshops in the awareness phase.

Borrowing from a model of how people grieve when confronted with their own mortality change agents deal with resistance. The model was first introduced by American Psychiatrist Elisabeth Kübler-Ross in her 1969 book, On Death and Dying, and was inspired by her work with terminally ill patients. The model is a series of emotional stages experienced when faced with imminent death or death of someone. The five stages are denial, anger, bargaining, depression and acceptance. Change agents have applied it to individuals when they are facing a transition that has disrupting consequences. Clearly it has to be taken with a grain of salt, since even when a transition signals the death of something it is not as tragic as the death of a person. Moreover, Kübler-Ross noted that the stages are not meant to be a complete list of all possible emotions that could be felt, and they can occur in any order. Her hypothesis holds that not everyone who experiences a life-threatening or life-altering event feels all five of the responses, due to reactions of personal losses differing between people. In any case, we can use this model to anticipate some of the most common reactions to loss.

Given a disruption of the status quo, even when it is perceived as a poor state of affairs, some individuals might perceive this as a menace to their personal position in the organization. Their first reaction, in line with the first step of the building commitment to organizational change model, will be to reject the idea that the change applies. Denial is the most common reaction to the announcement, and that is why the first phase in our program is to communicate the change loud, clear and often. For those that find the change too menacing the reaction is anger and rage. Don’t take anger and rage, even when directed at the change team or a particular change agent, as personal. Keep your discourse assertive and receptive. Listen a lot. Ask for explanations, deal with possible changes to your plan as a possibility.

Figure A-15: A Particular View of the Stages in Kübler-Ross Model

17

This makes matter worse, since it produces a huge pressure for an “ultimate” process, slowing things down and creating monster process documents.

Page 21: Mps and agile appendix on change

Boria et al.

Appendix A 21

Maybe the anger is at least partially justified even when wrongly verbalized. You will recognize bargaining as a request for partial implementation or postponing the transition. When that is not an option the reaction will probably be a total lack of collaboration that will sink the level of emotional commitment to very low levels. If you do not support the individual in the transition the cycle could repeat itself. The role of the phase launches is to do exactly that, make the individual test the transition in a safe environment and, hopefully, adopt.

A.12 Conclusion

Change is hard when we try to guide its direction. Left on its own, it will always go somewhere, only not where the organization needs it to go. To guide the change one has to focus on the transition. Ideally, a change can be split into smaller changes to lower transition costs, especially loss of productivity. When that is not possible, a large, concurrent effort has to be put in place and the individuals involved strongly supported in their own process to adopt.

Austin, August 2014