Identifying roles and responsibilities

There are only three roles in Scrum: Product Owner, Scrum Master, and developers. Adding additional roles and responsibilities does not add value in the Scrum framework and can cause more overhead, inefficiencies, and bottlenecks in the development process. Let's take a closer look at these roles.

Note that Scrum does not have the role of the project manager. However, Ken Schwaber, in his book titled Agile Project Management with Scrum, notes that the Scrum Master is, in effect, the project manager for Scrum-based projects. Nevertheless, the responsibilities of the Scrum Master are quite different. I'll address those differences shortly in the Scrum Masters subsection. But first, we will start with the first role in Scrum, which is the Product Owner.

Product Owners

It may seem counterintuitive, but the Product Owner role is a part-time position with regards to supporting the Scrum development effort. The Product Owner is effectively a product manager who is responsible for defining product development enhancements, as well as priorities that add the most value and generate the most revenue per unit of development cost.

As the product manager, their job is to assess market needs that are not satisfied and therefore represent an opportunity to the company. They spend the bulk of their time assessing the market opportunities, understanding user needs, conducting competitive assessments, and developing strategies for sales, marketing, and distribution.

In other words, the Product Owner still takes on the business, marketing, and sales support roles of the product manager, but also assumes responsibility for defining product requirements and priorities within the Product Backlog. This added responsibility might not seem like such a big deal. Still, they alone are held accountable for increasing customer desired value in the product while managing life cycle costs and ROI.

From the results of their analysis, the product managers are in the best position to develop the list of high valued ROI customer requirements. When wearing the Product Owner hat, the product managers work with the development team to establish development priorities to deliver the highest value ROI features and functions in the shortest possible time. The Product Owner is ultimately accountable for the profit and loss of their respective products and, therefore, cannot delegate the responsibilities of the Product Owner.

Business managers sometimes employ the concepts of Vilfredo Pareto's Principle of Unequal Distribution (also known as the 80/20 rule, Pareto Principle, or Pareto Analysis) to analyze which subset of people or activities have the most significant impact against a broader set of items. Vilfredo Federico Pareto's (1848 –1923) academic focus was on the economics of land distribution. However, other observers found the 80/20 phenomenon (for example, 80% of consequences come from 20% of the causes) seemed to apply to many other areas of study, and in particular, business management.

What this rule implies, from the perspective of product management, is that ~80% of a product's benefit or value comes from only ~20% of the implemented features or work activities. Likewise, ~80% of the negative impact on product results from only ~20% of the issues identified. From a practical standpoint, this means that the Product Owner must prioritize work around 20% of the features that are the most useful to a customer or end user. Put another way, 80% of the identified work has little practical value and represents wasted effort.

The Product Owner is ultimately responsible for defining the right high-value set of features for their assigned products. Moreover, they must maintain the prioritized backlog of high-value product features and ensure the requirements are clearly defined and articulated to the product development team. Besides the business and user requirements, the backlog must also include the technical requirements defined by the development team, as necessary to support the architecture, design, and non-functional requirements of the product.

Finally, even if the Product Owner successfully identifyies the right 20% of the available features, a company still has to make a profit. Likewise, nonprofits and government agencies must live within their budgets. Therefore, the Product Owner is ultimately responsible for assessing the commercial viability or budget feasibility of producing a new product or feature.

Developers

There are no types or categories of developers in Scrum. Every Scrum Team member only has the title of Developer, and there are no senior developers or junior developers. Likewise, there are no GUI developers, testers, programmers, database developers, or any other types of developers – only Developers. The reason for this is simple. Effective Scrum Teams are self-organizing and cross-functional, realigning their resources on-the-fly to meet the unique needs of each Sprint. And, all developers must carry their weight. Adding titles works against this philosophy.

Developers do have different strengths and weaknesses, skills, and interests, and the team can take advantage of those differences to apply the best people to the right tasks in each Sprint. But the overarching goal is to ensure the team has an abundance of overlapping skills to maximize their flexibility and productivity as a group.

Scrum developers perform all the work that is necessary to iteratively implement increments of new functionality across the development life cycle of a product. That's a fancy way of saying they build stuff. They also test the products they create. SQA is not a role in Scrum. Instead, the development team members identify, analyze, test, and fix any bugs or defects in the products they build.

