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.
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