The roles and practices of Scrum are simple and well defined, but the practice can be difficult.

Although Scrum is about a “mind-set” or adoption of a “culture” with ceremonies designed to make
the culture thrive, there are specific roles and practices that are vital to the method. These roles and
practices are simple and well understood, but the reality is that our participants follow them to varying degrees.

Scrum Roles

The ScrumMaster is not a “master of Scrum” but a role within the framework, something people may
misunderstand, especially as this relates to the Product Owner role as well. The ScrumMaster is tasked
with being responsible for ensuring that Scrum values and practices are encouraged and that barriers
impeding the progress of the project are removed from the team. This person leads by coaching and facilitating rather than by directing and controlling.

The proportion of participants who took the survey and had the official role of ScrumMaster was 18%, while 41% acknowledge having a dedicated role for the ScrumMaster in their organizations. It is commonly understood that many organizations will have a ScrumMaster and project manager, or will have the project manager act in the capacity of the ScrumMaster. This is reflected in our survey, in which 24% of the participants have a project manager in addition to a ScrumMaster and 35% have a traditional project manager who acts in the role of a ScrumMaster.

This strategy is taken by most organizations who are in the beginning stages of incorporating Scrum and/or assume the best-suited role for the traditional project manager is that of the ScrumMaster.

The Product Owner is the specific individual who has the authority to set business priorities for projects, usually through a Product Backlog. This person usually works directly with the customer. 24% of the participants had a dedicated Product Owner who fulfilled this role and responsibility. The Product
Owner may represent multiple customers’ requirements but has the responsibility and authority to reconcile conflicting  requirements. 38% of the participants had a Product Owner working in this capacity.

Unlike the ScrumMaster role, which seems well defined and followed, the Product Owner role
seems to give our participants some problems. In the “other” section related to the question on challenges faced with Scrum, several participants noted that individuals assigned this role lacked the proper background and enthusiasm to manage it. Another issue is raised by Jason Davis, a project manager for Victor Community Support:

“One issue that we have come across is that of our team being very small in numbers. We have found that in the process we have merged the roles of the Product Owner and ScrumMaster, which is not ideal as there are conflicting priorities on both levels. It takes a lot more energy to work through this process in dealing with the backlog and any critical bug fixes that may be identified. We have managed to work through these issues to date, but it hasn’t been without some struggle.”

Team Sizes and Artifacts

The Scrum team typically numbers 4-9 people, and 71% of the participants in our survey had teams of this size. Scrum teams are usually expected to be crossfunctional and self-organizing.

In one survey, 11% considered themselves cross-functional and 16% self-organizing. The use of a Product Backlog, Sprint Backlog, Burn-down Chart, etc., was noted by 38% of the participants. The Sprint Backlog is an output of the Sprint planning meeting. It consists of the tasks for the Sprint derived from the Product Backlog. “Done” defines what the team means when it commits to “doing” a Product Backlog item in a Sprint. The Sprint Backlog Burn-down is a graph of the amount of Sprint Backlog work remaining in a Sprint across the time left in the Sprint. The Release Burn-down graph records the sum of remaining Product Backlog estimated effort across time. 24% of participants use some of these
document artifacts.

Sprints | Sprint Planning | Sprint Retrospectives

A Sprint is one iteration of a month or less that is of consistent length throughout a development effort.
Only the Product Owner has the authority to cancel the Sprint. Sutherland and Vodde suggest that Sprints should be 2-6 weeks long. 75% run Sprints within this duration.  The Sprint Planning Meeting is attended by the Product Owner, ScrumMaster, and the entire Scrum team. During the Sprint Planning Meeting, the Product Owner describes the highest-priority features to the team. The team asks
enough questions that they can turn a high-level user story of the Product Backlog into the more detailed tasks of the Sprint Backlog.

60% have these conversations prior to a Sprint, while 16% do them right at the beginning of the project.
The Sprint Retrospective meeting is a time-boxed meeting where the team discusses what went well in
the last Sprint and what can be improved for the next Sprint. 62% hold these right after each Sprint,
whereas 13% wait until the end of the project.

The daily stand-up meeting is a time-boxed, 15-minute meeting used to inspect progress toward the Sprint goal and to make adaptations that optimize the value of the next workday. 59% have these meetings daily, while 18% do them throughout the week as needed.

Scrum does not define a software engineering or development process as that would defeat its philosophy of being as lightweight, flexible and adaptable as possible for a variety of complex situations.

Some use Scrum as a “wrapper” around an existing and proven software engineering practice, standard or method. A majority of our participants use at least one or several Extreme Programming practices in conjunction with Scrum, such as test-driven development, pair programming, continuous building and testing, automation, etc. 37% practice continuous building and integration, daily or multiple times a day.

The main recommendation that we can take away from this is that following Scrum roles and practices,
as they are prescribed, will prove to be much more effective. The reality is that many practitioners adapt Scrum, which has led to the term “Scrum-Buts” and in turn, the creation of the “Nokia Test.” While
other practitioners add practices to the basic Scrum framework as needed— known as “Scrum-And.” As
Steve Denning’s April 2011 article (“Scrum Is a Major Management Discovery”) in Forbes states:

“Despite the enormous potential that individual teams and departments have shown with Scrum, the overall picture of implementation has been quite mixed…. Most of these implementations with mixed results, which Sutherland derisively calls ‘Scrum-but,’ are examples of a failure to implement the full array of Scrum practices. When only some of the practices are implemented, such as doing the work in short cycles but interrupting the team during the cycle, the potential gains in productivity don’t occur.”

In one sense, Scrum can be viewed as a bundle of roles and practices that is best deployed as a whole, rather than piecemeal. For as Brian O’Reilly of Accel Solutions Group noted in an interview, “Agile with some constraints that provide a consistent approach regardless of team … [that] involve estimating
techniques, time-boxing … planning days up front [prior to a Sprint] rather than at each Sprint … may
be repetitive, but it assures consistency.”

While 41% of organizations are jumping into Agile waters without requiring a specific certification of their employees, more than half think a certification such as the Certified Scrum Professional (CSP) improves their chances of sustained success. As Liz Walsh of G2 Web Services states:

“In terms of moving forward with improving Scrum practices at our company, a few things spring to
mind. First, have a trainer come into our environment to help us understand how to address our specific scenarios (and perhaps dysfunctions). Second, find ways—maybe through that trainer, maybe through other resources—to make some of the more abstract objectives of Scrum more concrete and measurable. Like brushing one’s teeth is a practice that supports the goal of good dental health, so, too, can structured activities help keep people aligned toward the right goals.”

More than half of our participants are in organizations that provide training and consulting support for
staff involved with Scrum projects. Increasing these percentages should help with the consistency of roles and practices.

Recommendation: Follow Scrum practices as prescribed and ensure your organization is provided with appropriate support and training.