Scrum has become the most popular exponent of agile software development frameworks. Organizations-and those developing software, in particular-are drawn to Scrum for many reasons. They include its capacity to mitigate risk, facilitate frequent communication, reduce cycle time and cost, and deliver the right products to customers. From a managerial standpoint, Scrum's most appealing attribute is its ability to boost productivity through autonomous, hyper-performing teams.

Not only can the organization leverage Scrum to help teams self-organize and do more (and do it better), but that self-organization also frees up the Product Owner to focus on longer term strategy, macro-measurement as well as determining the ‘what' will be developed versus the ‘how' the work will be completed. In total, the Scrum framework's minimal structure is designed to facilitate frequent communication and ongoing process improvements, the byproduct of which is enhanced productivity.

The Scrum Framework
Scrum's unique framework is designed to be a lightweight management wrapper. That is, while none of the framework's constituent parts are redundant or expendable, there are relatively few of them, thereby making it an approach to management that complements existing processes. However, the framework's streamlined composition emphasizes the specific role each piece of the framework plays in facilitating productivity.

As such, each of Scrum's three primary roles-the ScrumMaster, the Product Owner, and the Team Member-play an essential role in enabling teams to perform at a higher level. To illustrate how Scrum facilitates productivity, in general, I'll examine its three roles to consider how they boost productivity on an individual basis. Of course, when all three roles work in tandem, the overall effect is much greater than the sum of its parts.

The ScrumMaster
Every framework or methodology has a set of rules and processes, but the Scrum framework includes an individual dedicated to making sure they are followed: the ScrumMaster. The work performed by this role is very easy to summarize: The ScrumMaster resolves impediments that obstruct the team from making progress; assists the Product Owner to make sure the backlog is prioritized; and works to make project status and team successes visible to all stakeholders.

However, the scenarios that might fall under any of the three listed responsibilities are virtually limitless. Factor in the ScrumMaster must execute without any formal authority and it becomes clear that this role requires a particular personality type. Typically, individuals must experience as much satisfaction from helping steer a team toward success as they would from personal heroics. That a ScrumMaster should lead a team through various "soft" skills-as opposed to the command-and-control approach of traditional project management-underscores the necessity of an individual who can motivate through accountability and shared commitment.

As time goes on and the Scrum transformation begins to take root at the organization, fleeting moments of leadership should arise from multiple sources, including all members of the Scrum team. An example follows: While working on a large scale government Scrum transformation (circa 2004), although the ScrumMaster Ann demonstrated an uncanny ability to show leadership in the midst of a difficult political landscape, individual team members (who'd gone through similar transformations) showcased their leadership abilities by holding brown bag lunches on engineering practices or advanced programming skills.

Given how central the pursuit of productivity is to Scrum, the ScrumMaster is not only working to remind all stakeholders to observe Scrum's rules, but actively focusing the team's attention on the ultimate goal: increased productivity and improved processes. One way teams can improve their processes is during the ‘forgotten' meeting, the sprint retrospective. A team is given an opportunity to evaluate itself to determine what's working and what's not so that adjustments can be made accordingly.

This time to reflect sometimes includes the Product Owner and, other times, does not. Usually, the ScrumMaster records what happens at these retrospective meetings. For more advanced teams, Diana Larsen and Esther Derby's book Agile Retrospectives: Making Good Teams Great discusses many different approaches to the retrospective meetings. They also conduct in-person workshops, which are highly recommended.

In examining how the ScrumMaster helps focus the team on constant improvement, I'll discuss how the role works with the team and the Product Owner to realize a heightened state of productivity.

The ScrumMaster and the Team
In relation to the development team, the ScrumMaster's work is simply described: enforce the rules of the framework, remove any obstacles that prevent the team from performing its work, while encouraging communication and team self-organization. Of course, that all amounts to a focus on facilitating productivity. Now, the impediments obstructing a team could be technical (a broken computer), personal (a disengaged team member), situational (the team room is uncomfortably hot), organizational (management doesn't recognize the ScrumMaster as a valued engineering role), or developer-centric (massive technical debt from using a legacy system).

But whatever the problem, the ScrumMaster should assist in resolving it. In the scenarios described above, that might entail a spur-of-the-moment shopping trip to replace faulty hardware; a candid and motivating talk with a rogue developer; or a call to office maintenance to address a stuffy, unventilated workspace. In the case of the last two examples, overcoming those impediments might entail more involved resolutions.

One anti-pattern to be concerned about in a Scrum transformation is a pejorative view of the ScrumMaster role from both Human Resources and Executives as administrative overhead. If this is the case, then it will require some effort on the ScrumMaster's part to demonstrate both the value of the Scrum framework and the ScrumMaster's role within it.

The value of this role would likely become apparent over time, as repeated successes with Scrum provide proof points for how both the framework and its roles generate value. Replacing a legacy system, on the other hand, would prove a substantial impediment simply due to various technical challenges (the code is complex and only understood by a few, for instance) and financial issues (redesigning or replacing such a system is typically very costly).

In short, when starting a Scrum transformation, the ScrumMaster owns all of these impediments - both big and small - so that the development team doesn't get bogged down. Without the distraction of resolving these peripheral goals, the team can remain fully focused on advancing development activities. It is important to note that, as your Scrum transformation matures into its second or third year, although the ScrumMaster should still know of all impediments (in order to facilitate communication throughout the team),

