The Untrained ScrumMaster at Litware

Litware is a medium- size vendor of planning software. A project management office consisting of one manager, John Chen, and three project managers planned all of the company ‚ s releases. After each release was planned, the work was broken down into tasks and organized on PERT charts . These tasks were then divided among the various analysts, designers, programmers, testers, and documenters. The approach was very ‚“waterfall ‚½ and very defined. As the complexity of the releases increased and the customer base grew, the release planning phase grew and grew until it was simply unacceptable. The results of each release planning phase were also unsatisfactory: the plans were difficult to adapt to the complexities that the team encountered and to the changes that sales and customers requested .

The company ‚ s frustrated managers asked John to work with me to switch the release management over to Scrum. After assessing the situation, John and I set a Scrum start date several weeks out. At this point, we would convert the plans to Product Backlog, provide Scrum training, and then conduct several Sprint planning meetings.

What Was Wrong

During those several weeks, I held a Certified ScrumMaster class and invited John to attend . This was his chance to learn Scrum before he implemented it at Litware. The class prepares people who will be ScrumMasters for projects. As usual, the class was well attended. Unfortunately, there was one conspicuous no-show: John. I kept checking during the day, but he was definitely not there. Later that day, I e-mailed John to find out what had happened . John responded that other priorities at work had precluded his attendance but that we would nonetheless start the Scrum implementation as we ‚ d planned.

I showed up on the appointed day, and we spent the morning laying out the Product Backlog for two teams. In the afternoon, the Litware managers asked me to give an overview of Scrum to the entire development organization. The managers wanted everyone to understand Scrum and what was planned for the two teams . I introduced Scrum and entertained many questions. Everyone wanted to know where Scrum had been used before, how it worked, and what everyone ‚ s new roles would be. They were particularly intrigued by the concept of self-organization because they weren ‚ t big fans of task-driven work assigned to them by a project manager. I spent quite a bit of time discussing the shift from project manager to ScrumMaster. I compared the ScrumMaster to a sheepdog who would do anything to protect its flock , or team. We discussed how the team ‚ s welfare was the ScrumMaster ‚ s highest responsibility and how the ScrumMaster would do anything in his or her power to help the team be productive. At the end of the training session, John and I confirmed the start time with the teams that we were beginning to work with the next day.

I was setting up for the Sprint planning meeting the next morning when Elsa Leavitt, a member of John ‚ s staff, arrived to let me know that John had called her and said he would be at an offsite meeting instead of at the Sprint planning meeting. He had sent Elsa along in his stead. John hadn ‚ t gotten it: a sheepdog never gets distracted from the flock. John didn ‚ t understand that the team would be relying on him. Worse, he had sent a message that Scrum and the team were unimportant to him. He had indicated that he valued offsite meetings more than building software ‚ even though it was the software that was critical to the success of Litware.

I filled in the vice president of development on the situation. He understood the significance of John ‚ s absence. He immediately promoted Elsa and appointed her to be the team ‚ s ScrumMaster. When the team members arrived for the Sprint planning session, they found that Elsa was their ScrumMaster. She took care of them just as a good sheepdog would.

Lessons Learned

John didn ‚ t understand that ScrumMasters have to make a personal commitment to their teams. A ScrumMaster would no more delegate his responsibilities than a sheepdog would lie down for a nap while herding the flock. The team needs to sense that someone is deeply invested in its work and will protect and help it no matter what. The ScrumMaster ‚ s attitude should reflect the importance of the project; instead, John ‚ s attitude told the team that things at Litware were still business as usual.

I believe that John didn ‚ t want to understand the role of ScrumMaster. The behavior of the ScrumMaster is dramatically different from that of people staffing a formal project management office that assigns work and controls its completion. The shift from having authority to being a facilitator was too much for John. Not only is the ScrumMaster role one without authority, but it also potentially represented a career change that John didn ‚ t want to make. The ScrumMaster is a leader, not a manager. The ScrumMaster earns the team ‚ s respect because he or she fulfills the duties of the role and not simply because he or she was assigned the role in the first place.

The shift from delegating to being personally responsible is difficult for some people to accept. The ‚“hands-on ‚½ aspect of Scrum scares some people. John deselected himself from Scrum by failing to show up for the job. The vice president of development made the right move by reassigning the role of ScrumMaster to someone who recognized its importance.