Invest in product owners to drive agility at the business level

The Product Owner is often the most understated role in the agile/scrum methodology, especially in organisations which do not have technology or IT as a core business. In fact, my personal observation is that, organisations that are failing to realise the benefits of seemingly entrenched agile development methodologies are the ones which fail to emphasise the role of a product owner.

Before switching to consulting, I worked for a long while in product development where the product owner played a very significant role in creating a vision for the product or the organisation; in connecting strategy to development; and in keeping delivery continually aligned to strategic goals. Within organisations that do not have IT as core business, the scene is unfortunately very different. Business owners aren't usually from a technology background and the arduous task of bridging between business and delivery teams is done by a cohort of business analysts and scrum masters. Sometimes, it is even difficult to identify a single person as responsible for end-to-end delivery.

My personal experiences as a product owner

Formally, I have been product owner twice. The first one was for engineering tools across Nokia Siemens Networks (now Nokia) where my focus was mostly on demand management, long-term road maps, vendor management, prioritisation and ensuring end-user (customer) value with every release. I was like a business owner working with product vendors, vendor development teams, project managers and architects to deliver value without the luxury of daily interaction with the development team.

In my next product owner stint, I looked after strategic improvements to automation tools where I spent a lot of time evolving a roadmap for refactoring our legacy toolset to make them modular and agile. I was very much hands-on, had architecture responsibilities, and was working closely with the development team to overcome technology and design challenges.

As a consultant scrum master, I often find myself wearing the product owner hat to fill gaps in roles and responsibilities across the delivery value chain. Although every role has been different, I have come to value some aspects as vital for effective product ownership

Creating a strategic perspective of the backlog

The backlog is an operational representation of business value waiting to be delivered

In agile/scrum definition, the product owner owns the product backlog, which is often defined as a prioritised list of features or stories to be delivered. This over simplified, one-dimensional view of the product backlog and the depiction of the product owner as a janitor has often diluted and downgraded the true potential of the role. At times, it gets reduced to a set of backlog management tasks that are eventually picked up by someone who has a bit of extra time on their hands.

In my view, the product owner role bridges business strategy to technology delivery. It connects business needs to technology requirements, facilitates teams to deliver technology artefacts, and finally ties back these artefacts to create enablers for business outcomes. 

The backlog is an operational representation of business value waiting to be delivered. There is a business purpose to the value and there are strategic outcomes to be achieved by the realisation of features in the backlog. If there is one person who can articulate the various dimensions of how the backlog captures product or organisational ambitions along with the value propositions of the items in the backlog, it must be the product owner.

Develop product ownership skills

If you have been thrust into a product owner role -- by design or by chance -- it is only fair that you develop the required skills to perform the role. So, what are the most basic skills?

Creating an initial delivery plan

The product road-map is often used to represent a high-level view of how we wish to deliver value over a long term to enable strategic outcomes. At this level, it is often just an understanding of which initiatives, from a bunch of competing ones, could potentially provide the most value.

Discovery and elaborations provide the next level of detail where initiatives are broken down into features or detailed stories. Estimation provides an understanding of the size of the backlog. Prioritisation at the story level suddenly provides the ability to slice and dice at the level of features so that critical portions of competing initiatives from the roadmap could still be accommodated.

A multi-dimensional backlog of releases, features and stories that are already estimated and prioritised is the ideal foundation for successful program or project delivery plan. The "responding to change" bit in the agile manifesto allows for business prioritises to effect changes to the original plan - the reference to the plan implies that it is good to plan and even better to change plans to respond to change.

Managing scope

Managing is not a one-time activity, it is a continual process of keeping things under control and requires active engagement

Of the trio of cost, quality and scope, cost is almost always fixed with some allowance for variance; compromising on quality is tantamount to hara kiri; which leaves us with scope as the only reasonable option to manage.

Managing is not a one-time activity, it is a continual process of keeping things under control and requires active engagement. A good product owner manages scope at different levels. Thin slices are used to make features just big enough to deliver meaningful value to the customer. Bigger features can be broken down into multiple thin slices to provide value in an incremental manner. 

Scoping features into releases is an even more important activity. Good product owners use velocity metrics to predict release capacity and then work backwards to descope features based on priority. 

Early clarity of requirements

Assumptions are the biggest threat to product quality

Assumptions are the biggest threat to product quality. Once engineers begin design, coding and writing tests for a story, having to go back to the analyst or subject matter expert to verifyinassumptions, it takes away precious focus.

The "definition of ready" is often used to ensure that requirements or stories have been elaborated to a required degree of detail before development is started.

I have observed that the projects with the quickest turnaround are often the ones where stories have elaborate detail. Even with dependencies, the information the team needed from other teams were defined and captured, so the team wasn't kept waiting.

Ensure operational alignment to delivery

Who would be the best person to ensure that delivery teams stay aligned to the delivery goals? Even when there is a division of responsibilities across project managers, scrum masters, business analysts and area product owners, the product owner role must stay in charge of tracking and aligning delivery teams to the overall release plan.

To achieve this, the product owner would need to carefully choose what information or metrics would need to be aggregated across different teams.

Track release readiness

Experienced product owners pay attention to the acceptance criteria or the definition of done to ensure that non-functional requirements as well as release-pertinent information such as training inputs, architecture & design documentation updates and business readiness information are captured as part of the stories along with story development.

Closer to releases, defect prioritisation and scheduling becomes another important responsibility for the product owner. It is often easy to neglect defect management, albeit it is a potent tool to keep team focussed on important release goals without being distracted by a large number of minor and insignificant bugs that may not deliver immediate value.

My personal experience is that a dash of release management rigour is all it takes to recover a seemingly impossible delivery and incrementally provide value to business.

Understand the delivery value chain

Agile/lean delivery is not just about the backlog, it is also about orchestrating a diverse group of people working on a value chain that transcends teams, roles, processes, tools, skills and capabilities. The biggest boost to delivery comes from the product owner assuming ownership of the end-to-end delivery pipeline. This is where minimising inefficiencies and ensuring consistency creates release cadence which in turn provides business teams with improved delivery assurance.

Left shift root causes of rework

Teams often evolve their own way of working specific to the organisational environment, team structures and access to skills. Identifying causes of rework and rectifying them at the source goes a long way in creating predictability and cadence.

As a very simple example, using low-fidelity mock-ups for early showcase of user interface screens can often prevent rework due to form field names and help texts. Rework not just creates additional work, it also reduces focus.

Maintain balance of power

I know this would sound controversial and going all out against the empowerment provided by agile ways of working. Nevertheless, let me put it out there. 

There is a certain skewed balance of power between an "owner" and a "master". In a larger systems context, the parts need to be serving the whole, which means the teams have to be delivering value to the owner and must be answerable to the owner.

In that context, agile coaches or delivery coaches must be aligned with and ideally even be accountable to the product owner to ensure that technical agility drives business agility. 

Again, if the product backlog is a collated backlog from multiple initiatives, the product owner role should be positioned at the appropriate level to facilitate prioritisation and decision making across all the initiatives. This is required because the product owner is not meant to serve a single initiative, he takes care of overarching business priorities across multiple areas.

Product owners play a central role to harness the technical agility of teams in order to provide business agility. If your organisation is struggling to help realise the benefits of agile ways of working, it is worth looking beyond agile coaches and starting to invest in skilled and empowered product owners.