The easiest way to ensure all aspects of the framework are observed is through a strong understanding of how they enable Scrum's benefits. Once it is clear how various parts of the framework interact to facilitate productivity, Scrum teams-as well as managers and stakeholders-will want to protect the basic framework to make sure that its potential is maximized.
I'll illustrate how each of Scrum's roles works to facilitate productivity on an individual basis as well as in concert with other roles. As mentioned previously, when all three roles work in tandem, the overall effect is much greater than the sum of its parts. In part two, I'll discuss the most demanding of the Scrum roles: the Product Owner.
The Product Owner
In Scrum, the Product Owner is the one person responsible for the project's vision and direction. He or she leads by communicating with the team, outlining chunks of work through the composition of product backlog items (PBIs), and then prioritizing those PBIs.
Of course, there is some negotiation involved in this process. He or she usually consults outside of the team with stakeholders (other Product Owners, business analysts, business owners, end customers, etc.), to make sure their interests are reflected in the backlog. Then he or she must parlay the PBIs to the team, to make sure the acceptance criteria of the PBIs are clearly understood. For this reason, the Product Owner must remain available to answer the development team's questions and provide updates to stakeholders.
Why Is Product Ownership So Demanding?
The stresses associated with Product Ownership, however, should not be swept under the carpet. The primary reason this role is so difficult can be traced back to why projects fail or are challenged in the first place. According to the Standish Group's report "Chaos," the most common reasons a software project failed or was impeded are:
- Lack of User Input (12.8%)
- Incomplete Requirements and Specifications (12.3%)
- Changing Requirements and Specifications (11.8%)
- Lack of Executive Support (7.5%)
- Technology Incompetence (7.0%)
- Lack of Resources (6.4%)
- Unrealistic Expectations (5.9%)
- Unclear Objectives (5.3%)
- Unrealistic Time Frames (4.3%)
- New Technology (3.7%)
Realistically, out of those top 10 reasons, all but "technology incompetence" and "lack of resources" likely fall squarely on the shoulders of the Product Owner. That is, eight of the top 10 reasons relate to poorly articulated vision or a poor understanding of what the team can reasonably accomplish. Certainly, there is pressure on the team to deliver a product increment and the ScrumMaster to ensure processes run smoothly, but, without doubt, the report makes it clear that strong leadership and vision are most critical for software project success. Thus, the Product Owner's job is actually much more demanding than "owning the backlog" would imply.
Still, while strong leadership is a requisite of a successful Product Owner, Scrum asks that he or she give the team adequate room for leadership within the team to naturally emerge. As such, one commonly observed anti-pattern in Scrum is the tendency of the Product Owner to micromanage teams. The role's combination of authority and mandated accessibility to the team presents most Product Owners, especially those with backgrounds in traditional project management, with a temptation to become overly involved and direct at the task level. However, one of Scrum's most defining facets (and one that's central to increasing productivity) is its charge for teams to self-organize. As a result, determining what backlog items a team will work on each sprint is not left to the sole discretion of the Product Owner, but, rather, arrived upon through a negotiation at the sprint planning meeting. In