Chapter 2. Getting People on Board

M. Scott Peck wrote, “The truth is that our finest moments are most likely to occur when we are feeling deeply uncomfortable, unhappy, or unfulfilled. For it is only in such moments, propelled by our discomfort, that we are likely to step out of our ruts and start searching for different ways or truer answers.”

As much as teams might complain, people are often all-too-comfortable with their ruts and their unhappiness. After all, as bad as their current situation may be, at least they know the terrain and rules. Scrum offers a way out, but it brings with it a new, unknown, unfamiliar way of working. When faced with the choice between the known and the unknown, people are often hesitant or even downright reluctant to change. It is not until immense pressure is applied, until their current rut itself becomes too painful, that they escape to a better future.

Getting people to take a chance on a Scrum project requires more than just a “Scrum is Good” campaign. It takes a healthy dose of persuasion, a steady increase in pressure, and a whole lot of patience.

Ryan and his family had a two-week vacation planned at their cabin in Montana. Ryan decided that the two weeks would be best spent finding some new tools for his project manager’s tool belt. He packed a suitcase full of books on project management. As he was about to zip up the bag, he saw a book that his boss, Steve, had given him several months ago, Agile Project Management with Scrum by Ken Schwaber. “Might as well throw this in too,” Ryan thought and tossed it in the bag with the rest.

Ryan burned through the traditional project management books. He picked up a few tips, mainly on communication plans and risk management, but found nothing that would have prevented the architectural issue on his last project or any of the other problems his teams had been having. Reluctantly, he picked up Schwaber’s book, grabbed a drink, and went out to the deck to read it.

His initial skepticism soon gave way to excitement. He could visualize the patterns in his work that directly related to the ones in the book, patterns around complexity and value-driven work. He also recognized truths that he had ignored on his past teams, such as actually building a team of people instead of using a collection of resources. The more Ryan read, the more interested he became. He closed the book later that afternoon with a great desire to learn more. He immediately went inside and ordered two more books on agile development, with next day shipping.

Ryan was not a workaholic, but the reading he had done sparked a passion. While his wife read the latest summer novels and his kids played soccer in the yard, he spent his time poring over books on lean, agile, XP, Kanban, and Scrum. Upon returning from his vacation, Ryan ran into Steve—his old friend and the division manager who had given him the Scrum book.

“Steve, I’ve got great news!” Ryan exclaimed. “While I was in Montana, I read all these books, and I think I have a solution to not only the problems I’ve been having with my projects but to all the project issues we have been having in our division!”

“That’s a lot to get out of a few books, Ryan,” said Steve, smiling. “But come on in and tell me about it.”

Ryan and Steve spent the next three hours talking about everything Ryan had read. Then Ryan asked the question that had been in his mind the whole way back from Montana:

“You know the Michaelson project we have coming up?”

“Yes . . . ,” said Steve, with a hint of curiosity in his voice.

“Would you let me try this Scrum stuff on that project?” Ryan asked. “Remember that objective you laid down for the group to find a way to increase overall operational efficiency by 50 percent without increasing the overall group size? I think this is one way to help achieve that goal. And I think it can be done within this year like you had hoped.”

Steve sat quietly for a minute, thinking, and then replied, “Ryan, I think you are right. The Michaelson project will be a good trial for this, and I agree that Scrum could help increase overall efficiency without growing the overall size of the group.”

“Great!” exclaimed Ryan. “My hunch was correct! Now can I—”

“Wait,” Steve interrupted. “Now, don’t get too excited. You don’t know this, but when I worked at Megaco, I actually ran several Scrum projects with great success. I have managed large organizations and teams that have been able to improve by more than 50 percent, so I know this can work. Your biggest challenge will be getting started, which is more work than you realize, especially getting people on board with Scrum.”

“So I can have a team to try this out?” asked Ryan.

“No,” said Steve. “You can have the project, but you’ll need to build your own team. I want you to find other team members who are willing to work this way before I give my final approval. I will support you any way you need me to, and you have free reign to do what you see fit, within reason, to get the project off the ground and the people on board. I will be your sponsor and will let the other senior managers know what we are doing. Remember, not everyone will have the enthusiasm you have for this, so tread lightly.”

“I’ll work on recruiting my team. I do have one last question for you,” said Ryan. “If you knew about Scrum, why haven’t you already introduced it or Extreme Programming to the group?”

Steve paused. “When I was at Megaco, I was very much like you. Enthusiastic, outgoing, very in-your-face with this agile stuff. I pushed it from the top down on my people there, and they reacted by rebelling. I eventually won most of them over, but not without a lot of hardship and attrition. That experience made me realize that this needs to be a bottom-up approach. I put the goal out there in the beginning of the year hoping someone would grab onto it and suggest an agile solution like Scrum or XP, or both.”

Both Ryan and Steve sat there, letting Steve’s comment sink in.

“That makes sense,” said Ryan. “I’ll keep you posted on my progress.”

“Remember, I’m here to help,” said Steve. “As your sponsor for this effort, it’s my job to help clear bigger issues and provide guidance. Don’t be afraid to come to me for advice.”

Ryan left feeling excited but a little worried about the idea of getting people on board with his ideas. He spent a few days considering his approach.

The first person Ryan met with was Daniel, a developer in his mid-forties who had been at the company for more than 12 years. Daniel was methodical in his approach and very good at his job, but lately he had become cynical and vocally critical of the way the group was run.

“Daniel, I’d like to talk to you about a project I am starting. It’s the Michaelson project and—” Ryan began.

“Why are you talking to me about this?” Daniel interrupted. “You should talk to my manager. He handles my time and will tell me what to work on next.”

Ryan felt a little perturbed that he was cut off midsentence, but he forged on.

“I can do that, Daniel. I thought I would talk to you first to see if you had an interest before talking to Alan about this. Steve said it would be a good idea for me to talk to people directly to build the team and you—”

Ryan was cut off again.

“Steve? Our big boss Steve?” asked Daniel.

“Yes,” said Ryan. “You see, this Michaelson project, it’s a real interesting project. My idea is to use this project management framework called Scrum to run it. We’ll use Extreme Programming practices like test-driven development and pair programming,” Ryan said with exuberance.

“Pair what? Extreme Scrum? I don’t get it,” stated Daniel bluntly.

“Pair programming, you know, where two people work on the same code at once. And Scrum is a project management framework that allows us to—” said Ryan, before being cut off yet again.

“Ryan, listen. I hear you’re a nice guy and all, but this isn’t for me. I have no interest in this Scrum stuff, and I most certainly will not try pair programming or test whatever. Sorry, but no,” said Daniel.

“But, Daniel, if you’d just listen, you’d be amazed at how—” Ryan started.

“Look, Ryan, I don’t know how to be clearer. The answer is no. I’m not interested!” exclaimed Daniel.

Ryan left, discouraged. Still, he had another chance at the one o’clock meeting he had scheduled with Meghan.

At one o’clock, Ryan went to Meghan’s office, but Meghan wasn’t there. Where is she? Ryan wondered. He sat and waited in her office. She finally came in 15 minutes later and seemed surprised to see him sitting there.

Ryan greeted her, “Hi Meghan, I was just about to give up on you. I’m here because I wanted to talk to you about this new project I’m doing. We’re going to use Scrum and—”

Meghan cut him off.

“Ryan, I need to come clean with you. Daniel has already warned me about what you want to talk about. I can already tell you I’m not interested. Honestly, I was kind of hoping you wouldn’t be here if I showed up late. I hate saying no, but I’m not saying yes.”

Ryan hung his head and sighed. Meghan relented.

“Okay. Fifteen minutes.”

Ryan got right to the point. He enthusiastically described what the project was about, the revelation he had over his vacation, and how Steve said he could build a team to do this work and try something new. He was very clear to emphasize that he had Steve’s full support. It was approaching half past one.

“That’s some good stuff, Ryan. I can see how it might work on a web project or something small, but the Michaelson project is huge! It requires a lot of architecture and design, which we need to do in the beginning to plan out the work. I don’t think what you are proposing will work. And, I’m with Daniel, I don’t want to pair program or do testing,” said Meghan.

“It’s not exactly testing. It’s test-driven development—” Ryan began. Meghan quickly cut him off.

“Let me put it another way. I’m not doing this. Ever. It’s not for me. It’s not for our division. And if you want to keep your job, it shouldn’t be for you either. There’s no win for any of us in trying something so extreme,” Meghan explained. “I’m sorry. I’ve got to go to my next meeting,” she finished, getting up and leaving Ryan sitting in her office.

Ryan sat there for 15 minutes with his head in his hands, wondering why Meghan and Daniel were so resistant. What was he doing wrong?

By Friday, he had two more meetings with two different people. No luck. He went to see Steve later that afternoon to discuss his lack of progress.

“Ryan,” Steve began, “I had a quick talk with Meghan and Daniel yesterday after you left. I’ve got some advice for you, as a friend. You can’t be in-your-face with people. Let them come around the way you did, slowly. They need to read about it. Understand it. Have time to make up their minds. Give them books or some of those papers you read over your vacation. When people try new things, we have to gradually bring them around and give them time to get comfortable.”

“You’re right, you’re right,” said Ryan. “I’ve gone about this the wrong way. I’m going to take your advice and take a step back. Gradually. Logically. Got it.”

Ryan spent the next two weeks slipping Meghan and Daniel copies of chapters from his favorite books and research papers. He highlighted key parts and made notes on the copies as to why he liked them and how he thought those sections could apply to the team he was trying to build.

One Monday morning, Meghan dropped by his office.

“Okay, Ryan,” she began. “I’m starting to see your point. I’m willing to help with one condition. I’ve got kids and I cannot afford to lose my job, not in this economy. I’m really going out on a ledge here, and I need to be sure that Steve will see this through,” said Meghan.

Ryan assured her that he would have Steve give her a call. Later that day, he once again dropped by Steve’s office. He updated him on his progress so far, adding that Meghan was willing to join the team but needed some reassurances from Steve before committing.

“I’ll talk to her,” said Steve. “So that’s one. How are you going to convince everyone else?”

“Well, I did some research, and it turns out we have two experts in XP here at the company, Jim and Ward. I asked them if they would be willing to have a discussion with our division about what this agile stuff is all about,” said a nervous Ryan.

“Good idea,” said Steve. “What do you need me to do?”

Thrilled that Steve liked the idea, Ryan laid out his plan for the talk. “At the discussion, I’d like you to be the first one to talk. Reiterate your goals for the division and then about what I’m trying to do. Sound good?”

“Oh, absolutely!” said Steve, smiling.

Over the course of the next week, Ryan put up flyers around the building, set up the logistics, and gave Jim and Ward some background on the group. Meghan helped get the engineering people to commit and suggested to Ryan that they order lunch to ensure a crowd. “Free food is a strong incentive,” she said.

The day of the meeting arrived at last. Ryan looked out at the crowd and smiled. More than 90 percent of the division had shown up, much more than he had expected. Steve spoke first, explaining the goals he was trying to meet and Ryan’s effort to find better ways to build software systems. Then it was Ward and Jim’s turn.

Most of the attendees knew who Jim and Ward were and what they had accomplished. Ward and Jim spent a couple of hours describing the principles, values, and practices of XP. The audience listened attentively and had plenty of questions. Even after the discussion had officially ended, nearly 50 people stayed to talk more; it was three o’clock before the last person left. Through it all, Ward and Jim happily answered everyone’s questions and provided gentle reassurance that Scrum and XP were just another way to approach software development—modern engineering practices, if you will. The last person to leave? Daniel. He approached Steve and Ryan.

“Well, I’ve got to say, these guys were pretty persuasive. I’m still not completely sold, but if Steve thinks this is important, I’m willing to do it on one condition,” said Daniel.

“What’s that, Daniel?” asked Steve.

“That if things go wrong, I won’t take the fall,” said Daniel, looking Steve in the eye.

“First of all, it’s not if things go wrong, Daniel, it’s when. My first clue that Scrum and XP are working will be when you fail—how could I blame the team for doing the right thing?” said Steve.

“I’m not following. What do you mean, when we fail?” asked Daniel.

