How to rescue your new product owner from project management
I have seen it many times: a former project manager or line manager is appointed as the new Product Owner as part of the Agile or Digital transformation.
Still dizzy from the bang that hit him (or her) of the new role, just finishing the PO training, Scrum course, he meets the fresh team that is now staring at him (or her) with eyes wide open waiting for the magic to happen.
Backlog management, stakeholder management and setting priorities are now key activities in the freshly baked PO's workdays.
And so his new routine starts...
It's quite simple at the beginning: the first wavering stakeholder makes his plans known and the first mistake of making a planning and agreeing on timelines are easily made during the first few days. After a few weeks however, our PO starts to feel the pressure from different stakeholders. The theory dictates the PO decides on priority, but in practice he or she gets easily overruled by (higher) management because, well, "they know what is really important".
I have even seen cases where the Product Owner was bypassed all together and the, also newly hired or trained Scrum master (formerly known as team lead), was ordered to 'make it happen!'
And before we know it, we are bending over Gantt charts, resource planning excel sheets, etc. Sounds familiar?!
Stop & pivot!
A well known coaching technique to stop circular reasoning and repeating discussions is stop and pivot. Break in, stop the discussion and pivot to either another topic or, usually much better, another point of view. A much heard question at this point is: what if we don't do this?
Exactly that is what you should do as Scrum master: stop the madness! We decided a long time ago that gantt charts are evil! The moment you hit the print button, it's outdated and data is, hence the Cone of Uncertainty, based on unknowns.
We Scrum masters should coach the PO, help the poor guy or girl to just say no. No to 'highest priority stuff' that is pushed in mid sprint. No to any board member that is bugging the team. No to... well you get the idea.
Also as Scrum master, you should talk to the management and ask if they can help to empower the PO to the job as asked in the first place. If we don't empower the PO to be the single source of truth regarding the priority of that product, we might as well do without a Product Owner or even leave Scrum alone all together.
The PO should be able to explain beyond any doubt to the stakeholders why the priority is set in that particular order. Based on added value. This can be business value: if we do this, we sell more of our product. Customer value: if we do this, we have less complaints and happier customers. Or IT value (which is actually also business value): if we do this, we decrease technical debt and we deliver more stable releases with less bugs in the future.
Basically two things you might already have read in the Scrum Guide, are needed: coach the PO and coach the organisation. Help them to implement Scrum processes to help them embracing the Agile principles and mindset.
Follow the Shu Ha Ri paradigm: Shu: learn the rules, Ha: adapt the rules and Ri: transcend the rules.
Interested in my experience? How I have coached PO's and the organisation? Contact me! Leave a review.