Welcome to the first installment of my coaching series. In this edition I’m going to cover my ongoing experience with bringing a new Product Owner (PO) into the fold in our development team.
A couple of months ago we had a change in management and the new director of engineering has decided to take on the PO role. After a few discussions I quickly realized that I have a lot of work to do to align his vision of the role to what the team actually needs.
Here’s some of the pitfalls that we’ve run into which can trap traditional managers moving into the PO role.
I want super accurate estimates
The first sign came when the PO asked for accurate estimates on all the work we had left to do. So I pushed back of course and introduced him to the concept of the cone of uncertainty. Basically, the further out a task or story is, the less certain the estimate will be. However by looking at a burn up chart we can estimate a window of completion with a reasonable amount of certainty. And what’s more is that we can use that chart to change the scope of work to hit target dates.
Over my career I’ve had dozens of managers ask me to estimate all manner of software projects and the only constant in my estimates is that they were always wrong. The beauty of scrum is that it takes this inherent uncertainty into account. You may not be able to pinpoint when you’ll get through the entire backlog but at the end of every sprint you have a potentially releasable product. And then it’s up to the PO to decide if that’s good enough for a real release.
Based on external influences the product may be good enough to release after getting through only half of the backlog items. The goal of the scrum team is to write software and get it out the door as quickly as possible in order to deliver value to the customer and not to hit an arbitrary date on a calendar.
I like to use a golf analogy to explain this principle. In traditional waterfall management you either sink a hole in one or you’ve failed. In agile you get multiple strokes and you get to adjust your shot after every one.
Who’s assigned to X?
The next teachable moment came up rather quickly when I was asked who was assigned to a particular story. Not one to give up on scrum so easily, I asked “why would you like to know?” Answer: “so I can make sure everyone is on task and not wasting time”
That answer uncovered a ticking time bomb just waiting to blow up in my face. After some deeper probing I discovered that one of his previous teams had a problem with developers veering off the critical path and working on side projects, they also weren’t doing scrum.
Let me be clear about this: if developers are working on something outside of the sprint it is a huge problem, but not in the way that he thought. The problem is that effectively the team is short a developer when this happens. The work intended for say five developers now has to be completed by four.
The interesting part about this is that it’s not the product owner’s job, or the scrum master’s job, to police the development team. A scrum team is self organizing, so if a developer decided to go off the reservation you can be sure the rest of the team will know about it and will take action to bring them back on track.
That being said, an observant scrum master should certainly have a frank discussion with said developer about focusing on the work in the sprint and not adding any pet projects.
Lack of clear vision
The most important job of the PO is to know what the finished product should look like. They build this vision by talking to stakeholders and crystallizing all of their wants and needs into a well vetted product backlog. This is why it’s so important for the PO to provide continuity over the development lifetime of the product.
In our case we had a changing of the guards half way into development, this can be a stumbling block for a well established scrum team and a death blow to a floundering one.
Why is this so detrimental to the development team? Let me give you an example to illustrate. When a developer has a question about the details of a particular story and he asks the PO, the PO should be able to give an answer, either immediately or after a brief consultation with a stakeholder. In our case the PO sent the developer directly to the stakeholder.
This has three deleterious effects: first of all it undermines the PO’s decision making authority. The stakeholder is now making design choices for the entire product which could affect other stakeholders as well. Secondly it devalues the PO role in the eyes of the developer, next time they have a question will they go to the PO or just go directly to the stakeholder? And finally it creates a potential situation where the PO doesn’t know what’s going on with their own product, what if the developer doesn’t relay the stakeholder’s decision to the PO?
Our PO is in an unenviable position, there’s a lot of tribal knowledge that he’s unaware of when it comes to the current state of the product. Which is what makes it so important for him to communicate with stakeholders as much as possible and to start making clear decisions about the direction of the product. It’s got to be his baby, and no one else’s.
In Conclusion (TL;DR)
I covered three pitfalls that our new product owner has already run into, doubtless there will be more in the future.
- Accurate estimates – burn up charts can give you a completion window, but inherently software effort can’t be accurately estimated.
- Assigning work – the team as a whole is responsible for the work, individuals must all pull in the same direction.
- Clear vision – a critical responsibility for the product owner is to take ownership of the product.
I’d like to hear about some problems that you or your team has run into and how you’ve handled them, please leave a comment below.