The term iterative refers to the frequent and repetitive nature of software development under Scrum, typically limited to individual and independent development cycles of 1 to 4 weeks. The developers work within these timeboxed constraints to deliver fully "Done" increments of new functionality. The Scrum terminology for an iteration is Sprint.

The term increment refers to the concept that each Sprint produces a new slice of useful and high valued functionality. Each increment must be fully formed and integrated with previous increments of functionality. By definition, each increment of functionality must meet the definition of done.

In other software development approaches, the closest equivalent to the definition of Done is acceptance criteria. Every increment of functionality must have a unique definition of Done, as defined by the Product Owner and Scrum Team. In other words, the term Done describes the acceptance criteria for each new increment of functionality.

You might be asking yourself why it is so essential to define a definition of Done for every product enhancement. There are a couple of reasons. First, code under development represents work in progress that becomes increasingly difficult to manage and more complex to debug as it accumulates. This issue is no different than a manufacturing facility that allows materials to accumulate at every piece of equipment in the factory. After a while, it's nearly impossible to track all the individual parts and concurrent workflows. Secondly, the different pieces of code under development must eventually be integrated into the product. The longer the team holds off on the integration of code, the more difficult it is to determine the cause and effects of bugs discovered after these integrations.

The better alternative is to test individual segments of code initially to make sure that each piece of code works correctly, and then integrate each segment into the baseline code for the system to ensure it doesn't break something else. If the new code does break something, at least the developers have isolated the problem and know that something about the interaction of the new code with the existing code set is causing the bug.

With these issues in mind, the ideal situation is that each Sprint results in a potentially shippable product. The Product Owner has the sole authority to release a product into production, and there may be many reasons why they choose to delay the release of a potentially shippable product to a customer. But the main objective is to ensure that the increment of functionality resulting from each Sprint is fully integrated with previous increments of functionality, and thoroughly tested to ensure there are no bugs in the product. This integration and testing strategy gives the development team confidence that they can continue to build on the completed increments in future Sprints, without worry that untested software components may cause problems in future increments.

Scrum Teams are too small to enhance their ability to function as a cohesive unit. Not including the Product Owner in the Scrum Master, Scrum limits team size to three to nine people.

It may take some time for the team to gel and require some trial and error when it comes to grouping people together. Since the team works so closely together for extended periods, they must have respect for each other and have the ability to work through difficult issues without causing conflict. The team must have diversity in terms of their skills and personalities to ensure they can attack problems with abundant knowledge and from differing perspectives. Not every approach works equally well for every type of problem.

Teams that encourage multi-learning to develop a diverse and overlapping set of skills have more ability to self-organize to address the different types of problems that arise from the Sprint. The development of cross-functional skills also makes it easier for teams to adjust when individuals are sick, on leave, or otherwise absent. There is little luxury for small teams to have individuals with specialized skills, as their skills likely cannot be fully utilized at all times. To be effective, Scrum Teams must have autonomy and freedom to self-regulate their activities so that they can apply the right set of skills and resources to the tasks identified within each Sprint. In short, waste occurs any time a team does not have the skills and resources to apply to the work at hand, or when they have specialists whose skills are not required.

The sole purpose of Scrum Teams is to develop new increments of functionality across each Sprint, typically within a single product line. The members form a cross-functional group that includes all the skills necessary to complete the work of each Sprint. They are accountable for completing each increment per the agreed definitions of done. The entire team is responsible for completing the work of the Sprint. If someone is hung up on a task, other members jump in to help out. Everyone in the team is responsible for achieving the Sprint's Goal.

Since Scrum Teams are responsible for getting the work of each Sprint done, they cannot rely on outside help. The only exception to this is when they require the skills of specialists. Even then, the role of the specialist should include training the Scrum Team members on their skills before they move on to work on other projects within the organization.

In other words, when specialists are required, they tend to rotate from Scrum Team to Scrum Team to help develop organizational skills and their areas of expertise. Once the organization builds enough organizational skills in the specialized domain of knowledge, the specialists should move on to become a member of the Scrum Team. This means the specialists must also multi-train in the disciplines required by the Scrum Teams.

As you might imagine from the preceding descriptions, effective development teams do not evolve overnight. The organization needs to give its Scrum Teams time to gel, build their skills, and learn how to work together. Given the investments required to build a capable team, it makes no sense to disband a team when a product development requirement comes to an end. Instead, the more effective strategy is for the organization to move the team onto new work, either on the existing product or different products.

