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