“I’m talking about one of the best things agile processes give teams—the ability to fail early. I know the team will mess up; what’s important is when they mess up. If the team waits until the end of the project to fail, as has happened on our other projects, we’re going to have all the same problems we’ve had before. On the other hand, if this team fails in the first three months and learns from it, the project has a much better chance of success. Ask Ryan. He wishes he had failed early on his last project because if he had known about his architectural issues sooner, he could have quickly fixed the problems and avoided all the end-of-project pain. Failing isn’t the problem; failing late is.

“As far as taking the fall goes, I know that there will be stumbling blocks, and I’m willing to give you some leeway to figure out how to work in a new way, but I expect everyone on the team to be fully committed. You succeed—and fail—as a team,” cautioned Steve.

“So it’s all of us or none of us, and you want us to fail, as long as we do it early. Wow. I actually think I’m going to say yes,” said Daniel. “I just need a little more time to figure it all out in my head—really, it scares the bejeezus out of me.”

“Me too,” said Ryan.

This caught Daniel off guard.

“But Ryan, you’re the guy pushing this crap. What do you mean it scares you?” asked Daniel.

“Are you kidding? I think it’s the right thing to do, but that doesn’t mean I’m not scared. I have a vision of how this can work, of how we can help achieve the goal laid out by Steve. But once we make this leap, like Steve says, we are in this together, as a team—succeed or fail, it’s all on us,” said Ryan.

“Well said, Ryan,” said Steve.

“Let me noodle on this,” said Daniel as he turned to walk back to his office.

“Not a bad showing today, Ryan. How do you feel?” asked Steve.

“This is so hard,” said Ryan. “Getting these people to change their minds is excruciatingly tedious. I wanted to be up and running by now, but here we are, nearly four weeks into it, and I still don’t have a team. It’s pretty frustrating,” said Ryan.

“Hang in there. Today was a great meeting for our division. People wanted to hear about this, and I think you made a lot of progress. Still, don’t be surprised if there are people who won’t change their minds, no matter what you do or say or give them to read,” said Steve.

Over the next three months, Ryan worked with Meghan and Daniel, calming their fears and winning them over. They, in turn, won over a few more people to fill out the team. They were all surprised at the resistance from middle management, who were unsure how they would do performance reviews and monitor who was working on what if their people were on a cross-functional team. Steve was a big help with the managers, reassuring them that he had done this before and that he would help them work through any problems. Finally, after four months, the team was ready to start the project.

“Phew!” said Ryan to Steve over beers on a Friday night. “I finally did it.”

“Now comes the hard part,” said Steve. “You have to figure it all out, experiment, and learn.”

“Oh, that’ll be easy after these past four months,” said Ryan.

“Sure it will, Ryan,” said Steve with a smile. “Sure it will.”

Convincing others proved much more difficult for Ryan. Ryan’s peers met his newfound enthusiasm with fear, anger, and suspicion. One problem was that Ryan’s last project did not inspire trust with his colleagues. Another obstacle was Ryan’s delivery style. By almost attacking people with his zeal for Scrum, Ryan was making people feel defensive before they’d even had a chance to hear what he had to say.

Steve, Ryan’s sponsor of this change effort, helped him realize it was his emotional method of persuasion that was alienating people. He advised Ryan to adopt a much slower, fact-based approach. He explained that while Ryan had the luxury of reading and thinking about Scrum for weeks before coming to a decision, he was expecting others to jump on the bandwagon on no more than his say-so.

In response, Ryan stopped his active campaign and took a gentler but more time-consuming approach. He handed out papers and chapters to give people the facts. He involved Steve as a vocal sponsor to help soothe people’s fears and also to help them understand the need to make changes. Finally, he reached out within the company network to find reputable people to advocate an agile approach, so that it wasn’t just his advice that people were taking. Even after all that, it was still several months before he had a full team ready to begin a new project.

Bringing people on board with Scrum, especially in a bottom-up manner, often takes time, persuasion, and patience.

Steve provided a clear vision: his desire to increase operational efficiency by 50 percent. Ryan had his own sense of urgency: He wanted to have more successful projects and feel better about his own job performance. Neither was sure how to accomplish his goals, but both were open to the possibilities inherent in a change to Scrum.

In a 1995 article in the Harvard Business Review, John Kotter [KOTTER] outlined an eight-step model for addressing change. A summary of that model is shown in the following list:

