The ScrumMaster fills the position normally occupied by the project manager. I’ve taken the liberty of redefining this role. While the traditional project manager is responsible for defining and managing the work, the ScrumMaster is responsible for managing the Scrum process. To put it simply, ScrumMasters make Scrum work.
The Scrum process defines practices, meetings, artifacts, and terminology. The ScrumMaster is responsible for knowing these and knowing how to apply them correctly. Scrum can be applied incorrectly, as we will see. But because the ScrumMaster has a clear understanding of how Scrum works and has experience applying Scrum, the ScrumMaster knows how to guide a Scrum project through the shoals of complexity.
Like sheep in an open field, individuals in a project tend to stray. The ScrumMaster’s job is to keep the flock together. In fact, I often compare a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.
MetaEco develops and sells code generation software. It owns a library of object patterns that describe various business enterprises. Customers customize the objects in their business’s pattern to describe their unique business model and to generate applications for their business. MetaEco, a three-year-old company, had enjoyed a steady revenue stream from its first customer. However, this customer had just been acquired by a competitor and was unlikely to renew its contract.
MetaEco was in a tight spot: it had been spending more money than it took in, and its product was complex and expensive. MetaEco’s primary costs were new product development and development of customized solutions based on the core product. Every prospect required a customization of the product to its needs before moving forward. Making this initial investment was costly for MetaEco, and not enough prospects were becoming paying customers to make up for that cost.
Tom, the MetaEco CTO, asked me to train the development staff in Scrum. Tom decided that he needed to be ScrumMaster because of his technical skills and his determination to keep MetaEco on track. Tom and I formed teams charged with enhancing the current product and building a prototype for a very important prospect, a news organization. The prospective customer had said that it would consider funding a long-term partnership if the prototype was to its liking.
Tom did a great job of reinforcing the Scrum teachings of cross-functional teams, cajoling and educating each team when it reverted to design sessions that weren’t in line with that Sprint’s goal. Tom also worked hard to protect the teams from outside interference. Tom’s biggest challenge in this area turned out to be his mentor, Paul, who was MetaEco’s new CEO. Paul served as the company’s chief salesman, and was usually on the road drumming up business. The two men were positioned to serve as counterpoints to one another. Tom brought stability and focus to the teams so that they could rapidly build demonstrable products. Paul worked to find money to keep the company afloat. Often, Paul would have to commit to a proof of concept before the prospects were willing to take the next step. Tom discovered Paul redirecting the team members from their Sprint work more than once. Paul would ask a key developer to tweak the product and buff it up for presentation to a prospect. Although each customization could be completed in only three or four days, these interruptions shattered a team’s focus and slashed away at its productivity.
Paul argued that all he needed were a couple more prospects becoming customers to generate much-needed revenues. To make the prospects customers, he required customized prototypes. Tom argued that Paul, as Product Owner, had already prioritized work the team had to complete to finalize contracts with the important prospective customer. Staffing had been reduced so that the new organization’s project and other customizations couldn’t be completed simultaneously. Tom reminded Paul that his opportunity to direct the team’s work was the Sprint planning meeting. If he wanted another prototype built in parallel with the news organization’s project, he could choose to do so at that time and visibly accept the consequences of slowing progress on the news organization’s project. Or he could choose to prioritize another prospect above that one.
Paul was in a bind. He didn’t want to miss out on any opportunities, but he also didn’t want to screw up the news organization’s project. Tom was sympathetic, but he also understood that if he didn’t stand firm and stick to the rules of Scrum, nothing would get done. Finally Paul said, “All right! I don’t like the Scrum rules, but I understand them. Now that I know the rules, I’ll follow them. But you’d better be willing to turn on a dime at the Sprint planning meeting!”
Let’s see how Tom as ScrumMaster added value to MetaEco. The sales and marketing departments are often at odds with the development organization. Sales and marketing want quick responses to every opportunity that comes knocking. Developers need to focus on producing the product. The chaos in a company is often caused by an inability to resolve these conflicting needs.
Scrum strikes a balance between the two through the use of 30-day Sprints. The development organization will do whatever is needed every Sprint, addressing whatever is deemed the top priority for that Sprint. However, everyone else must leave the developers alone to work.
As ScrumMaster, Tom was able to cite two rules to help his team and ultimately MetaEco. First, he highlighted the Scrum rule banning interference during the Sprint. Then he reminded Paul of the Scrum rule that allows a team to be redirected to higher priority work at the Sprint planning meeting. The first rule protected his team and its work, and the second rule reassured Paul that the process was responsive to his and MetaEco’s larger needs. Striking a balance between responsiveness and focus, MetaEco was able to close a deal with the news organization. If Tom hadn’t exercised his new responsibility as ScrumMaster and hadn’t protected the team’s focus for the Sprint, things might have ended differently. Because Tom correctly applied Scrum rules, he was able to balance the needs of both the marketing and the development departments.