The first post in this series about descaling Scrum, focused on how to identify the product. If you have successfully identified the product, or used narrowing questions to get to the practical product to start with, the next step is to identify the Product Owner. If you assign an available person as the Product Owner with little to no regard for identifying the Product, there’s a high probability that your Scrum adoption will be less than successful at delivering value. Need the tips on identifying the product again? Visit: https://www.collaborativeleadershipteam.com/blog/less-series-descaling-scrum
Ok let’s say you have effectively identified the product and it’s large or even enormous! The framework included in this series that “descales” the organization when you have up to 50 people working on a large product is Large Scale Scrum (LeSS). When even more people are involved, the product may be a candidate for LeSS Huge which will be explored in the next post in our series. For more information and case studies, visit: https://less.works/
What Changes for Product Ownership in LeSS:
The good news? Nothing does. LeSS is Scrum. Product Owners still:
Are customer focused responsible for maximizing whole product value
Order the Product Backlog to best achieve goals and missions
Are one person, not a committee
Make decisions that are respected by the entire organization
The bad news? If these simple rules laid out in the Scrum Guide (https://scrumguides.org/) are not followed, not only will the Scrum adoption fail to produce valuable, working product, if it’s a large or enormous products mentioned there’s still little chance for success. Indications that these mistakes are being made include Product Owners “in name only” who:
Spend the majority of their time writing things like user stories
Have no authority to make product decisions such as scope, scheduled and budget that are respected
Are order takers saying yes to every request
Know your Development Type
In order to more effectively identify this Product Owner, it’s helpful to know the type of product development we’ll be engaging in:
Product Development: product will be used by a paying customer in the marketplace. If this is your situation where can you look for the Product Owner? In the Product Management group initiating the work. If there is no Product Management group, then the business unit driving the initiative.
Internal Product Development: for one or more users within the company. If this is your situation you can look for the Product Owner in the group that will use this product and/or who is closely involved in the work that the product or system will be used to support.
Project Development: for one external customer where work is “contracted”; this customer includes both the purchasing entity and the users. Does this sound like your situation? The Product Owner is from the company receiving the work/deliverable/system and much like the previous scenario, is hands-on using the system.
Closing Thoughts on Authority
Giving authority to the Product Owner and respecting their decisions are choices any organization is capable of making. If recommended steps have been followed for identifying the product and type of development, the chances of identifying a Product Owner who cannot be trusted with these choices is unlikely. Product Owners are not administrators reporting the results of someone else’s decisions. In order for your organization to deliver more value with less wasted time and wasted money resulting from overturned decisions and go-betweens, it is critical for the Product Owner to have authority over the Product.
To learn more from Large Scale Scrum (LeSS) co-creator, Craig Larman, and to earn a Certified LeSS Practitioner credential register here.
