Roles

6. Roles

• Who is responsible for the product backlog
• Developers

Now that we know what we have to do, we should specify the responsibilities, in the form of roles that are needed. A role is not necessarily filled by a person. While sometimes one person will fill a role, very often a role will be split across more than one person or two people will share the responsibilities.

6.1 Objective: The (Stakeholder) Value Owner

The value owner is the role of deciding what value should be created. Value is based on both the stakeholders and the customers of the company. The normal name for this role is “product owner.” Unfortunately, the way the product owner role is defined and typically implemented in Agile is not effective. The name change is important to not carry the connotation of the Scrum product owner.

While the product owner role is somewhat ubiquitous in Agile approaches, it is far from the only one. It ignores the fact that different types of products may need the role attended to differently.

Why this is important

What is built is always an integration of business and customer needs. Who can best speak for each of these and integrate them should be the basis for a decision here.

Having a well-defined backlog to pull from is critical to facilitate the team working on the most important items.

How to implement when using timeboxing and flow

This responsibility is independent of whether an iterative or flow-based approach is being used. Options include:

• Have a product owner outside of the development team be responsible. This enables this person to talk to all stakeholders and avoid the team getting conflicting priorities.
• Have the team be responsible. This is often the best option when a technical product is being built and the team understands best what features are important.
• Have the product owner and team be responsible. In this case the product owner is responsible for the objectives as defined by the stakeholder while the team is responsible for the functionality to achieve those objectives.

Anti-patterns

If you don’t have this responsibility well-defined, people will work on different things based on their own priorities. It also enables people outside the team to go to individuals and tell them to do something that’s been decided for personal reasons

References: To see more about what a value owner should be, see Tom Gilb’s Value Agile: Agile As It Should Be. To get a better sense of the short-comings of the product owner, read Mark Schwartz’s The Art of Business Value. 

6.2 Objective: Developers

Developers are those people who are actually creating value. They should be a team, not just a collection of people working together. This requires mutual trust and an alignment on what they are creating.

Have all of the capabilities needed to create value quickly in a predictable, sustainable, and high-quality fashion. This does not include dependencies between other teams doing work but relates to when people’s capabilities that are shared across several teams are needed, for example, business intelligence or UX. Development teams should have all of the skills required to produce the software being developed. Ideally, this will be for the software being released in its entirety. In larger organizations, it may be just a component or module of what is being built. While it is virtually always best for a team to be cross-functional (meaning they have all the skills necessary to implement the PBIs being built) it is often the case that some capabilities are shared with other teams.

The way these people are organized is discussed in the Organizing Teams and Backlogs for Effective Value Streams section.

Why this is important

In order for people to work together well, they must all identify as working together. Obviously, if you don’t have people doing the work it won’t get done.

How to implement when using either timeboxing or flow

Wherever possible create cross-functional teams. When not possible, see if teams being dependent upon can provide team members needed for the necessary time. If all capabilities cannot be made to exist in the team then manage the dependencies on the shared capabilities via a Kanban board so that the delays created by using people outside of the team can be known and managed.

Anti-patterns

If you don’t have a well-defined team, people will not collaborate well with each other.