The Three Roles in Scrum

Scrum supports three roles which are the development team, the Scrum master, and the product owner.

The Development Team is a cross-functional group of individuals who collectively possess the required skills to perform the required software development work. The Scrum Master is an authoritative role that is responsible for enacting Scrum values and practices. The development team and the Scrum master are rather clearly defined so let’s focus on the Product Owner, a cardinal role in the Scrum software product development method.

The Product Owner Role in Scrum

The Product Owner role is a managerial role that is responsible for defining, prioritizing, and maintaining Product Backlog Items (PBI) which are contained in the product backlog. Because the PBI is not defined in Scrum and therefore the product backlog can contain “everything”, by inference and consequence the product owner now becomes the responsible role for managing “everything”.

The development team may do different things but it is only responsible for core development work and the programming code. Consequently, the product owner must perform and assume responsibility for any complementary work that is not core development work. So by a perfectly legitimate interpretation in accordance with Scrum guidelines, the product owner role can be extended to be also the executor and responsible party for market research, product architecture, project budgeting, release management, launch management, and much more... just about anything that is in the product backlog which is not related to coding or testing.

Managing work prioritization in a product backlog is very different than understanding market research and documenting the market problem—again, the skills required just for these two tasks demand different types of expertise, education, background, and experience.

In many companies the product owner role is assumed by a former product developer who usually considers the move a promotion, or by a former product manager who often considers the move a demotion. Coincidently and among other factors, when the product owner role is given to a former product manager, this confuses some people to equate the product owner role with the product manager role and regard the move as a legitimate and natural thing—which it is not.

The source of this confusion is due to the lack of Scrum’s explicit placement in the company’s processes: Scrum explicitly owns the solution space as expected, but it does not definitively exclude itself from the problem space, although it neither claims to be in or own the problem space. The basic lack of clarity on the separation of problem and solution spaces in Scrum is the primary source of many difficulties and inefficiencies.

Compounding the difficulty, in Scrum there is an insufficient number of roles which do not cover all the different types of tasks required in a software development project.

There is a common denominator that is being voiced by virtually all product owners. The reality is that Product Owner has become a job title that represents a collection of several roles; one of them is the original product owner role that is responsible for managing the product backlog. Due to the very fluid original definition of a product owner in the Scrum method, internal politics, and (usually) a technology-driven culture, the Product Owner job title can now also represent the roles of Product Manager, Program Manager, Product Architect, Release Manager, Launch Manager, and more... This is similar to the company dynamics that try to generalize product management and the product manager.

Given the extremely loose job description, virtually all product owners report an excess of roles, too many to be effective. In addition, the roles vastly differ in character and mindset with some assigned roles emanating from both the problem and solution spaces, which only compound the difficulties.

Analysis of the aforementioned demonstrates that in order to successfully implement Scrum, from the role and artifact perspective, the following guidelines should be followed:

  • 1. The product owner resides solely in the solution space.
  • 2. The product owner only manages the product backlog.
  • 3. The product backlog only represents a prioritized list of required software

development work.

These guidelines work and fix Scrum deficiencies. However, the problem with these guidelines is that they contradict some basic tenets in Scrum which do not officially provide for managerial roles other than the product owner, and do not support artifacts or documentation other than the product backlog—which does not allow obvious leveling of different types of information.

This beckons the realization that Agile methods in general and Scrum in particular are ready for the next phase in their evolution. Indeed Agile methods are useful but must evolve to compensate for present Agile methods’ deficiencies.

The practitioners and companies are clearly ready for a new breed of Agile-inspired software development methods.

 
Source