Scrum Masters

Scrum Masters are the project managers of a Scrum project. But the role is different than that of the traditional project manager. First and foremost, Scrum Masters are responsible for the successful implementation of the Scrum process and the overall effectiveness of their teams. But rather than directing the activities of the Scrum Team, as the traditional project manager would do, the Scrum Master allows the team to decide how to do the work on each Sprint. The Scrum Master is ultimately responsible for the implementation of the Scrum process and spends their time supporting the team to ensure their success.

One of the primary ways that the Scrum Master role differs from the project management role is that, while they are responsible for the proper execution of the Scrum process, they are not responsible for the actual work of building a product and its delivery. The product team, as a whole, is responsible for their work and delivering increments of new functionality on every Sprint, not the Scrum Master.

Scrum Masters are facilitators whose primary work is to ensure the successful employment of Scrum rules, artifacts, and events. The Scrum Master's role is that of a servant leader. In other words, their leadership doesn't come from or through directives but rather from their knowledge and their effectiveness in supporting the team by removing impediments, mentoring and coaching, and facilitation of events.

As the team's expert in Scrum, the Scrum Master guides the Product Owner, their team members, and the organization as a whole. Guidance can take the form of one-on-one mentoring, coaching the team, and providing training to those who were not familiar with the concepts of Scrum. At all times, the Scrum Master must be careful not to impose their will on any of the team members.

As an example, a traditional project manager might view the daily Scrum meetings as an opportunity to get updates and direct work from the Sprints task list, just as they might manage work on a schedule plan. But they have missed the point when they do this. As a facilitator, their role is to get the team members to open up about the work they are doing and the challenges they are facing.

Directing work is not the same thing as facilitating work. Whenever a Scrum Master feels compelled to tell a team member what they should work on, they have missed the point of their role. The development team members have the responsibility to self-organize and assign work against the Sprint Backlog with the resources and skills available within the team.

The Scrum Master's role – for example, in daily meetings – is to ensure the team members use that opportunity to inspect their work and evaluate any variances that are impeding their work and adapt their approach accordingly. The team members may also ask the Scrum Master to help resolve any impediments so that the team members don't have to spend their limited time on such activities. Also, when the Scrum Master sees behaviors that are counterproductive to the successful implementation of Scrum, they use those opportunities to redirect the team's behaviors through coaching, training, and mentoring activities.

In support of the Product Owner, the Scrum Master's primary role is to ensure everyone has a common understanding of the issues facing the business domain, the Product Backlog priorities, and Sprint Goals and objectives. They may assist the Product Owner in finding effective ways to prioritize the Product Backlog. Again, it is not the job of the Scrum Master to make the backlog a priority, but rather to help the Product Owner develop effective techniques for managing the backlog. Besides, Product Owners may not have a sound understanding of empirical process control.

This issue becomes evident when the Product Owner attempts to pre-define every potential customer and end user requirement or assigns equal and high priorities to all of the backlog items. The Scrum Master must help the Product Owner gain confidence that they can better identify high-value requirements and priorities through the iterative and incremental development processes of Scrum, which are validated by the product being frequently inspected by customers and end-users.

The final point I want to make is that the Scrum Master must work in alignment with the organization's culture, goals, and objectives. Their primary concern is their assigned development team or teams and removing any impediments that affect their ability to meet the commitments they have made for each Sprint. And as part of their duties, they make sure all team members, the Product Owner, and the stakeholders within the organization understand the concepts and practices of Scrum. But they also must realize that, sometimes, an ideal situation can't be obtained due to corporate policies or culture.

In such cases, the Scrum Master may have no choice but to make accommodations or tweaks to the Scrum process to ensure the Scrum Team functions successfully within its corporate environment. When such situations occur, the Scrum Master must reach out to decision-makers, organizational stakeholders, the Product Owner, and affected team members to discuss the situation and potential impacts and collaborate on defining the best approach forward.

Now that you know about the unique roles and responsibilities within Scrum, we need to take a look at the meetings and activities they participate in within Scrum. Scrum calls these activities and meeting Scrum Events. In effect, Scrum Events establish the boundaries of Scrum meetings and help manage the flow of value-based work within the Scrum framework.

Empirical process control is the approach Scrum uses to remove impediments and resolve issues.