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 (not done well enough). He mentioned 6 ‘top tips’ on 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 (I added some numbers):
3. Not the Manager
5. I had a vision
6. 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.
He had become a very successful product owner in a difficult environment where others had failed (not done well enough). He mentioned 6 ‘top tips’ on 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 (I added some 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
organisation (~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 fullfil my backlog.
- I encourage team members to generate ideas on how we can improve
what we do or how we do it (actually wrt ‘how we work’ – I always listen
to them first). However, I want to hear about these ideas when they are
at the whiteboard stage.
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 valueable at the top.
3. 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?
4. 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 standups would help).
5. 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 conextra 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).
6. Small Items
[Ed. Note: The firm was used to 'features' that we 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.
- Also I have several teams so I can manage about 20-30 items per sprint but not 70.
***
Thanks Rich!
No comments:
Post a Comment