Many organisations choose to apply the agile values and principles because they want to achieve higher alignment with their business counterparts, increase their chances of delivering validated value in a time frame that works for them. Unfortunately for large or growing organisations achieving this becomes increasingly difficult due to their inability to overcome or avoid some of the most common antipatterns:
Managing, not eradicating dependencies, the effect of which is:
Increased time to market
Confusing leadership with management, the effect of which is:
Lack of Servant Leadership
Teams being unable to be truly autonomous
A culture of individualism
Focusing on bilateral relationships rather than nurturing an effective system of relationships, the effect of which is:
Destructive political activities
Lack of a shared understanding
Quid pro quos rather than doing the right thing for the organisation.
Traditional organisational thinking is not equipped to deal with the volatile, uncertain, complex and ambiguous world we find ourselves in. The effect of this is that we continue to create and avoid solving the causes of these systemic problems, unconsciously choosing to resolve the “burning platform” symptoms and rarely the underlying causes. This leaves the symptoms to return another day and forever hinder our progress if we desire an adaptive organisational with ever-increasingly capable & engaged people.
When these issues are left unsolved, making large organisational decisions slow down and the effort to enact those decisions snowballs, slowing not only their time to market but also the ability to innovate and re-prioritise effectively.
What is the result? We are inhibited from harnessing the true power of agile by being able to outmanoeuvre the competition through harnessing change as a competitive advantage.
It has been my experience that the antipatterns I mentioned above and the growing pains that organisations experience when trying to make use of agile at scale can be traced back to the one role, that at least on paper, could have a significant impact on making them great: The Product Owner!
The great news is that all of these issues can be dealt with by taking another perspective of the role of Product Owner, one which aligns to its original sentiment.
True Product Ownership at Scale
In the Scrum guide (the framework that defined the role originally) it says, “The Product Owner is responsible for the Product Backlog” and that “Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.”. All seems clear so far that we have:
One Product Owner per Product Backlog
The Product Backlog describes all of the upcoming work on that Product.
Now let’s move onto the really interesting part, “The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints…TheSprints. The increment must be in useable condition regardless of whether the Product Owner decides to release it.” and “Only members of the Development Team create the Increment.”
What this implies is that:
The increment must be usable and be integrated with all previous work
The Development Team have no dependencies on any other team as it is only members of that team that create the increment
Sadly applying this logic was not something that was explicitly asked in the Scrum guide and not something which many people seem to discuss, perhaps this is why within many organisations, you can often find a plethora of people enacting the role of “Product Owner” and there is no redesigning of the organisation to eradicate the dependencies between the teams.
When there are so many “Product Owners” how can you ensure that all of them are aligned on the highest value items from the company’s perspective?
How can you ensure that all of these people independently ordering their own (usually single team) Product Backlogs are doing it correctly (assuming they can) without adding additional roles, complexity and value detrimental expense?
Let’s try and answers these questions through the lens of the antipatterns I have already detailed above and at the same time give you some practical advice to help you achieve game-changing success:
Managing, not eradicating dependencies
First and foremost, the word “Product” is very widely used and defined (or not defined) with a huge degree of variance in the agile community. To this end, I propose that searching for a strict and unifying definition of what the word “Product” means to every organisation is a folly. I suggest that we think of “Product” as a mental model of something meaningful to our organisation, a model that we can adapt and evolve as our organisational context and goals change.
All models are wrong, but some are useful
One of the major benefits of thinking of “Product” as a model is that we can accept that it will never be correct (as no model ever is) and instead we can focus on how creating a model, through many conversations. If done in specific ways it can act as a catalyst to the organisation in achieving its goals, through the ability to:
“Identify and work upon the newest high-value item, changing direction to work on these items quickly and with low cost”
But what, I assume you must be thinking, has this got anything to do with dependencies?
For an organisation to model it’s “Products”, to achieve the above goals they have to eradicate the dependencies between teams and “Product Backlogs” (to enable teams to be motivated by high-value work) and as a consequence reduce the number of places (queues) where the work resides so that an increasing number of items can be relatively prioritised against each other (helping to always identify the highest value item).
As a Product Owner, you should be in a position to drive the consolidation of Product Backlogs that may have popped up as you have grown, to eradicate dependencies and help your organisation thrive.
Confusing leadership with management
The desire of individuals and organisations at large to tie seniority and leadership to the management of people is all-pervasive, seemingly regardless of industry.
The consequence? Organisations with many “Product Owners” often (and arguably at the detriment to their dreams of agility) place them all in a hierarchical structure. Those at the top feel like they have been rewarded with a position of leadership and more than likely a prefix to their previous role such as “chief” of “lead”. In reality, they spend too much of their time managing their subordinate “Product Owners” (and commonly some roles with the word “Analyst” in them) along with all the bureaucracy that goes along with it. This responsibility takes precious time away from the Product Owner being able to enact their role, creates relationships that could potentially hinder their ability to make hard prioritization decisions (as this may affect the people that report into them) and can limit their ability to grow others around them as a Servant Leader.
Ann McGee-Cooper & Gary Looper, Pocket Guide to Servant Leadership
To be a Servant Leader is to serve first, create space and allow people to contribute towards and be responsible for (some) decision making. So how does that manifest if we think about the role of Product Owner? What does ‘serve’ mean in this context?
Educating others on the product, its users, customers, market forces et al.
Coaching and mentoring the team on soft skills that will help them build stronger relationships with users.
Getting out the way so that the customer can lead the development with support from the development team/s
Letting people experiment with a fresh product or technical ideas and innovations that can help drive the product
Letting development teams and users fail safely and learn quickly to enable growth in them and the product
Doing all of this by working with others to create a high trust, psychologically safe environment where teams can come to a decision and act upon it
Servant leadership is a must-have for the most successful Product Owners. When you want agile at scale to succeed, the capability of everyone to understand what is valuable and work together to create it needs to grow. This will dramatically increase the chances of the right product decisions at the right times without having to wait for direction or approval.
Focusing on bilateral relationships rather than nurturing an effective system of relationships
In a successful, collaborative environment it’s never about the intellect or experience of a single person, it’s about nourishing, trust-based relationships that create systems that work reliably at meeting their evolving goals.
But when organisations increase their number of people, they will also increase the need for effective, trust-based relationships to enable productive group and peer to peer conversations. But whose role is it to do this? Being an effective Product Owner at scale means taking some responsibility, in five specific areas:
Your relationship with Higher Management
These are the people who may be funding your product and/or setting the strategic direction for the organisation. Without a trusting and respectful relationship with them, you will struggle to grow much further.
Your relationship with the Customers, Users, and Market
As a Product Owner, you have to set the direction for the Product, you cannot do this without maintaining relationships with your customer, users, and market.
Your relationship with Scrum Masters and other Coaches
They are there to help you achieve your goals using the framework you have chosen. They are also there to help you to hold yourself accountable for goals you have set. Also, they will advise and teach you when required so that you can maximise the product’s return on investment.
Your relationship with Teams creating your product
If there is no mutual trust between Teams and the Product Owner then, as a Product Owner, you will likely feel a desire to always be in contact with the team which potentially creates an atmosphere of micro-management. As there is no trust the motivation of the team will drop and the assumption of negative intent that comes from a trust void will reduce their willingness and ability to self-manage.
And finally, the most overlooked and challenging relationship (say for Proxy Product Owners) is the team’s relationship with the users and customers.
In a large organisation, you cannot be the Product Owner who has to be the middle person between teams and those receiving the Product as you simply will not have the time. And if your desire is agility then without this relationship you will never achieve one of the most impactful Agile Principles:
“Business people and developers should work together on a daily basis”
Without these relationships being nurtured on a foundation of trust people will create mechanisms such as reports, new roles to act as proxies, a proliferation of new meetings, gatekeepers and extra bureaucracy. This increases the organisation’s complexity, reduces adaptability and debilitates the role of Product Owner.
Organisations struggling to take their agility and organisational adaptability to the next level, I believe, would benefit greatly from using the perspectives and advice I have outlined if it resonates with them. This will involve addressing misunderstandings their organisation has about the Product Owner role and defining a model of product that accelerates their progress towards their organisational goals and greatness. It won’t be easy and at times it may seem futile, but no large changes ever come without courage.