Phil Kan (philxan on twitter) recently sent in a problem to the The Agile Revolution problem bag:
We have a Product Manager who’s supportive of Agile in theory, but won’t do the work we need him to do. How do we manage that?
A few tweets later we learnt a little more…
They aren’t available for the discussion of stories (often away) & the highest priority work is the customer who screams the loudest. Rather than product progression, we do a lot of tweaks and minor bug fixes. We do showcases after each 2 week sprint (a release is usually 3 sprints). Are we just expecting too much from our customer?
Because we were running incredibly over time there was a little skimming of the issue and I wanted to take some additional time to cover off a few points that we might not have been awfully clear or comprehensive on.
The stance –
- Craig: Do you have the right person?
Is this really the right person as your Product Owner? Is someone more suitable that can give you the time that you need?
- Tony: Stop working on the product.
If they can’t give the time then they are obviously not committed to the product. By stopping work on it (tools down) you are testing their commitment. If they are upset that you are no longer working on their product then as calmly as you can explain that they need to provide more time in order for you to reach your goals. Ask them the question “If you wanted a renovation on your home, would you just hire a builder and say ‘Do what you want, I’m sure you’ll get it right.'” My concern is that sometimes commercially this is not a viable option.
- Consider moving to a Kanban method rather than using Iterations (which was my second thought five seconds after tools down). I hear a lot of complaints (and more of them from product owners) that say Agile has too many meetings. Kanban has a more natural flow. You can still release every six weeks if you want. Or just release whenever now. Yes the product owner will still need to groom the backlog and provide details for you to build off but this is now on a more pull basis then scheduled.
- Replace your product owner with your true end customers. This is really an extension on the above thought. If you move to Kanban you can setup a regular cadence with all of your customers at once and groom/define stories in the backlog. David J Anderson talks about this process a bit in his Kanban book.
- Consider shifting to three week iterations. If the complaint is that there are too many meetings then three weeks will reduce the number of meetings over time, but in reality this is more of a perception. Don’t get me wrong, perception trumps and if they think it is better, even though it is the same then it is win-win.
- Conduct a root cause analysis. Gosh we are so bad at this. Look at how we all initially reacted. Solution, solution, solution! Now in fairness, if you give a problem in a single tweet you are only ever going to be able to go straight into solution mode, but spend some time being frank with your customer. Call the spade as it is. Explain that it is an issue for the team, but that you want to work with them (the product owner) to find a resolution for all. Get to the depths of why they cannot provide the time. Get to the depths of why you need the time. If an understanding can’t be made then maybe look at the solutions above.