The Untrained ScrumMaster at Trey Research

A consultant is sometimes defined as someone who gives advice more than 100 miles from where he or she lives. I know why this is the case. My neighbors know my lawn has patches and crabgrass in it, just as their lawns do. The police in my town know I sometimes speed. The librarians know I sometimes have overdue books, and they know I have a taste for daring mystery stories. In short, the other residents of my town know I am a regular person with both strengths and shortcomings—I’m not at every moment an expert on all questions.

People often hire consultants because they want to get a different perspective on their situations. This new perspective is often perceived as somehow better than the native view of things. This would be enough of a reason for clients to think twice before hiring a local consultant. So you can imagine how excited I was when a company in the town where my family has lived for the last 23 years called. The CIO had implemented Scrum and wanted me to check it out.

The company in question was Trey Research, a start-up company that acquires tissue cultures from healthcare organizations and resells them to pharmaceutical companies. Trey Research adds value to the cultures by inventorying and identifying the demographics, illness, and stage of illness represented by each sample. Overloaded with new systems to build and implement, the Trey Research CIO had implemented Scrum. He wanted me to evaluate how Scrum was working at his company and suggest how his implementation might be improved.

What Was Wrong

At the beginning of my visit, I met with the CIO’s management team and provided them with an overview of Scrum. We then discussed the various projects under way at Trey Research and how they were using Scrum. Each team had sprinted several times, and everyone was pleased with the changes that had been effected and the progress that had been made.

The ScrumMaster who had been using Scrum the most invited me to attend “his Daily Scrum.” The moment I heard this, an alarm bell went off in my head. Why was it “his Daily Scrum” and not “the team’s Daily Scrum”? I decided to hold my tongue and wait to find out. He led me to a large room in the basement of the old mansion that was Trey Research headquarters. Nine developers were working at their workstations—five clustered in the center of the room and a pair at each end of the room. From a structural point of view, this was good news: an open work area like this enables the high-bandwidth communication essential for successful teamwork.

At this meeting, the ScrumMaster kicked things off by pulling out a list. Reading from the list, he proceeded to go around the room, asking each person present whether he or she had completed the tasks he had written by that person’s name. He asked questions like, “Mary, did you finish designing the screen I gave you yesterday? Are you ready to start on the dialog boxes in it today?” Once he had exhausted his list and spoken to everyone in the room, he asked whether the team needed any help from him. The team members were all silent.

I wasn’t sure how to tell him what I thought of his methods. On one hand, work in my hometown was certainly convenient. But how could he have so completely misunderstood all that I had written about Scrum? How had I failed to convey the spirit of Scrum? He turned to me and somewhat proudly asked what I thought. I paused and then complimented him on the open arrangement of the team room and the general spirit of the team. I then asked him how he knew what the team was working on. He started to say he knew because they were working on what he had told them to work on, but before the entire sentence got out, a look of shock passed over his face. In just a moment of reflection, he had identified the key element of Scrum that he had forgotten to implement.

Lessons Learned

The project manager had read the book on Scrum and learned the mechanics of the Daily Scrum. He had read that team members are supposed to answer three questions at each Daily Scrum:

What have I done since the last Daily Scrum?
What am I going to do between now and the next Daily Scrum?
What is preventing me from doing my work?

However, he was a longtime practitioner of traditional project management techniques. He’d spent years planning tasks and ensuring that teams completed them. Consequently, he had interpreted what he’d read as

He would check on whether the team members had done what he told them to do since the last Daily Scrum.
He would tell each member what they should do between now and the next Daily Scrum.
He would check to see whether he could do anything to help the team accomplish its goals.

To save time, he had shortened the last question into a general inquiry.

The shift from project manager to ScrumMaster had eluded him. He believed that Scrum was merely a series of practices and techniques for implementing iterative, incremental development. He missed the subtle but critical shift from controlling to facilitating, from bossing to coaching. Just as he missed out on these changes, he also missed out on the importance of a self-organizing team. He and the team had committed to a Sprint goal, but the team never self- organized or truly committed to the Scrum goal. The productivity that emerges when a team figures out the best way to accomplish its goals hadn’t been realized. Neither did team members have the deep personal commitment that emerges when people puzzle their way through their work on their own. The team’s ability to tackle its problems and solve them is the heart of Scrum and the basis of the Scrum team’s extraordinary productivity. Once I pointed this out to the project manager, he immediately saw the error of his ways. “Oh, of course!” he exclaimed. Some people are so embedded in their familiar ways that they have trouble seeing what they have to change, no matter how many articles and books they read and agree with.