Organizational culture is a reflection of the beliefs, ideologies, policies, and practices of an organization. Culture is important because it guides what and how work gets done. Team culture, in Agile, in addition to being influenced by the organization’s culture is heavily influenced by the product owner’s interpretation of the organization’s culture.

For a Product Owner, a larger teams means more complexity!

For a Product Owner, a larger teams means more complexity!

As organizations find that using Agile delivers higher levels customer satisfaction, higher quality and greater efficiency and effectiveness, they try Agile in more situations. One of the most common scenarios that organizations struggle with as they expand their use of Agile is with larger and larger projects. One common stumbling block is implementing the product owner at scale. Getting the product owner role wrong is a problem. The product owner plays a pivotal role in an Agile project. One of the critical aspects of the product owner role is the relationship between the product owner and the team, stakeholders/customers and Scrum masters. As projects are scaled, these relationships become more complicated.

Product Owner to Team(s): On paper, the relationship between a product owner and team is fairly straightforward. The product owner owns and prioritizes the backlog, provides a product vision, involves customers, users, and other stakeholders and collaborates with others on the team. But, the role is more complicated; the product owner is also a leader, mentor, politician, and confidant, just to name a few roles. Add more teams to a product owner’s plate, and the relationships get even more complicated because the number of possible combinations required at any one time increases.

Product Owner to Stakeholders/Customers: The product owner is the primary facilitator and connector between the team or teams and external stakeholders. The product owner gathers needs and priorities that he or she leverages to prioritize the backlog. As projects become larger, the pool of stakeholders and customers will increases, which will complicate the role of the product owner. It requires judgment and tools to balance needs as in order to prioritize. As a project grows the number of groups of customers and stakeholders generally increase.

Product Owner to Scrum Master(s): The relationship between the product owner and Scrum Master(s) should be fairly straightforward. The product owner prioritizes, makes decisions and connects the team with stakeholders, while the Scrum Master mentors and facilitates the team. My observation is that real life is more complicated. The two roles often blur based on the personalities of the people involved. As the number of teams and Scrum Masters increase things get messy if roles blur. Since the relationship between each combination of product owner, Scrum Master and team might be slightly different, it will be difficult to predict the outcomes of interactions as people and groups involved in the project randomly work together.

If a large project chooses to leverage several product owners, the potential combination of relationships between the additional product owners and the stakeholders, teams and Scrum Masters increases dramatically, as does the level of complexity. We will discuss this possibility later in this series on scaled product owners.

The relationship between product owners and other constituencies in a project gets more complex as the number of parties increase. Complexity requires a proactive mitigation to avoid the possible negative aspects, such as communication failure, quality issues, reduction in efficiency or simple project failure. We will tackle techniques to mitigate the complexity that scaling an Agile project can cause in the product owner role in the next installment.

You need both the big and the small picture to deliver value.

You need both the big and the small picture to deliver value.

The concepts of project and product provide two alternatives that might lead readers to believe that one perspective is more important than another. You need both sets of behaviors generated by the project and product perspective. How these behaviors are incorporated into roles on teams is not as straightforward as designating a role representing project concerns and a role representing product concerns and never the twain shall meet. Both roles do not have to be separate people. Agile spreads the project-centric behaviors across the entire team. Even the product owner typically absorbs some of the project-centric activities. However, other than at a philosophical level, the team is not typically charged with performing the product-centric activities. Agile techniques spread project behaviors across the team while product driven behaviours are more concentrated.

Project-centric behaviors are focused on the delivery of the tactical plan, while the product owner has more of a focus on the vision of the long-term future, i.e. the product roadmap. Even though the product owner has a distinct interest in the tactical (what is to be accomplished in a sprint or release), the team has a more focused interest in day-to-day activities. The team must plan, monitor and adjust the day-to-day activities needed to meet their commitments during the sprint (commitments in Agile are by definition tactical). The product owner can contribute, however they typically do not have the technical acumen to deliver functional software. However, without a product view, the day-to-day project considerations will typically trump long-term considerations. In a mature Agile environment, the product view interacts with the project view to generate an equilibrium between long- and short-term perspectives.

Project and product focuses require a different measurement. The project focus on delivery/short-term goals generates a need to understand, pursue and measure delivery efficiency. Efficiency is a measure of transformation; how much of a set of raw materials is needed to create an output. Efficiently producing any output is only valuable, IF what is being produced is what is needed and can be actually delivered. Interestingly most software is a step toward a different product that is bought or used. Because the software being developed or enhanced is a step along a path, the value assigned often does not represent the ultimate impact to the organization (See our Re-Read Saturday series on The Goal for more on this topic). The product owner, as the steward of the product perspective, owns the definition and measurement of value. He or she needs to take the big picture view of what the market needs AND what the market will pay for. What the market will pay for is just as important for an internal product as an external. In order to understand the value a product delivers, the product owner must ask whether the result of a sprint or release positively impacts ROI, profit and cash follow. Efficiency is a mechanism to determine whether a team is making the most out of their “raw material,” but it does not provide feedback on whether what is being produced is the right thing, or whether the functionality delivered yields value to the organization.

In general the product owner will be the champion for the product perspective, however every team member needs to have an understanding of the how the future should unfold and the value they are being asked to deliver. The team will need to temper the product vision based on the constraints that the day-to-day environment provides. Both the project and product perspectives are needed to maximize value. Putting either perspective ahead of the other for any length of time will create an imbalance that will reduce team effectiveness.