Thank you to everyone who attended “The Product Owner – the most difficult role in Scrum” webinar, hosted by Angela Johnson, PMP, PMI-ACP, CST. If you missed it or would like to review, check out the recording.
In the webinar, the role of the Product Owner was discussed, looking at attributes that make a good Product Owner and why it’s the most difficult role in Scrum. Organizations often struggle with identifying a competent Product Owner and the webinar is meant to help give recommendations for that and similar issues. See below for questions that came up during and after the webinar.
Q: I work for RBC Royal Bank in Canada. The bank is in the process of scaling agile for projects across the bank. The big question is, how does the role of a product owner get the business who pays for the project to be available and be skilled to be a product owner?
A: Scaling is a hot topic with large organizations. We still need to answer, who is the customer? What is the product? If there are logical, large features within the product, you may have a Product Owner over those features. That P.O. is still empowered over that feature or features. There may be one or more Development Teams working on the respective feature or features – it just depends on the budget for those teams. In the event where the Product Owners have some sort of touch points across their features due to these being in the larger product or product suite, there may be what some Scaling approaches call a “Chief Product Owner” to escalate to. It is important to note that this is not somebody these POs are seeking permission from. The POs are empowered. They invoke that escalation only when necessary. Other authors refer to that CPO as PO and then those feature POs as Area PO or Proxy PO. The nature of those areas being Features is very important. They are not “components”. In other words, one team is not the “front end”, another “back end” etc. but features can “vertically sliced”. Some additional resources for you to check out are Essential Scrum by Ken Rubin and also Large Scale Scrum: http://less.works/
Q: I find that the BA role overlaps a lot with the PO role where a BA is not needed. Is a BA needed if there is a PO?
A: The perception that a Business Analyst “overlaps” with a Product Owner is unfortunately a misunderstanding of the Product Owner and how Scrum is different from a Waterfall approach. A Business Analyst is rarely empowered to make decisions for the Budget of the Product, the Scope of the Product or the timeline. A Product Owner has this authority. The PO’s decisions are respected – not overturned. They make informed decisions but do not need to seek permission. This is a leader in the organization that is identified as a result of asking who is the customer, what do we mean by product, who has this authority. Someone coming from a traditional Business Analyst role can certainly assist a Product Owner in evolving detail about Product Backlog items but they rarely are given the level of authority in the organization that is the essence of who the Product Owner is. Scrum is different. This means that it is not intended to continue using a “waterfall” approach but adopt new vocabulary terms for the old roles. That would not truly be different and is not what is intended with Scrum.
Q: What is the difference, if any, between a PM and a Scrum Master?
A: There are several differences. A Project Manager by definition is assigned to Projects. Projects are temporary endeavors with a Start and an End. Products are holistic. They only end when they reach end of life and a company no longer offers services or accepts feedback about the Product. A Project Manager performs several administrative funcitons in terms of tracking items for other people who are empowered: tracking budgets, tracking timelines, tracking scope, etc. A ScrumMaster is the master of using Scrum to deliver business value faster. The ScrumMaster is not an administrator and does none of the previously mentioned tasks. They teach Scrum in the organization, they are the internal coach to a Development Team, the Product Owner and to the Organization about how Scrum works differently than project management. A great reference for what a day in the life of a ScrumMaster looks like is the ScrumMaster Checklist by Michael James: http://scrummasterchecklist.org/
Q: Is there still a position for a BA on what is known as “the development team” if the BA is not the product owner?
A: That is up to the BA. The Development Team is a cross-functional, self-organizing team that works in a “rugby-like” approach to accomplish the Sprint goals for the product. Assuming this is a product that has traditional waterfall roles, if any member of a product Development Team chooses to stay “locked” into any traditional role, there is a risk of not delivering value faster as the Sprints become “waterfalls” which is not what is intended in Scrum. Scrum does not dictate that every Development Team member has to execute any task, it is expected that people work together adding value in any way that they can do to deliver a working product increment by the end of the Sprint. The idea would be “what is the team member formerly known as BA willing to do, willing to learn, willing to help wtih in order for the Development Team to meet it’s Sprint Goal?” This could include writing test scripts, executing tests, helping evolve detail for backlog items, documenting outcomes, coding, pairing with other team members, etc.
Q: Do you have some real product examples?
A: This is truly for any organization to answer. Who are your customers? What do they pay you for? Is it a service? Is it a physical product? If you have a cell phone, that is a product. If you have an insurance policy that is a product. If you drive a car, that is a product. If you have ever downloaded an “app” to a mobile device, that app could be a product. Unfortunately, many organizations “componentize”, breaking work down into locally optimized functional skill sets. The “product” only works for the customer at the end when the components are put together. Any Agile approach takes a ‘vertical slice’ view – cutting across the components – from the Customer’s approach of delivering something of value sooner.
Q: It is an interesting topic and a microcosm in the whole topic of a product based view or a project based view. Most companies I run into are very large 15,000 to 35,000 people and this shift in thinking is huge to them, if they do it at all, it is bit at a time. With larger projects is it difficult to have one person as a product owner? Often the owner of an initiative is high up and there are a number of people who could be a product owner for a part of it. It is challenging to get to a single owner.
A: Yes! It is. But it’s hard to “scale” something in an organization when it’s not understood or “working” at a small scale. We can start by asking, are you trying to scale Scrum across a large product? Across the organization? Across geographical locations? All of those? That is not simple. You may want to visit http://less.works/ for information on Large Scale Scrum. This reference includes many successful case studies of using Scrum at a large scale in many different industries with many different types of products.
Q: What is the product owner responsible for, what things typically make the role more difficult within an organization, and what can be done to improve it?
A: The description of the role and what a Product Owner is responsible for is also articulated in the Scrum Guide which is the official source for what Scrum is written by its creators, Jeff Sutherland and Ken Schwaber: http://scrumguides.org/ Organizations’ lack of understanding of the paradigm shift that makes Scrum different from traditional ways of doing work is what makes this the hardest role in Scrum. In the webinar we discussed how organizations are unwilling to step back and identify who the customer is, what is meant by product and then identify who has the authority and the knowledge for the product.
Q: Do you typically recommend to have the Product Owner training before becoming a product owner or if you would like to take your career in that direction? Or does it not make sense until you actually have that position? What is the difference between a product manager and a product owner; are they the same thing?
A: It may be helpful to understand the role if that is the direction you would like to take your career. This can be achieved by reading the Scrum Guide or other references on the Product Owner role or attending training. We do have Product Owners attend training after working in the role also. It comes down to your personal preference to have that context first prior to training or to have an idea about the role prior to accepting work as a PO. Roman Pichler describes the role as Product Owner = Product Manager + X Scrum is simple. Any questions such as “who owns the budget in Scrum?” “who owns the timeline for the product?” or “who owns the scope for the product?” can all easily be answered with Product Owner. Sometimes Product Managers are not involved from a strategic point of view and that is the expectation of the identified PO.
Q: What are some more ideas on how to identify and develop the product owner?
A: On the webinar we covered the key questions any organiation needs to start with: who is the customer? What do you mean by product? Scrum is a framework that can be applied to any industry so there is no one way to accomplish this. Identifying the Product Owner for an area of an insurance company may be completely different than doing that in an organization that manufactures razor blades. Let’s say you work in an insurance company. The vision for what will be offered to customers is a new type of Group Life Insurance. The customers who are going to pay our organization for that product are businesses. As the organization is deciding to invest in the new type of Group Life Insurance product we need to determine what the various limits will be, what the deductible will be, etc. Who has the authority for this in our company? Who owns that budget? Who is ultimately responsible for the launch of that product? That is your PO. It does not mean they do everything alone. They are a Collaborative Leader who listens, who takes input, but at the end of the day makes an informed decision for that product.
Q: Doesn’t there tend to be a “pendulum” effect? i.e., we can’t do Agile if we don’t completely reject Project. We should be looking for ways to adapt the Project mentality to achieve the intended goals of the Agile movement. I don’t think it is impossible. In the same way, people on the Project side need to find ways to adopt and implement Agile premises, concepts and techniques to improve Project outcomes.
A: Please understand that nothing shared was intended to be an absolute. But do know that by definition, Scrum is different. If it was intended to be project management, it’s creators would describe it as exactly that. Organizations rarely make successful change in any sort of “big bang” or absolute fashion. Organizations that are successful with Scrum generally start with a pilot. A pilot that truly adopts the framework as intended. This will provide the organization feedback as to what they may need to consider changing if they were to expand their use of Scrum further. The Project paradigm in many ways contradicts the Product paradigm which can cause confusion for the people being asked to do the work in two different approaches. But there is no question about what Jeff Sutherland and Ken Schwaber intended in creating a different way to approach work. Recommended reading would be the Scrum Guide or Jeff Sutherland’s Scrum: Doing Twice the Work in Half the Time.
Q: Could you give more in-depth examples of how to identify a product owner?
A: On the webinar we covered the key questions any organization needs to start with: who is the customer? What do you mean by product? Scrum is a framework that can be applied to any industry so there is no one way to accomplish this. Identifying the Product Owner for an area of an insurance company may be completely different than doing that in an organization that manufactures razor blades. Let’s say you work in an insurance company. The vision for what will be offered to customers is a new type of Group Life Insurance. The customers who are going to pay our organization for that product are businesses. As the organization is deciding to invest in the new type of Group Life Insurance product we need to determine what the various limits will be, what the deductible will be, etc. Who has the authority for this in our company? Who owns that budget? Who is ultimately responsible for the launch of that product? That is your PO. It does not mean they do everything alone. They are a Collaborative Leader who listens, who takes input, but at the end of the day makes an informed decision for that product.