The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?
The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians.
Karine doesn’t show up. She has a good reputation and was previously the product owner on a run away success. But on your project she seems quite distracted by other commitments. What she is working on is all good stuff and related to the wider programme but it means Karine often misses the important meetings with your development team. When she does turn up the team are very happy with the input she provides. They’d just like it more often. Much more often.
Phil doesn’t show up. He is a colleague of Karine and is product owner on another work stream within the same programme. Phil’s development team never sees him at all as he is entirely focussed on external communications.
Mike doesn’t show up. He’s the external customer and commissioned you and your company to build some software. He knows his business inside out but he’s never been involved in software development before. And Mike is quite busy and doesn’t often make it to your offices. When he does come in he talks to the CEO and not the developers.
I’m sure elements of these scenarios will sound familiar to you?
You’ve got a a big problem if the Product Owner does not show up to the key meetings of the Agile Heartbeat or is otherwise not engaged.
To address this problem you’ve got three options: Educate, Delegate, or Escalate.
In response to my request for questions along the lines of what do I do when … ? Jo asked:
What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.
In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:
- Normally vague/dynamic
- Completely vague
- Massively dynamic
The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.
The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
People don’t resist organizational change! – People resist being changed!
The Communication Toolbox
My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
A fundamental military axiom is to reinforce success.
Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.
Wikipedia: Reinforcing Success
I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.
What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
I was on leave for a week and when I got back I found a new flip chart was on the wall.
Critical Success Factors when we release:
- Functionality – Does it do the job?
- Usability – Does it do it well?
- Performance – Does it do it fast?
- Evolution – Does it build smoothly on what is already there?
- Delivery – Is it ready on time?
- Comms / Training – Have we told people about it?
I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.
Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.
programme, project, portfolio
and product management
That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
According to Wikipedia: Project Management project scope is:
The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.
We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.
Typically the project scope is a subset of the scope of the product under development.