Chapter 7. Change
Lydia was happy that the team had now optimized its interactions. Everyone was aware of the natural and adapted behavioral traits of one another on the team. All team members respected one another and understood why team members behaved the way they did.
Lydia observed another issue. Some members of the team felt less comfortable with the changes associated with their relatively newly adapted agile approach.
A True Story
In early 1984, the headquarters of a large insurance company in Texas was in the throes of email adoption. As with many companies at that time, the promising new technology had a provocative return on investment. Benefits included increased productivity through faster communication, elimination of the typing pools, reduction of secretarial positions, and most significantly—paper savings.
The hundreds of thousands of pages per year that were typed, distributed, read, and discarded would be virtually eliminated. With this new technology, it was possible that paper could completely disappear from the office scene. The business case used to justify buying all the fancy new computing equipment was based completely on the cost savings from less paper.
The implementation team was unprepared for what happened. Although many of the new “office automation” users were enamored with this new toy, many others resisted. Logging into this new system to get access to intra-office communication was tedious, and it was easy to forget to check. The “old way,” glancing over at the inbox on the corner of the desk, was more intuitive and efficient. It had been much easier to know if there were a memo to read because it would be there, easily visible inside the inbox.
Because a faction of users resisted using the new electronic mail system, it was useless for others to use it as a reliable way to communicate. It hardly seemed worth the trouble to send someone an email if there were no way to know when and if they would actually see it. Nevertheless, they didn’t have a choice because they no longer had secretaries and typists to create memos for them.
For many of those who used the new system, reading memos online was a chore. Because they were so accustomed to reading memos on paper, many of these people printed every email. Because the volume of emails was greater than the volume of paper memorandums, paper consumption was an order of magnitude more than before email. The unexpected printing volume thwarted any chance to meet the return on investment goals, based on the original paper savings-based ROI formula.
So why all the fuss? The company made a huge investment in some cool technology that would make everyone’s life easier. How could anyone possibly resist? This true story is a great example of the power that change resistance can have on a company, a department, a team, and even individuals. By overlooking the resistance to change, implementation and adoption of the new system became much more laborious and expensive than originally planned.
Project teams adopting new approaches such as agile often encounter resistance as well. This resistance often has no logical or rational basis, yet it can be powerful enough to impede adoption of better, more efficient ways to run a project.
Why Is Change Difficult?
In 1589, Gerardus Mercator created a world map that would forever impact the way the world is viewed. The Mercator Projection flattened the world and significantly skewed proportions of the land masses. For example, the Mercator map greatly exaggerates the size of Alaska, Greenland, and Europe, while at the same time depicts Brazil and Africa as significantly smaller than they actually are (see Figure 7.1).
Figure 7.1 Standard Mercator projection
Looking at a map based on the Mercator projection, it’s not too difficult for most people to pick out the United States, Africa, South America, and China. Put your finger on the map near your home town; then follow a line depicting a trip from your home town to the center of the east coast of Australia.
Your understanding of the map, and our ability to navigate the map, is learned and conditioned over time. The more often you see the standard Mercator map, the more you internalize it as the true representation of the world.
Now, what if the map were turned upside down? Using the map in Figure 7.2, try plotting a line from Los Angeles, California, to London, England. Although those are two well-known cities, most people find this task much more difficult because the map is upside down.
Figure 7.2 Upside-down Mercator projection
An upside down map isn’t as unnatural as it may seem. Most people don’t realize that placement of north on the top, and south on the bottom, was an arbitrary decision made by an early mapmaker named Ptolemy. In the first century AD, most geographic areas known to Egyptians such as Ptolemy were in the northern Hemisphere, so he chose to place them on the top of the map. Other mapmakers followed suit, and hence north on the top became a notational convention.
Over time, Ptolemy’s simplistic arbitrary notational convention defined people’s visual understanding of geography. If a mapmaker in today’s world were to depict a geographic area with north on the bottom and south on the top, the map would be rejected by most people. Adapting to that type of change would be uncomfortable, and the learning curve would be undesirable.
Despite this awareness, many people involved in project work can be ignorant of the effect that change has on others. When building a new system, the software developers’ livelihood is based on creating change. At the same time, the world of many users of the new software may resist having to learn new tools.
When Microsoft introduced Office 2007, it made a radical overhaul to the user interface. Microsoft touted these changes as much needed enhancements to the interface, yet many consumers complained about them. “Better” is a relative term, and from the perspective of many consumers, Microsoft did an inadequate job of defining “better.”
Process change is unsettling to many as well. Some people may jump at the chance to try a “shiny new” process such as Scrum or eXtreme Programming. Many others, though, will be overwrought with concern about abandoning old skills, developing new skills, extensive learning curves, and reduced positions of power based on years of experience doing things the old way.
Change Squirm
At 9:00 a.m. on Monday morning, Joe walked to the front of the room to launch into his usual kickoff speech for the two-day training class he was about to teach.
Joe started, “Good morning, my name is Joe, and I will be your instructor for Agile Software Development for the next two days. It’s always a good idea when starting a class for us all to get to know one another.” At that point, Joe said nothing. He looked around the room, making eye contact with those students who would permit it. Joe moved from the front of the room to this side and then to the back, continuously paying attention to the students but saying nothing.
After no more than ten seconds, students were already starting to look around at each other. Some made inquisitive gestures, whereas others just looked confused. After a while, a soft murmur started to bubble up from the group, which eventually turned to a smattering of nervous laughter.
Joe created an uncomfortable environment for his students by doing absolutely nothing. In this case, nothing was actually a whole lot. Joe changed the rules without letting anyone know. Those who had ever been in a training class before knew that after his introduction, Joe would likely go around the room and ask people to introduce themselves (or conduct some other form of an interactive ice breaker).
Moments before all this happened, the last of the students had settled into their carefully selected seats, adjusted the seat height, placed their coffee next to their freshly unshrink-wrapped course notebook, and relaxed for a predictable stress-free course introduction.
The silence that Joe created was awkward and painful, and most of the students likely wanted it to end as soon as possible. The awkwardness centered on the uncertainty. Nobody knew what was happening or what was about to happen. This change to conventional expectations put the students outside their comfort zone. You can only imagine their relief when Joe finally broke the silence!
Change Apprehension
Many people dislike change due to fear. Any individual’s level of change apprehension is usually due to fear of disruption to core needs. In Chapter 4, “Communication,” a depiction of these core needs was shown using Maslow’s Hierarchy of Needs. Using that model, you can recognize that at the tip of the hierarchy, changes (or anticipated changes) to those needs can cause apprehension. As you move down the hierarchy to the basic needs, the apprehension increases by orders of magnitude (see Figure 7.3).
Figure 7.3 Impact of change related to the Hierarchy of Needs
Fear of Changes to Self-Actualization Needs
This level of the hierarchy is focused on people’s needs related to how their job functions, roles, and responsibilities may be affected by the change.
Individuals who enjoy a high level of creativity in their job may stress about a change that is going to restrict their creative outlet. Perhaps the introduction of a new highly prescriptive process will remove their ability to make spontaneous decisions about what should be done and when.
An accomplished painter would be uncomfortable if required to paint using a paint-by-numbers kit. Similarly, individuals who are motivated by their ability to solve problems creatively and autonomously will be uncomfortable when told to step in alignment and follow a structured process.
The reverse situation is also true: individuals who prefer following a prescriptive step-by-step process when told to rely more on intuition, experience, and instinct.
Fear of Changes to Esteem Needs
When introducing process changes, there can often be an impact to organizational status. Those who like managing other people may fear a change to a flatter organization in which supervisor/subordinate roles are shuffled around. A seemingly subtle change can cause undue stress to some individuals: changes to job titles. Many individuals work for years to climb the ladder of job titles, and to some, the title can be more valuable than a corresponding salary increase. This is especially true when these individuals’ workplace motivators are individualistic/political (see Chapter 8, “Motivators,” for more details).
When a Scrum coach announces to a new agile team that all former titles are going away and will be replaced by these fancy new titles, this can be perceived by some as stripping away stripes that were earned over years of sweat and loyalty. A cavalier pronouncement of the abandonment of job titles can cause a great degree of stress for members of a team.
Fear of Changes to Love/Belonging Needs
At the Love/Belonging level the initial instinct is to think of family and loved ones. Certainly any change that can have an impact on the quality of family life can cause fear and stress.
Beyond family, many sociological units exist within a company that individuals may fear being separated from. When reorganizations happen and new project teams are formed, many thoughts will run through individuals’ heads, such as the following:
• Will they like me?
• Will I have someone to eat lunch with?
• Will somebody on the team be interested in talking about my Fantasy Football team with me?
Fear of Changes to Safety Needs
Any change that can cause concern about job security and continued employability fall into this category. Even if management states that training and time for reskilling will be provided, the fear may still often be present. The only certainties related to an employee’s skills are those already present. There is never a guarantee that new skills can and will be acquired and honed in a timely manner.
John the project manager, who worked hard to earn his Project Management Professional (PMP™) designation, was told that he will now be a ScrumMaster. Further, he was told by an agile consultant that his “old school” project management skills are no longer useful. Whether that statement is true or not, John may develop fear at multiple levels. He may fear loss of his job if he doesn’t do well in the new role, which carries with it changes to the relationships he has developed with his colleagues, loss of esteem by having his title stripped away, and loss of job responsibilities that he enjoys doing.
Fear of Changes to Physiological Needs
The base of the needs hierarchy, those fundamental needs that stand above all, includes the needs for food, water, sleep, air, and so on. Pure human instinct ought to be enough to ensure that these needs are met. Some may think that they can’t be affected by change in the workplace. However, that’s not the case.
When new project teams are formed and new processes are introduced, often some individuals will worry about changes to their eating and sleeping cycles. When the eager new ScrumMaster announces that the daily standup meetings will be held at 7:30 every morning so that “We can launch every day bright and early on the right foot,” it’s bound to be met with resistance.
James may complain that this interferes with taking his child to school, which could be accommodated as a valid reason. However, Mary has a productive sleep cycle that would be disrupted if she had to get to work before 9:00 a.m. Although James’ excuse may be seen as valid, Mary’s may be scoffed at as trivial. Coming in an hour and a half earlier could completely disrupt Mary’s productivity and mood.
Change Coach
An experienced individual such as a consultant can be brought onto the team to coach the members through the change process.
Many coaches in the marketplace tout their skills in agile software development, which can qualify them to be good coaches. When hiring a coach, you also need to assess the coach’s skills at managing individual and team changes. A good coach is skillful at identifying and addressing the many fears of change so that they don’t stand in the way of advancing the project forward.
Imagine Jenny’s boss Fred noticing that she seems to have self-confidence issues. Is it advisable for Fred to give Jenny a book titled How to Improve your Self-Esteem? Certainly it’s possible, and ethical, and maybe even appropriate to some. However, is it advisable? Self-help is usually only effective when it is self-driven.
In the same spirit as not handing someone a self-help book, an effective coach helps an individual understand and rationalize barriers to change so that they can be removed.
Change Catalyst
Change in the overall dynamics and behavior of a team can change as a result of one individual’s behavior. When the team captain of a losing basketball team steps up his game while encouraging everyone else to do the same, he can positively affect the behavior of everyone on the team. If another team member who isn’t in a leadership role were to do the same thing, it could still potentially boost the productivity of the rest of the members of the team.
In business, inserting a highly productive person on a team has the capability of positively affecting other team members’ productivity. Some may follow suit out of shame or competition or perhaps just out of respect or admiration for the positive role model.
The role model can work against the desired goals of a team as well. It’s also possible for the behavior of an entire team to be negatively influenced by one team member. Dr. William Felps from the University of Washington Business School ran an experiment in which he assembled groups to solve a problem together. Felps assembled groups of individuals to participate in a problem solving exercise. One participant was a “plant”—a confederate trained by Felps to behave a specific way.
In the first group, the confederate behaved in a manner that Felps labeled interpersonal deviance, which is referred to as the “jerk.” The jerk was quick to dismiss others’ ideas for solving the problem, yet he didn’t offer concrete solutions of his own.
In the second group, the confederate withheld effort and is referred to as the “slacker.” The slacker showed little interest in the problem-solving exercise and leaned back in his chair with his feet up on the table while texting on his cell phone.
In the last group, the confederate showed affective negativity, or the “depressive.” He told the group that his cat just died and took on the appearance of a person in despair. He expressed doubt that the group could succeed at the unpleasant exercise.
When conducting this experiment, Felps found that the confederate’s toxic behavior became contagious; it catalyzed negative behavior across the team. The confederate’s jerk behavior begets jerk behavior by others on the team, and the same was true for the slacker and the depressive. The negative effect of the bad apple drove down the rate of success on the problem being solved.
Negative behavior has a more profound emulating affect on a group than positive behavior. In other words, team members are more likely to adopt the behavior of a negative individual than they are to adopt the behavior of a positive individual.
It may not be possible to eliminate bad-apple behavior completely. Although some individuals may regularly exhibit negative behavior, it’s possible for any or all team members to behave negatively on any given day. Therefore, to avoid the bad-apple effect, it’s best when the team maintains conscious awareness of the effect so that it can expose it and shut it down when it appears. This may sound good on paper but requires a highly mature and self-aware team.
Tracing to the Roots
Most current pop, rock, and jazz songs last approximately three minutes, more or less. For years, the music industry was built around that parameter. Why not ten minutes, or five minutes, or one minute? How was it decided that three minutes was the default duration of a single?
In the early 1900s, most recordings were sold on seven-inch 78 rpm discs. The groove on these discs could hold a recording up to three minutes and five seconds. To sell a song, a musician was constrained to this time limit.
Modern recording and music distribution technologies have eliminated the physical constraint of the length of a song. Nevertheless, the music industry has grown up around the notion that a single is three to four minutes long. Some artists deviate, of course, but most single track recordings still conform to that arbitrary constraint. If a new artist were to release a series of six-minute songs, it’s probable that listeners would notice that they are unusually long. When things become a certain way, it’s difficult to change even if the original purpose no longer exists.
Grass Roots Resistance to Change
Often a process, system, or organizational structure has passed its reason for being long ago. Nevertheless, changing or eliminating it can be an uphill battle. When routines become habit, and habits become comfortable, change or elimination can become seemingly impossible.
Recall the upside-down map from the beginning of the chapter. Putting the northern hemisphere on the bottom of a map is certainly possible; however, widespread adoption of that change would be an extraordinary undertaking, even if everyone agreed that Ptolemy’s decision to put north on the top was an arbitrary one.
The approximate calendar used by most schools in the United States begins in late August or early September and continues until late May or early June. This was originally established in the nineteenth century in rural areas to enable children to be home to work in the fields during the summer. About the same time, wealthy families in big cities pressed for longer vacation periods in the summer so that they could escape the heat of the city.
There have been efforts in recent years by some school districts to change to a year-round school calendar with breaks distributed throughout the year. A goal of the year-round calendar is to provide students with seamless continuity from one grade to the next.
In 1991, Northside School District in San Antonio, Texas, was one of many school districts in the United States that introduced a pilot year-round school program. The program was deemed a success by the families that had volunteered to participate in the pilot. The two-week break in October was touted as a great benefit because family vacations were possible while the weather was still nice but the crowds were gone.
When the school district tried expanding the program beyond the pilot, however, it was met with tremendous resistance from parent groups. Many of the complaints were based on logistical concerns such as arranging childcare during several short breaks versus one long break. The primary reason most objected, however, was resistance to change. Elimination of the traditionally long summer vacation was perceived as too dramatic a shift from what people were used to.
Although some year-round school programs still exist, most were abandoned. The force of resistance was far too great for the resources of most school districts to contend with. The introduction of change in companies often can also be met with frustration and great forces of resistance.
Pushing change from the top-down is always certainly possible, but in the face of that, grass roots resistance can block change. Change can be imposed, but it may not accomplish its goals if there is sufficient force working against it. For this reason, pushing change from the top-down should be complemented with acceptance and support from the bottom-up as well.
Exposing the Origins
When encouraging change in the face of a fear of change, it can be helpful to expose the origins of the conventional processes. Just as the school calendar was based on expired needs, many processes in business were conceived based on traditional requirements that are no longer valid.
Many traditional project managers use a Gantt chart to depict the project plan. The Gantt chart was developed by Henry Gantt in 1910. The first major project to use it was the construction of the Hoover Dam. For years, Gantt charts were used for managing construction projects—many decades before the existence of software projects. Many of the earliest software project management processes were based on processes that had been used to construct buildings and roadways.
Building software, particularly with current-day tools, differs greatly from building and roadway construction projects. Building construction projects usually require comprehensive planning and design before actual construction can begin. On software projects, however, creative choice during construction is permissible and actually results in software that better meets customer needs.
For most, Gantt charts are hard not to like. They align well with the way most people think about organizing work. Consider the following example of the tasks involved in a family cleaning a house:
Clean the kitchen.
• Clean the oven.
• Clean the dishes.
• Clean the refrigerator.
• Clean the floor.
• Clean the counters.
Clean the family room.
• Vacuum the floor.
• Dust the furniture.
• Clean carpet stains.
And so on...
Sequence matters for some of these tasks because they depend on other tasks having already happened, whereas others could be done at any time. Say you have four workers: Joe, Tim, Nikki, and Danni. By assigning these workers to specific tasks, you could lay out a neat plan for getting the house cleaned in a quick efficient manner.
Some days, this plan could be executed flawlessly with a high degree of predictability. At other times, it could fail miserably. Perhaps a worker gets sick, or the vacuum cleaner breaks, or the carpet has grape juice stains that require additional effort to remove.
Projects with a high degree of creative choice, however, don’t usually work well by following a prescriptive step-by-step serial plan. Choices of what tasks to do and when to do them is often more spontaneous than in the house cleaning example. Tasks are determined based on recently completed work. Those who have grown up in the Gantt world may have a difficult time accepting any other way of organizing work.
Using Gantt charts to run a software development project could be analogous to using a riding mower to cultivate a flower garden. Nevertheless, Gantt charts continue to be used on software projects despite the introduction of better tools for managing projects iteratively. Yes, change certainly is difficult.
Exercise
In Chapter 15, “Change Exercise,” you can find an exercise that creates a fun, safe environment to openly discuss things that require changing. The facilitator should carefully read this chapter and the workshop instructions before diving into this exercise, more so than any of the other exercises in this book. Change can cause hot flashes and cold sweats, and it’s important for the facilitator to keep an observant eye out for signs of resistance and to be prepared to address that resistance when it surfaces.
Closing
Aversion to change is inherent in most people. Even a person who is a catalyst for change (a change agent) may resist when others attempt to impose changes of their own. This phenomenon makes it difficult for organizations and teams to adapt to better ways of working together on projects.
A step in the right direction is to accept that change is difficult for most people. This can help overcome frustration with those who resist change. The change exercise in Chapter 15 of this book offers a tool that you can use to expose those areas needing change so that they can be addressed head-on.