Jim was working as the business manager inside the company. He had years of experience and was a few years from retiring. Jim was working on a project with Michelle and he had been voluntold (told he would volunteer) that he was the teams product owner due to his rich expertise, background and knowledge on the business end of what the project was to deliver. We find Jim having a conversation with Michelle, where she is showing some frustration with Jim’s lack of involvement with the project.
“We’re doing Scrum” said Michelle, “and you’re the product owner!”
Product owner thought Jim? He had heard the term around the water cooler, and he had been skating by doing the job in a half-assed fashion, but now his real job was beginning to back up. It was time to do some homework.
After some digging, Jim discovered that the product owner role was a Scrum role whose primary goal is to ensure the vision that was asked for by the stakeholders/customers is being executed by the team and that he was now responsible for managing and representing the interests of the stakeholders and customers to his development team, who executed the work. He found that the product owner was responsible for working with the stakeholders to understand the functionality of the system under development as well as writing user stories and working jointly with customers.
“Great” he thought to himself, “more work.”
He kept reading and discovered the stories go into the something called a product backlog, an ordered and prioritized list sorted by business value and risk of the work needed to accomplish the project. It contained user stories and other things like bugs and various issues.
“Even more work” he said out loud. He began to wonder how to push this off onto the team. He went back to Michelle to share his concerns.
“Michelle, I’ve been thinking about this product owner role. I didn’t commit to the responsibilities of this role. My manager said I would do it because of my background. I don’t mind helping you out but I just cannot take this on at this time. I need you and the rest of the team to do this type of work. I’m far too busy. You know what we need to do this year so just make it happen and if you need anything critical, pull me in, but I need the team to drive this” said Jim.
Michelle was shocked.
“Jim, I don’t think you understand. You are best suited for this job. You have the experience, the background, relationship with the stakeholders, and you know how this thing should work. We need what’s in your head. You’ve been working on this for quite a long time. I’m worried that if we just come to you for critical items, we’ll end up building the wrong thing. Can we really afford this?”
“I don’t have time, do your best” said Jim.
You might think this is isolated and uncommon, but unfortunately in today’s overloaded and understaffed businesses with multiple simultaneous projects, its reality. People are often “too busy” and can’t do their jobs because the business lacks the necessary slack in the system to allow for flexibility and change.
In the story, we have Jim who is essentially handing off his product owner responsibilities to the team (never mind the fact that he was not committed in the first place). We have the team who doesn’t have the insight into the business or the vision and has been tasked with moving the project forward. This is a recipe for disaster.
Jim, as the product owner, is responsible for managing the vision, keeping it on track in the form of user stories and keeping those user stories prioritized and ordered through frequent interaction with customers and stakeholders. Jim, as the business manager, has the industry and business background, and owns the relationships with the customers and stakeholders. By handing off this responsibility to the team, he is essentially signing both of their death certificates.
The team, working to please its product owner through frequent releases, working software and collaboration, has now lost its primary source of knowledge. Jim’s responsibility is to provide the team guidance and to answer questions when ambiguity arises around user stories, and that is now gone.
I say “a solution” and not the solution because there is no single, all-encompassing solution to this problem. I see this problem more than you might expect and here is the advice I give to my clients.
- Help the product owner/business manager understand their role. The product owner is a full time job, especially with projects that have a lot of change. The longer the project, the more likelihood for change. To read more about the product owner, click here
- Discuss the impact of this decision. The decision to have the team become the product owner will end in failure. The impacts of this decision are
- The team will build the wrong thing. Why? Because they don’t have the background or knowledge of the vision the way the product owner does. The teams focus is a shorter term technical focus, where the product owner holds the long term vision through active product backlog management and customer interaction.
- The product backlog will become stale. When there is too much pressure in a system, something will give. The first thing I see give is the product backlog. The team will not keep it up to date, nor will they have the frequent interaction with customers and stakeholders like a product owner would (this is called grooming). This is because of the focus of the team – executing the project – not managing its scope and area of focus.
- Money will be wasted. If you believe that these impacts don’t come with a cost, you are wrong. Time will be wasted, as well as money, and opportunity cost will be lost while the product owner is too busy. Meantime, team is struggling to build the product or service and trying to manage the stakeholders and product backlog (the job of the product owner), doing both poorly.
- Velocity. You will see a significant drop in the teams’ velocity. This will directly result in a slippage of stories. Publish this data, and once you have three to six sprints worth of data, go back to the all-too-busy product owner and say “here is our new release schedule,” which should be much farther out than it was before due to the increased overhead in the team in doing both roles (team and product owner).
- Customer satisfaction. This is a little harder. In your review meetings, ask the customers if they are satisfied with team performance and their delivery. Show them the velocity numbers and the projected release plan. If they are happy, the team is in great shape. Most likely, however, they’ll be a bit worried and/or upset with the performance of the team due to its increased overhead and the longer release schedule.
That’s it. I hope you found this article of value. if you liked this post, check out my book, which is full of good tips like this.
Additionally, there are several resources you may find of value to help you identify/prevent this from happening.
- Book: Slack by Tom DeMarco – read it and give it to everyone
- 14 day sprint timelines – print them out
- Intro to Scrum section on this website, specifically