Embedded Files
First published in The Agile Zone, 11 April 2013
Scrum has simple rules about team composition. There is the Development Team plus exactly one Scrum Master and exactly one Product Owner. Due to potential conflicts of interest, the Scrum Master cannot be the same person as the Product Owner, although either can be members of the Development Team. The Development Team should have at least 3 people but not so many that it becomes ungainly and unresponsive (7 or 9 being the usually accepted maxima). As far as the rules of composition go that’s pretty much it.
Even so, applying these rules has proven to be a real headache for many organizations, especially those seeking to apply agile practice at an enterprise scale. Scrum Masters are often recycled out of Project Managers...a natural fit for some perhaps, but a poor one for those with little comprehension of “servant leadership”. In my experience though, it’s the Product Owner role which is the least well understood, and with which the greatest liberties are taken.Before we look into this, let’s review a Product Owner’s ideal job description, and remind ourselves again of what this role is meant to involve.
Wanted: Product Owner, Topnotch & Best Ltd.
Your duties will include the stewardship of a Product Backlog
You must be able to formulate a release train and understand the critical path for successful project completion
The ability to prioritize requirements and authorize them for Sprint-based, iterative-incremental delivery is essential
You will fully participate in Sprint planning, reviews, and retrospectives with Development Team members
You must be able to understand business requirements, and explain their value to Agile team members
The ability to explain the acceptance criteria for each piece of work is important
You will be expected to determine whether or not completed work is fit for purpose, and to either authorize its acceptance, or reject it and replan the work accordingly
You will demonstrate excellent customer-facing skills, including the ability to elicit functional and non-functional requirements, and balance competing demands from multiple stakeholders
So how does this idealized view match with the reality of Product Ownership? Let’s look at some of the product ownership “antipatterns” that have been known to surface, and which will be chillingly familiar to many.
Product Ownership Antipatterns, or a character description of the PO from Hell
Trying to reprioritize the work that a team has committed to in a Sprint. It is up to the Development Team to self-organize in such a way that the delivery of a potentially releasable increment is facilitated. As long as that increment was agreed with the Product Owner at the beginning of the sprint, and is available at the end of the Sprint, he or she shouldn’t care how the team set about creating it.
Trying to unilaterally add or remove content of a Sprint Backlog after the team has committed to its delivery. The Development team wholly own their Sprint Backlog. In agile practice, no-one has the right to change a team’s Sprint commitments without their say-so. If essential additions or removals from the backlog must be made after a Sprint has started, then they must be negotiated with the team, if necessary by trading other work out and redefining the Sprint Goal accordingly. The other option available to the Product Owner is to cancel the Sprint and work with the team to replan an abbreviated one for the remainder of the Sprint timebox.
Dictating, or trying to overrule, the estimates that a team provides. A Development Team is wholly responsible for forecasting and estimating how much work they are prepared to commit to in a Sprint.
Interfering with the Development Team’s ability to deliver on their Sprint commitments. This can include pestering them for status updates or attempting to micromanage them.
Deferring business decisions to the Development Team. The Product Owner is the sole arbiter of business value in a Scrum project and has the responsibility of prioritizing and explaining business requirements to them.
Expecting the Development Team to plan beyond one iteration. Although the advice of the team can be sought regarding future matters of technical delivery, they can only be expected to forecast their deliverables for the currently planned sprint. It is the duty of the Product Owner to produce a meaningful longer term plan (such as a roadmap or release train) for the sustained release of business value.
Transparency is the first step in any agile transition. If you can at least recognize problems such as these you’ll be in a position to start dealing with them. After all, an issue that has been acknowledged is somewhere on the way to being solved. But getting effective product ownership often has to be seen as a medium to long-term goal...it doesn’t usually happen overnight. Compromises may have to be made in the shorter term while more appropriate qualities of product ownership are gradually encouraged.
One compromise that is often made is product ownership by proxy. This happens when the person best suited to be the Product Owner is unavailable due to other commitments, and one or more stand-ins have to be resorted to. I make special note of proxying here, because it can involve the horse-trading of critical and/or senior personnel. Also, the politics involved can make it a long-term (if less than entirely satisfactory) arrangement for a project.
Product Ownership by Proxy
A Proxy Product owner is a stand-in for other stakeholders in whom real product ownership is somehow vested. Proxying can take several forms. Here are some examples:A supplier might provide a proxy as part of their service to a customer. This proxy represents the client’s interests to the development team. Product ownership rests with the customer but the proxy is authorized to act on the client’s behalf regarding operational matters. Decisions of strategic import may be deferred to a suitable representative from the customer side (i.e. the “real” Product Owner).
A Product Owner might be too busy to effectively represent the all of the systems they value. Due to a number of competing commitments, the Product Owner cannot do justice to all of them and must therefore authorize delegates to act on his or her behalf. This is a common occurrence in enterprise systems at scale, where senior managers have budgetary authority over diverse and strategically significant portions of scope, and are responsible for the successful delivery of major system components.
There may be multiple customers being served by the same product. Each has a Product Owner who is too busy to represent their stake in the product, and a Proxy is required to arbitrate between them and the Development Team. This model is an especially tricky one because each Product Owner must cede a measure of authority to the Proxy, and thereby potentially compromise their own immediate interests. These Product Owners may be tempted to withdraw (or threaten to withdraw) funding in an attempt to sway or coerce the Proxy. In effect the Proxy must have the executive authority of a senior Product Owner, and must be respected enough by the other stakeholders so as not to be undermined.
The product may represent the interests of different stakeholders within the same organization, all of whom consider themselves to be Product Owners, but who do not have the time to represent their interests. This is often the case at enterprise level when a number of existing systems are being rationalized and replaced by a common architectural component. The proxy must act on the behalf of senior stakeholders, somewhat in the manner of (3) above. Clearly the proxy’s job will be made easier if a shared budget has already been been agreed and capital has already been furnished by the various parties.
The product may represent the interests of different stakeholders, all of whom do have the time to represent their interests to the development team. This is common in small to medium size organizations where managers have not absorbed responsibilities over truly enterprise levels of scope. A senior Product Owner is found (such as a senior manager) who can arbitrate between them should matters of contention arise. Each stakeholder effectively proxies for that senior Product Owner at an operational level and with a particular area of focus. Discipline is needed so that proxies defer authority to the Product Owner instead of manoeuvering and bickering amongst themselves.
The product may represent the interests of different stakeholders, all of whom are very busy but nonetheless still find the time to be represented. This situation can emerge in enterprise projects where the product is of such strategic or political importance that “real” Product Owners clear their diaries and make themselves available. Again, a senior Product Owner (possible the CIO) will be needed to arbitrate between them and a great deal of discipline is needed so that bickering and political manoeuvering is avoided.
It can therefore be seen that Product Ownership is a potentially complex phenomenon, although it can be reduced to either a single proxy or multiple proxies facing the team (see illustration). Of course, a very strong argument can be made against such complexity. It can be argued that unless a simple, direct, and effective model of Product Ownership is negotiated for a project, then the risks are too high for that project to be authorized. A direct line of control from a single team-facing proxy to a single or shared absentee Product Owner might just about be acceptable, but that would be the limit of any compromise on product ownership. Adopting a risk-driven position such as this is quite defensible in terms of agile practice, and also within the context of industry frameworks such as PRINCE2.
Unfortunately, this hard-line tack is often unsupportable in practice. Organizations, especially public sector and enterprise-level ones, always have new projects to do, existing political and business constraints in place, dysfunctional practices and cultural norms, and a misty-eyed goal of transitioning towards a more genuinely risk-driven and agile way of working. They just aren’t there yet. Although it may sound like a platitude, the fact is they are where they are, and every agile transition has to start somewhere.
This is where compromises are made, and why. In my experience these compromises are especially common around product ownership...even more so than the old chestnut of “who should be the Scrum Master”. The reason why product ownership is so abused should be clear from the above. Product Owners often hold the purse strings of projects, or represent the customers who do. Just follow the money, and you will soon find these competing interests and agendas, office politics and empire-building, and the sometimes quite bizarre priorities that managers set for themselves and others.
Page updated
Google Sites
Report abuse