Derk-Jan de Grood is an Agile transition coach at Squerist. He’s supported organizations like ING Bank, RTL, DPD, Nationale Nederlanden and Greenchoice in their Agile transformation. He’s also an experienced trainer, workshop host and regular speaker at conferences. On his blog, he shares his knowledge and experience for everyone to benefit. This year, he published his 8th book, “The waves of Agile,” which deals with value delivery in medium and large organizations.

16 November 2021

For many years, Derk-Jan de Grood has regarded the ability to say no as one of the most important skills of a good product owner. The power to say no seems to be an indication of product owner maturity. But that’s not the end of the story.

The advantages and mechanisms making single-team Scrum effective are challenged when applied in larger organizations. There, we often see that new epics and features are pre-determined by programs and scopes defined outside the product owner’s span of control, and short-term intitiatives interfere with longer-term planning cycles. Product owners need to grow in their role and take ownership. The more mature they get, the better they operate in the complex, multi-layered environments of larger organizations.

Product owner maturity

There are several models of product owner growth. In my book “The waves of Agile,” I follow Robbin Schuurman’s article “Growing as a product owner: five product owner maturity levels.” These five levels are: scribe, proxy, business representative, sponsor and entrepreneur.

The scribe administers the product backlog, collects the wishes from the stakeholders and translates them into user stories for the development team. He has no to very limited authority.

The proxy has the authority to make (limited) choices in the ordering of the product backlog. As the vision and the business goals are determined by other people, the proxy has to ask for approval to change the priorities, planning, roadmap or backlog.

 advertorial 
Benelux RF Conference 2023 - PhD pitches

PhD pitches at the Benelux RF Conference

Learn about the latest trends and developments in high-end RF techniques. On 24 May, the Benelux RF Conference will take place in Nijmegen. New this year are the PhD pitches, in which young professionals present their research results. Make sure to reserve your seat in time and register now.

The business representative has connections to customers and/or users. He has the authority to manage the product backlog but doesn’t have a budget to spend as desired. The business representative has to work on projects/goals that are defined by others.

The sponsor has control over his own budget and can scale up the team. He has a bigger say in what needs to be done. The sponsor can define the work to be done, the projects to perform and the business goals to achieve.

The entrepreneur takes full responsibility for and has full authority over the product. With a strong vision on the market, customers and the product, he takes responsibility for the profit and loss and for maintenance, operations, marketing, legal aspects and sales. The entrepreneur has his own ‘mini-company.’

Product owners who act as a scribe or proxy have limited control over both the product and sprint backlog. When new items are added (not seldomly during the iteration), they have to put up with it. Growing in their role, they start to take ownership of the backlog. They learn to make a stand and not always accept new requests from the business. They take pride in being predictable and protect the team from scope creep and adhocracy. Product owners acting as a business representative have the authority to manage the backlog. With this also comes the authority to say no to work that doesn’t yield benefit for the release or may delay items other teams rely on.

For many years, I’ve regarded the ability to say no as one of the most important skills of a good product owner. The power to say no seems to be an indication of product owner maturity. In organizations entering the second wave of Agile, we’ll be hearing no a lot more often, but that’s not the end of the story.

The waves of Agile

In “The waves of Agile,” I write that many organizations start with a strong team focus. In the first wave, a lot of attention goes to the team basics, and product owners can get away with being a scribe or proxy. Recently, I had a nice session with the Product Owner Guild of a large financial enterprise. We reviewed the Agile waves and discussed how these impacted the work of the product owner. We agreed that organizations that progress on their Agile journey face new challenges. As the teams get up to speed, the focus shifts towards cross-team collaboration.

When organizations enter the second wave, product ownership requires a higher maturity level, eg that of the business representative. The second wave is characterized by a strong focus on cross-team alignment. Work needs to be prioritized and divided over multiple teams; solutions need to be integrated into a working release. Product owners need to collaborate with their peers to manage cross-team dependencies.

This requires more planning and better prioritizing, often supported by quarterly planning cycles and road maps. Product owners need to take the business value of the separate user stories into account but also have an eye for the bigger picture. A less valuable item for one team can be key to completing an epic for another team.

When organizations progress on their Agile journey, product owners need to take more ownership. They can’t always follow the whims and impulses of the business. The authority to say no is a necessity to keep focus and commit to the release goal.

Waves of Agile yes no yes and

More flexible

Organizations that have mastered the art of frequently releasing enter the third wave, which is characterized by a strong focus on business value. Third-wave organizations need sponsors or entrepreneurs with a strong focus on keeping the business running.

Recently, I had a discussion with a department head. “I have a business to run”, she sighed. “But whenever I discuss new items with the product owner, I hit a brick wall. They’re taught to adhere to the release goals and be predicable on their epic completion. But don’t they understand that when they say no, they put the weight on my shoulders?” She wished the product owners in her team were a little more flexible.

That’s an interesting wish. In this organization, the product owners come from an informal and unstructured background, and have learned to think in product visions, road maps and release plans. They’ve scaled up from independent teams towards release trains and learn to strive for collectively set goals. When these are threatened, is there a better answer than “no”?

Saying no is an essential way to remain focused on goals and epic completion. But when the organization moves forward, more is expected from the product owner. Saying no might also mean that you say no to taking true ownership of the product. What would you do if you were the CEO and people depend on you? Would you try to find a solution or just ignore the problem? “No” might not always be the best answer to give.

Yes, and…

In the third wave of Agile, flexibility is required from both the product owner and the business. Product owners are expected to take ownership of their business and product. The entrepreneur, or mini-CEO, can’t ignore demands made by the market and customers.

“There are more answers than yes or no,” the business manager stated. “I’ve been taught there’s always a third option.” New items may be split to make it easier to fit them into the planning. Existing items might need revision as well. This requires flexibility from the business, to not want it all in one go. It may mean that you must wait a bit longer than expected, since other items get more priority. It requires flexibility from the product owner and the team to revise the business case and the user stories. It requires time and effort to redefine the items.

The answer shouldn’t be a single “no” but a more balanced “yes, and…” “Yes, and we postpone user story X.” “Yes, and we redesign this function and implement half of it later.” “Yes, and we start by investigating if the damage outweighs the benefit of the planned items.” “Yes, and we need… to make it work.” In organizations that move beyond the second wave of Agile, we’ll be hearing “yes, and…” a lot more often.

Edited by Nieke Roos