it isn't necessarily their job to be the point person to resolve these impediments. Being a point person or knowing of said impediments (both team and organizational) doesn't mean that the ScrumMaster is in charge of the task level management of resolving that impediment. This is a fairly nuanced point, but it underscores the important distinction between task-level management and product backlog-level management.

Although much of the ScrumMaster's value to a team hinges on his or her ability to react quickly to problems as they surface, there is also a more visionary component to the ScrumMaster's work with the team. Because the ScrumMaster works closely with the team on a daily basis, attending all meetings and remaining in sync with all development progress, this individual possesses a deep understanding of the team's dynamics.

As such, the ScrumMaster is uniquely positioned to help the team address internal dysfunction, especially during the retrospective meeting, which occurs at the end of every sprint and provides the team with a time to candidly assess its performance for the previous sprint. Not only is this an outlet for the team and ScrumMaster to make changes and evolve the framework, but it is also a repeated opportunity for the ScrumMaster to observe ineffective working patterns, which may be too close to the team for it to observe.

The ScrumMaster and the Product Owner
Unlike their work with the team, the ScrumMaster's duties to the Product Owner are more limited in scope. Rather than "putting fires out," the ScrumMaster's support work with the Product Owner tends to be more easily anticipated and performed on a regular, ongoing basis.

In essence, this work can be summarized as (a) enforcing the rules of the framework, (b) assisting the Product Owner with various preparatory activities as well as (c) removing barriers between the development and the Product Owner so that the Product Owner directly drives development. [i] These activities can include updating the Product Owner about the team's progress and successes, assisting in the preparation of the backlog for sprint planning (also known as backlog grooming), and radiating important status updates to all team members and stakeholders, but it can also be contentious.

Here's an all too familiar example. Some newly minted Product Owners, who are accustomed to chaotic work situations with rapidly changing requirements may feel the need to raid sprint work (after the sprint planning meeting and before the sprint review meeting) as a means to get the priority one request du jour into the team's committed backlog. In this sense, it is up to the ScrumMaster to explain to the Product Owner that this action is a non-starter and that the only way to do this is to cancel the sprint and re-plan. If similar occurrences continue to happen, it is recommended that ScrumMasters suggest shortening sprint intervals.

This may leave you wondering, "Is the Product Owner even part of the team?" The "official" answer to this can be a cause for great debate on forums like this one, as it calls the meaning of the word ‘team' into question. Often times, aggressive Product Owners are asked to sit out the daily standup and the retrospective meeting (because of their "boss" status). As such, does that mean, if they don't attend all the meetings, they aren't part of the team? You can see how this can get hairy. 

Radiating Information
While touched upon in the previous section, the ScrumMaster's responsibility to ensure all stakeholders are apprised of project status (frequently referred to as "radiating" information) is critical to both increased productivity and success with Scrum. In fact, it could be argued the ScrumMaster is such an integral part of the framework because he or she can function as a facilitator or information radiator.

Through his or her work informing various stakeholders (both on and off the team) about the project or ensuring that Scrum's artifacts perform that communication for them, the ScrumMaster can unite disparate parties through streamlined communication. In addition to verbally communicating with stakeholders, the ScrumMaster might provide updates through visual representations of the backlog, taskboard, and important metrics such as the product burndown chart. In fact, some team rooms literally cover their walls with these artifacts, making information accessible to the whole team at any moment.

Others who utilize automated tools, like ScrumWorks, utilize projectors to radiate information during the different Scrum meetings. When every member of the team is empowered with current information, it eliminates the time-consuming need for developers to keep track of metrics or orient themselves to a project's current state. In fact, once they're up-to-speed, developers have nowhere to go but forward.

Of course, it should be mentioned that the ScrumMaster's efforts to ensure the team remains connected is not a substitute, but a complement to the team members' communication among themselves.

Conclusion
While bettering processes and, consequently, boosting productivity are primary objectives of Scrum, the ScrumMaster role nonetheless plays an especially important role in facilitating those improvements. And through the framework's intentional construction, the ScrumMaster facilitates communication and improved processes via every point of contact with the team and the Product Owner. The ScrumMaster actively works to understand and then remove the impediments that prevent a team from performing to its potential, while working closely with the Product Owner to remove barriers between the development and the Product Owner so that the Product Owner can focus on directly driving ‘what' is to be developed.

At the same time, the ScrumMaster attempts to keep all stakeholders informed through various information radiators-not the least of which is the ScrumMaster role itself. But because Scrum is a framework, a system in which all the constituent parts depend on one another for success, the Product Owner and the team play important roles in facilitating productivity. In the second installment of this series, I'll turn the discussion to the Product Owner role and how it also enables teams to push productivity to the next level.

 About the Author

 In August 2000, Laszlo Szalvay founded Danube Technologies, Inc. with his brother Victor in Seattle, Wash. to provide software and training exclusively focused on the Scrum method of agile software development. The company's ScrumWorks® Pro and ScrumWorks Basic products are licensed to more than 105,000 software professionals worldwide, making it the most widely used software in the industry for managing Scrum projects. ScrumWorks Pro recently received a Jolt Productivity Award at the 19^th annual Jolt Product Excellence Awards. Danube complements its software offering with a comprehensive schedule of ScrumCORE^TM training courses, which are taught globally by Danube's four Certified Scrum Trainers.

[i] Source: Agile Project Management with Scrum, Ken Schwaber