The Cage Match Continues
In a 2016 Pragmatic Institute webcast, John Milburn and I discussed the differences and similarities between product managers and product owners. We used the analogy of a cage fight to highlight how the roles are wrestling for position in the responsibilities of leading product development.
We concluded that, while it takes a team to build a great product, there needs to be one person who makes final decisions about the product’s direction. And that can be the product manager or the product owner—the title doesn’t matter, but the accountability does.
The initial audience for that webinar was massive, and it continues to be a popular playback. But has anything changed in four years?
Product Management and Scrum
Conduct a Google search of “Scrum and product management” and the results reflect articles about how:
- Scrum is a real problem for good product management
- Scrum ignores complexity and focuses on delivering products—even if they’re the wrong products
- The idea of a done increment—when the increment is complete and useable at the end of a sprint—is great, but it misses all the other “product” work that a great product team must do
You’ll also notice that practices like user experience and design thinking are relegated to a magic zone outside the confines of the sprint itself.
The disconnect between the product and Scrum communities is odd. Both seem to challenge industrial thinking with the need for frequent observation and feedback. Both dismiss the false reality of detailed plans when managing complex work. Both encourage learning and engagement. Dig deeper, though, and this distrust seems to be a result of two challenges:
- Product decisions being made by the right people. Scrum and Agile encourage self-managed teams that are focused on a goal and empowered to make decisions in pursuit of delivering value. That means that some traditional product management activities can—and should—be taken over by the team. This can lead to conflict between the “development” team and the product manager.
- Done increment is not always good for the product. Scrum was born out of the realization that waterfall, with its focus on documents and tasks, was not actually delivering software. In response, Scrum placed special emphasis on delivering done incremental changes to the product. Scrum even includes a “definition of done” that highlights the level of quality, documents and signoffs required for something to truly be done. But software or product changes are not always the most economical way to build learning. Sometimes the team needs to build prototypes, conduct surveys, talk to customers and even do research. The balance often leads to conflicts between product professionals who want to learn and Scrum people who want to deliver.
Yes, and …
It’s always interesting to see the polarization of two well-intended ideas. Both communities care about frequently sharing learning, involving the whole team in value generation and engaging with stakeholders to gain insights and re-plan. But the reality of complex work is that each situation is different, meaning that absolute decisions about who does the requirements or how much product work is done in a sprint varies based on the situation. Let’s tackle both challenges.
Product Decisions Being Made by the Right People
The flow of work and decision-making in a product team is complex. Decisions are made on the micro and macro levels throughout—and at surprising times. For example, say you are working on a product backlog item about reporting. Nothing can be simpler, but perhaps the needs of the report change the timing of the engagement with the customer and the information captured. Suddenly, a little report requires decisions throughout the product architecture, not just in the reporting section. Who makes those decisions?
Scrum dictates that a developer would make this information transparent to the Scrum team and the team would work out what to do. The team is empowered to make the decision about the work (unless that decision puts the sprint goal at risk). But isn’t this decision so big that the product manager or product owner should make it? Or should it be escalated to management?
Here’s the reality: The product owner is on the Scrum team, and the Scrum team is working in a bound-problem space and timeframe that is defined by the sprint. The sprint has a goal and a fixed duration of fewer than 30 days. These guide rails provide freedom for self-management, as they reduce the risk of mistakes. They also ensure that the team is managing against the goal as insights are made.
In the backlog report example, the team has some decisions to make regarding scope (does the report really make sense? Is it asking for too much?) and impact (what does this mean for the other items required for the sprint goal?). The worst that can happen is that, when this item is presented at the sprint review, the stakeholders say the decisions they made were wrong, and that means reframing the next sprint based on that information.
Of course, the team can check with subject-matter experts if they are available throughout, but the important concept that Scrum enforces is that the Scrum team stays focused and isn’t waiting around for decisions to be made. Make things transparent. Look to the guide rails of the sprint. Make a decision and move on. Or, in rare cases, stop the sprint and take a step back.
In the broader product development and agile communities, the idea is that the team members are T-shaped, with the top of the T representing a broad skillset and willingness to try things. This means everyone must have an appreciation for the goal and a desire to understand the customers, buyers and investors. This requires product people to lead, educate, coach and mentor teammates to help them make the right decisions and understand the impact.
Mistakes will happen. But Scrum encourages transparency and safety, allowing for those mistakes to be taken as learning opportunities. If you want a more flexible and agile team, you must empower people to make decisions and spread knowledge and support to ensure that those decisions get better over time.
The Role of the Done Increment
Though Scrum is used in many different industries, its history lies in software development. And software development has a history of not delivering or delivering low-level quality. That’s where the idea of delivering done software was born. But the idea of done is more than just an antidote to poor software development.
By encouraging teams to work on delivering “product-ready” software, not only did teams deliver working software faster and more frequently, they also repeatedly proved what it takes to deliver that software. The economics, risks, and impact of that work were being better understood, which, in turn, helped improve the choices being made on which capabilities to deliver. You learn as you build stuff, and that helps you decide what to build next and how to build it most effectively. Also, if the increment is part of a much larger and complex business process, the impact of this change will provide much better insights because other things will break or work differently.
Of course, delivering working software is expensive and time-consuming. And, for requirements of high uncertainty, building it into a production-ready product is not the right decision. Building prototypes, surveying customers, and doing research all have value and can be used at the right time and in the right form.
Each Scrum team should look at balancing the need to incrementally make product progress with the learning required to do it right. The product owner needs to help make those tradeoffs by working closely with the team. Questions like, “Can we validate that assumption quickly and cheaply?” should be asked of the capabilities being developed. And that may mean that there is little work being done on the increment. However, that choice must be balanced with the experience you only get from delivering “stuff” to production.
The great thing about Scrum when working with a great product person is that balance can be achieved in a transparent way. Developers (the people doing the work) are empowered and supported to help the product manager/product owner make those tradeoffs. Tools like design thinking and lean UX help everyone involved in product development to think more clearly about the customer and understand their needs.
Balancing Risk Is Important for Success
Scrum was developed to focus on incrementally delivering value in a complex or unknown environment. The discipline of product management is a collection of practices that define, develop, maintain and market the product. The combination of these two worlds can only benefit the product and its customers, owners, and stakeholders.
Tension points should not be treated as opposing forces, but, instead, as an opportunity to explore the intent and find some level of equilibrium and balance. The ultimate enemy is neither Scrum nor product management, but the outmoded concepts of industrialism and waterfall thinking.
Modern product development is executed in a world of unknowns, with complex tradeoffs, imperfect decisions, and, oftentimes, a real lack of information. By using the ideas of product ownership within the Scrum framework, product managers can effectively deliver value. Product management brings to Scrum teams a broader view of the risks and challenges of delivering great products. Combine the two and you get the opportunity for greater success, but it will come with friction and decisions to make. I recommend that you embrace that friction—and use it to drive the whole team toward a better product.
Find these related resources on PragmaticInstitute.com
Certification Courses
Webinars
Podcasts