1. Establish a sense of urgency.

2. Form a powerful guiding coalition.

3. Create a vision.

4. Communicate the vision.

5. Empower others to act on the vision.

6. Plan for and create short-term wins.

7. Consolidate improvements and produce still more change.

8. Institutionalize new approaches.

Both Ryan and Steve were following (albeit unknowingly) some of Kotter’s approaches. What follows are some concrete steps you can take to help ease people’s fears of what life will be like with Scrum.

To convince people to try something new, you need to give them a reason to make the change. Issuing a challenge or establishing a sense of urgency helps people understand why a change is necessary. Keep in mind, however, that the challenge must be reachable and the sense of urgency real. People will rise to a real challenge but will shrug off one that they perceive as impossible or false.

A good sponsor is someone in the organization who believes in the change and has the authority to work with the leadership team and the middle managers to communicate a vision, explain why it is important, and establish a timeline for effecting the change. The sponsor should also be able to help explain to managers what their roles will be in the new process and solicit their help in making it happen. When necessary, a sponsor should also intervene with potential saboteurs to alleviate their fears and concerns.

Not everyone learns by reading, though, so also consider social learning mechanisms. Create a book club, have brown bag lunch sessions where people in the group talk about a topic passionate to them, participate in webcasts and local user groups, and, of course, if other teams you know of are doing Scrum or XP, ask if you can watch their reviews or planning meetings.

Next, use your network. There are often people, both inside and outside your current company, who are very familiar with Scrum. Reach out to those in your local area and become genuinely interested in them. Invite them to present to your group about their experiences, how they got started, and techniques for success. Even if there are no experts in your local area, it’s still helpful to bring in outsiders to share their stories. After all, people will often listen to someone that they don’t know and trust their words, even while disregarding people they do know, who are saying the same thing.

Even after people were convinced that Scrum might be a good idea, they were still hesitant to commit. Meghan gave a bunch of excuses, but her real fear was that she would fail and lose her job. She had a good reputation and didn’t want to lose it. The decision for Daniel also came down to whether or not he’d be successful. As the sponsor, make sure you clear the way for team members to address any issues that surface on the team or in the project. Reassure them that they can do what they need to do to resolve their own issues with impunity.

If, even with strong backing, people are reluctant to commit, consider offering them a trial run. In a trial run, the team members would have a designated period of time (perhaps three months) in which they would agree to put forth their best effort. At the end of the trial, they could either continue with Scrum or walk away clean. Running a trial helps to remove the fear of the unknown, creating a comfort zone where people can try new things without repercussions.

A trial run can also be a way to prove to the team, the skeptics, and the rest of the organization that the new methodology doesn’t just work in theory, but it works in practice, in this company, and on a specific type of project. It can also provide insights into things that don’t work initially and how these challenges can be overcome. The data from a trial run can be used to help build a coalition of supporters. Over time, fear will be replaced with confidence.

Short-term wins also help build the trust between the team and the stakeholders. Trust is fragile in the beginning. Showing working software, even small bits of it, will help increase the confidence of the team members and the stakeholders.

As the project progresses, new practices will become ingrained habits, making the work itself easier. At the same time, improvements will get harder and smaller. New champions of Scrum will emerge as people find the way they are working now to be a significant improvement.

As the consolidated improvements become commonplace, team members will begin to wonder what it was like to work in a non-agile environment where they only shipped once a year. When this happens, ask these champions to spawn off and create new teams, further institutionalizing the framework across the organization.

Find out what other people’s triggers are. Listen when others explain that they don’t understand, are afraid, or are reluctant to change. Ask questions designed to elicit answers that will allow you to uncover and address underlying concerns. Try not to let what you perceive as a lack of progress frustrate you. Things of great value take a fair amount of time.

Remember that though the current rut may be painful, most people are unwilling to move unless they truly believe there is a better path. Your job is to clearly explain the alternative you are proposing and to wait patiently while people make up their minds. In the end, the only person you can control is yourself. Throughout the challenging process of getting people on board, keep your head up. You may hear no more often than yes. Stay focused. Stay positive. Stay strong. This is challenging stuff.