Product Owner Staffing Smells

The Product Owner is the most important member of the team… Seems simple, doesn’t it? The Product Owner is the “Single Wring-able Neck,” the person responsible for getting the customer the product they want, and therefore the person responsible for getting the team the information they need to get the customer the product they want. A successful implementation of Scrum pivots on the proper staffing, training, and support of your Product Owner(s).  By proper staffing, I mean this: A Product Owner should be a permanent member of the team.

Many of us are familiar with Tuckman’s Stages of Group Development:

  • Forming – the team is formed and initial communication and structure appear;
  • Storming – teammates class and the structures initially created break down, and new ones appear in their place, until;
  • Norming – the team resolves disagreements discovered while storming, and this resolution brings the team together; and finally
  • Performing – the team’s focus ceases to be the team, and turns to common goals.

(for more on Tuckman, refer to the Wikipedia entry)

Teams take time to gel. For a new Scrum Team to thrive, the Developers and Product Owners need to build a sustainable rhythm, a common language, and common practices with which to perform. After every sprint we hold a retrospective in order to build these skills.

The Product Owner’s job is a difficult one. Part of their job is Universal Translator, converting customer-speak to something the developers can understand, and vice-versa. They have to learn what the Development Team expects and needs in order to produce valuable software. Over time, the Scrum Team (ScrumMaster, Product Owner, and Development Team) will customize their workflow and process to something that works for them. This process goes on continuously, and does not stop at the Performing stage, which is a great contributor to the acceleration that highly productive teams can achieve.

If you change any member of the team, the established communication pathways are damaged, and the new team reverts to the Storming phase. This is disruptive enough. When you change Product Owners, the disruption is maximized, as they’re the team’s communication link to the outside.

This happens occasionally out of necessity, like when the Product Owner leaves the organization. Other times, it’s because the organization doesn’t understand Scrum. In these cases, there are some smells… I’ve smelled three different Product Owner Staffing Smells, each of these can harm the team in different ways.

The Product Owner Pool Smell

Scenario: In order to maximize the production of their teams, the organization has developed a pool of Product Owners. To decrease the idle time of their teams, a new product is assigned a Product Owners from the pool to identify stakeholders, hold story workshops, develop a backlog and provide the business with a development estimate. The backlog then goes into a holding bin until the next development team becomes available. At this point, the theory is that a pool Product Owner will take the backlog, brief the development team, and begin construction. The team’s previous product owner will then join the pool.

Rationale: We can have a constant flow of products being delivered, with no wasted time on the Development Team’s part.

Why this is a problem?

  • This is wasteful, since inventory is itself waste. A pre-prepared backlog might represent a product that the organization decides not to develop, or the customer might change, or… Scrum works because we gather information at the Last Responsible Moment. This isn’t that.
  • The team needs to re-form with a new Product Owner, after establishing a working relationship with their previous one.
  • The team is presented with a list of stories developed without their having the opportunity for customer interaction. In fact, the Product Owner might not have even prepared the backlog.
  • The team is presented with, and asked to develop to, an estimate prepared without their involvement, and possibly based on their previous velocity. This is a problem because when the team changes, their historical velocity is no longer accurate.

Result: Of all the smells, this is the least harmful to the team. They are still working with a trained Product Owner and have something resembling a backlog, but their trust in the organization could be damaged, and their resentment at having a team that was “working great” was broken up for no apparent reason. Scrum teams usually are smart people, and they will see that this makes no sense.

Resolution: In this case, the answer is fairly easy; the organization needs to reexamine its Product Owner pool, assign Product Owners to teams, and then figure out how to re-purpose their excess Product Owners. Alternatively, team reorganization or expansion can expand the number of Development Teams to account for the extra Product Owners.

The Customer as Product Owner Smell

Scenario: The organization has interpreted the Customer Collaboration aspect of Agile to mean that the best person to get the customer what they want is the customer.

This is similar to the Product Owner Pool Smell, but instead of the development team getting a trained Product Owner with a backlog, they get an untrained customer. For the customer, this is a part-time job, so they are not highly available to the team. The backlog is not being groomed nor are stories being made ready for development. The customer doesn’t understand how to verify either the acceptance criteria or the definitions of done. In fact, in many cases, these aspect of User Stories are not to be seen.

Rationale: Who better than the Customer to tell us what the customer needs? Additionally, this way the organization doesn’t have to spend the money to train Product Owners.

Why is this a problem?

  • The team needs to re-form with a new “Product Owner”, after establishing a working relationship with their previous one. Unlike the Product Owner Pool Smell, the Development Team and Customer/Product Owner lack a shared process language, so communication errors are very disruptive, and so…
    • The Scrum Master has to educate every new customer/product owner.
  • When a proper Product Owner is in place, the team can pose questions regarding the customer(s), questions they don’t want to hear. This is necessary so that teams can vent and ask questions before they ask the customer. Is the Customer is Product Owner, they can’t do this.
  • The Development Team doesn’t have a clear backlog with well defined stories.
  • The Development Team doesn’t have the type of readily available resource that a Product Owner provides. Instead of getting answers to questions in minutes or hours, answers may come in days or weeks (seriously).

Result: This is a harmful smell, indeed. Many times, organizations use this approach because of either a fundamental misunderstanding of Scrum, or because they don’t want to spend money on, as they see it, training a business person to talk to another business person. Since the Customer/Product Owner isn’t part of the team, there’s a lack of their trust about their accountability. Finally, Development Teams see this as being counterproductive and quickly get frustrated with the communication and speed issues.

Resolution: One easy way to solve this one is through experiment: Bring in or train a Product Owner and assign them to a team. After the team norms and begins to perform, the increase in both the quality and quantity of their work should be obvious.

The Product Owner by Committee Smell

Scenario: The organization’s teams work on different components of a large system, and the organization may have trained several Product Owners, or may have one Product Owner and several customers acting as a Product Owner committee.

Each team’s backlog is edited by the committee, which then assigns stories to different team’s backlogs for working. All Product Owners attend Sprint Reviews and Planning Meetings, where the Product Owners discuss and refine stories as the team is trying to decide to what they are comfortable committing.

Rationale: With this scheme, the intent is to share information with the team, and to reduce the reliance on a single individual.

Why is this a problem?

  • The team can never gain any rhythm or communication with a Product Owner; teams are in a constant state of Storming.
  • The team doesn’t have a single source of truth regarding stories; each “Product Owner” can have their own interpretation of a story.
  • In this setup, the axiom “when more than one person is responsible, no one is responsible” truly applies to this smell. There is no Product Owner responsible for anything. In my experiences, in this case “responsibility” for failures always gets placed on the Development Team

Result: This smell presents itself when an organization with a strong Project Management Office (PMO) tries to adopt Scrum without committing to is, and so wants to keep the PMO in place. In my experience, this leads to a rapid degradation of trust between the Development Teams and the Product Owner Committee.

Resolution: This is a very difficult smell to get rid of. The fact that the organization is using Scrum indicates some willingness, but the fact that the committee exists indicates a fundamental lack of understanding of Scrum or distrust in their Scrum Masters. I’d recommend engaging a Scrum Coach for this smell.

Coaching Can Help

Coaching can act as a huge disinfectant to solve some of these smells. As mentioned, Scrum Coaches will listen to the teams, the stakeholders, and talk about what’s going right and what’s going wrong. In the end, they give an external and impartial view of the situation to those asking.


Categories: Blog

Tags: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: