Advice from an experienced successful PO

I was doing a course with Dave Muldoon in Ottawa. And Rich O’Grady visited us.

He had become a very successful product owner in a difficult environment where others had failed.  He mentioned 6 ‘top tips’ that day, and then he wrote me explaining them a bit more.  What he wrote was pretty much what he said that day.

Here is what he wrote as advice (I added the numbers):

1. Transparency

• When I took over, there were several teams. Some had backlogs and some claimed to have backlogs. The ones that had “backlogs” were usually owned by the manager, updated by the manager and only viewable by the manager.
• I ran a workshop to create a new backlog for the whole organization (~40 persons) and it was placed on a wall initially. We had to put it into a tool (JIRA) due to the fact, I work on a different continent.
• Everything is on my backlog including defects.
• My backlog is viewable by anyone in the entire company but only I can change an item’s priority.
• This simple exercise in transparency allowed everyone to see what we would be working on and to simply build trust.

2. Only my Product Backlog

• Another part of the above exercise was to give a very clear message. The team members can only work from my backlog. If they work on anything else they are wasting my money.
• I forced a couple of teams to stop what they were doing by having executive approval to stop their work. I them told them to look at my backlog and consider what they could do from the top. At this point half the teams actually self reorganized as the team make ups at that point could not fulfill my backlog.
• I encourage team members to generate ideas on how we can improve what we do or how we do it (actually write ‘how we work’ – I always listen to them first). However, I want to hear about these ideas when they are at the whiteboard stage.

3. Continuous Value Analysis

• I built and used a simple and quick spreadsheet.
• I educated my stakeholders about the illusion of accuracy.
• My stakeholders enjoyed being shown at an EPIC level the different relative value points (I can’t easily attach dollars to what I do so I simply used a weighting system across a broad range of categories).
• My stakeholders are now in the routine of a quarterly review where they get to see at an EPIC level progress and if we are still getting value.
• With my teams I do this on a sprint basis. Some times it’s subjective other times there are very clear objective measurements. On a sprint basis I continually prioritize the backlog looking to keep the most valuable at the top.

4. Not the Manager

• I am not the manager (of the people in the Team). I am the Product Owner.
• As a coach to other POs, I noticed this recurring time and time again. The PO would simply be too involved in the team and dealing with issues the team should be dealing with.
• A number of POs were ex-managers so perhaps they were still trying to work as a manager?

5. Feedback/DOD (Def of Done)

• Always good!
• Don’t be afraid to say something is not done (0 points and back to the backlog).
• It’s a clear message.
• Essential here is a clear and collaboratively formed DOD and good acceptance criteria.
• POs make mistakes too (we’re all human) and shouldn’t be too proud to admit they got it wrong as well 🙂 (nice short sprints or attendance to some stand-ups would help).

6. I had a vision

• I had a vision formed by listening with my teams, users and stakeholders.
• It is clear and concise.
• From here “we” formed nice clear objectives (written in the con extra story format).
• Every item of work on my backlog can be linked to one of those objectives.
• It allows us to see the connection from top to bottom as to WHY we do what we are doing (and not doing).

7. Small Items

• I didn’t actually talk about this one but I wish I had.
• Small to me is about 1 week of work for the whole team.
  [Ed. Note: The firm was used to ‘features’ that is often 6 months of work for 1 team. So, these stories are much much smaller.]
• It takes a lot of work to keep the backlog manageable when everyone is trying to add so many tiny tasks on to the backlog.
• Several times I have ‘collapsed’ PBIs else the backlog gets unmanageable very quickly.
• Also I have several teams so I can manage about 20-30 items per sprint but not 70.

***
Thanks Rich!

 

« « Adopting Agile: Ask questions || The ScrumButt Test (4): You know who the Product Owner is » »