Looking through some old notes from China, I noticed there were a number questions about the roles in Scrum, the importance of each role and how each role balances the other.  As a review, here are the three “offical” roles in Scrum and an additional role I consider important for the success of your product as well – stakeholders.

1. ScrumMaster: their role is to ensure the integrity of the process, that the preconditions for the framework are met, all the roles are filled and the players are following the Laws\Rules (I like to use the terms Laws since in rugby the rules of the game are called Laws – CEN).  They also encourage the Team to self-organize, remove obstacles, teach others about the Scrum and be on the lookout for people trying to minimize the feedback the framework is providing.
2. Product Owner: the person who defines and orders the list of features (called the Product Backlog) the Team is going to build for the organization.  They are given the authority to make tradeoffs about scope and date within the boundaries of the governance model of their organization.  Often times, Product Owners collaborate with the ScrumMaster to get the most value from the process.  Product Owners can delegate some of their work, but never their responsibility.
3. Team: the cross-functional group of individuals given the responsibility and authority to turn the Product Backlog into working software.  The Team is urged and guided by their ScrumMaster to strive for continuous improvement and technical excellence.  They work with the Product Owner to determine the best sequence of features for the business.  When an obstacle is identified, the Team always tries to resolve it themselves before calling in their ScrumMaster or other parties.
4. Stakeholders: anyone who has an interest in the product.  They are outside the Team and as a result, can only influence the Team’s activities at clear checkpoints.

Scrum, just like every other Agile process, is a carefully balanced framework.  Each practice, guideline, artifact and role are the minimum collection of elements needed to be successful with the framework.  When you fail to fill a role, give one role more weight or weaken a role, all sorts of dysfunctional behavior manifests itself.  In some respects, this is a strength of Scrum because it makes all sort of dysfunctions visible very quickly.  That is why the ScrumMaster role is VERY important.  Their job is to make sure people acknowledge the dysfunctions and try to devise ways to eliminate or minimize the obstacles.  In my experience, this is a full time job.

One dysfunction Scrum was created to eliminate was the detrimental impact of meddling Stakeholders.  Too many Teams have trashed about trying to implement this great idea or another from competing Stakeholders, that they end up chasing their tail and getting nothing done.  This problem is overcome through a combination of an empowered Product Owner and the Law that you cannot change a Sprint once it has started.   In practice, the diagram shows the new relationship the Stakeholders have with their Scrum teams.  Generally, they do not have a direct line of communication with the Team.  Most communications come to the Team via the Product Owner and the ScrumMaster.  Again, we must balance the need to protect the Team from distractions and the needs of the business to direct the Team.  Scrum provides this balance through the Sprint Review at the end of every Sprint where the Stakeholders are invited to review the product, give feedback, provide oversight and help the Product Owner reprioritize the Product Backlog.  With the Sprint Review, we can provide the proper balance between protecting the Team from distractions and letting the business respond to changing conditions rapidly and effectively.