Many product owners take a fairly directive, hands-on approach when leading their Scrum team, just like the guide indicates they should.
Developers take comfort in a product owner who attends Scrum ceremonies and can directly answer questions in refinement sessions. Any over-dependence on the product owner is considered beneficial rather than a liability.
Where this gets problematic, and quickly, is when the product becomes more complex, the user base grows and becomes vocal about their needs, or the Scrum team itself gets bigger. Demands on the product owner grow significantly, even exponentially.
It’s a mistake to believe the product owner should remain hands-on in the same way they were previously. Unfortunately, I’ve seen several product owners burn out like this.
The first line of defence is delegation and empowerment. The product owner should delegate as much as possible to empowered team members. Even certain product decisions should be delegated. Remember that everyone has a certain level of ‘ownership’ or commitment in a Scrum team, and having a clear product vision amongst the team helps.
Beyond that, and more as a function of technical team size, delegating to nominated individuals is helpful, such as a business analyst or technical lead. By this stage, expect the product owner to perhaps only attend the sprint kickoff and end of sprint demo. It’s not what the Scrum guide says, but it’s realistic and still workable for larger teams and complex products.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |