Product Owner: the things they often don’t mention
Do you really have a Product Owner on your project?
Having an effective Product Owner (PO) on software development projects is a hugely useful and important role, whether using Agile or other methods. The way the PO is described, especially by many promoting some Agile methods, is ambitious. In some circumstances, it may not even be close to possible. Pretending we have one when we don’t (by the measures below) is not going to be successful.
The purpose of this post is to hopefully help you decide whether it’s as simple as many would say.
|The Product Owner Role (as commonly defined in Agile methods)|
|Note: none of the following relates to “classroom” or “text-book theory”. It reflects real world human challenges, behaviours and issues that are commonplace around projects. These challenges, if not recognised and properly overcome can wreck any project very easily.|
|Product Owner Responsibilities:||Implications:|
|How it’s usually described|
|Are accountable for a successful end-product.||It's odd that the PO owns the definition of what is required and developers produce the product, but in the most common Agile methods they have no accountability for the success of their efforts. This is highly convenient for all of those who are not the PO, including the Scrum Master, who is only responsible for the “process”.|
|Define the product vision.||This is a task most people are not skilled to do. Many who are asked to do this may never have done it before.|
|Describe required product features to development team.||Doing this well will take a good deal of time and requires the skillset to do this successfully.|
|Prioritise the product backlog.||Done properly, this is a heavy responsibility and will often require a good deal of time.|
|In reality: the bits often not said.|
|Communicate, as required, with all key stakeholders.||This is a hefty responsibility time-wise in many instances.|
|Resolve conflicts among stakeholder needs.||This can be very challenging, to the extent that people sometimes will ignore this challenge rather than confront it. It takes personal qualities of a particular kind to do this well and maintain momentum towards a successful project. That relies upon time to communicate well during this process and the skills and resolve to do this.|
|Conduct trade-off analysis as required (e.g. scope and schedule).||This one is very challenging. It frequently occurs around issues often with zero notice. Two key questions occur: does the PO have the time to do this (well) and how many POs would or could do this, even with significant support from the team.|
|Attributes of a successful PO||These are the bare minimum attributes:|
|One Person: Not a committee.||Committees can exist but the PO is the focal point for the team. All other stakeholders should make their representations via the PO. This places great responsibility on the PO and requires a significant commitment of time by the PO over the whole life of an Agile project.|
|Availability: No 1 attribute is that they must be available to the team, before and throughout the development process (iterations), for planned events and often at short notice. Many of the responsibilities described above carry a heavy commitment of time.||Some try and focus this availability around Sprint planning. This is unrealistic. Most iterations (e.g. Sprints) involve development of the detail feature requirements, within the iteration itself. The PO must be available to do this or coordinate with those who will do this.|
|Domain knowledge: They must be able to make decisions as quickly as possible over priorities and functionality. Having to refer to others constantly will hamper progress significantly.||This makes your choice of PO quite limited in many cases.|
|Authority: They must have authority to commit to decisions about the product, constantly. Those decisions must be respected by all other stakeholders.||They have to be able go make many decisions even on behalf of whole committees. They cannot constantly refer to others or progress will stall or even stop.|
Conclusion:Having a participative, knowledgeable PO with the authority and time to do all of the above is priceless on any project (whether using Agile or not). However, you have to ask yourself, on a case-by-case basis, do we realistically have one (with the substantial amount of time that will be required across all iterations). If there is any significant doubt around this question it could be very foolish to attempt to use Agile development methods or a team model based on Scrum alone.
If you agree with any of the above you may find the following pages useful:
Contact Us Now
Email us today to find out more on how we can help you.