Product Owner Team - How to build a big product in a collaborative way

Category: Commentaries

Written by: Giuseppe De Simone

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and a project staff, headed by an expert project manager, coordinates everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
  • The best architectures, requirements, and designs emerge from self-organizing teams.

What do you get out of this? First that SW development is a collaborative game by its nature: there’s no meaningful problem which can be solved by one person in a time compatible with modern business needs. Secondly that self-organization and servant leadership are somehow embedded in Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: no project manager whatsoever. Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. I’m rather referring to roles and their effectiveness in an Agile context. Having said that, what I would suggest to an Agile organization is to setup a Product Owner Team, a self-organized team formed by all development teams’ Product Owners collaboratively working together. I will try to give you some suggestions based on my experience in coaching a PO Team.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog that might feed all development teams and ensure the following:

  • the whole organization is focusing at any point in time on the most important items
  • the development teams are as much independent as possible so that they can move fast with little need to coordinate with each other
  • the overall system architecture is preserved

Like any other Scrum team, a PO Team might better have a Scrum Master and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

Let’s start from the beginning: from the team setup. It is important for a team’s success to set the stage to high performance. That’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

Since I wanted to introduce Scrum in my PO team in an organic way, I let them decide completely how to organize in the first place and here below is our working agreement:

  • Global Product Backlog grooming once a week
  • Global Release Planning once a week
  • 15-min daily standup everyday
  • Review of work done at least by another team member according to our Definition of Ready
  • Team retrospective once a month

Look at this picture to see how our PO Team developed collaboratively a unique Product Backlog to feed all development teams.

We used an iterative approach: at each step we did the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders whether continue on the assumed path, change direction or even drop the development.
Given a customer request or a business opportunity, we started writing a Vision of what we were going to develop, a pitch to explain what we were going to do and why. Then we elicited requirements in terms of needs and problems to solve, together with all involved stakeholders to be sure that everyone was aligned.

The requirements were then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have. After exploring the problem domain (in order to find the right answer, it’s better to spend time finding the right question first), we made a quick architectural analysis and tried to identify a possible structure of MMFs (Minimum Marketable Features) which made sense for the highest priority requirements.

This implied again a collaborative approach with the stakeholders. If the team did not have all the needed domain competence, a PO paired up with a system architect to get some help in a high level solution sketch which could support the coming backlog preparation. At this stage, a first cost estimation was provided: relative cost estimation in story points, using as baseline the actual effort spent on the features we had developed already.

MMFs, for which business opportunity was still considered valid at this point in time, became part of our global Product Backlog.

Let’s have a look now at how to groom and order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.

To do that, I would like to tell you the story of a failure. A “good” failure indeed: one of those you learn something out!

Some months ago, we realized that implementing a new feature would have required moving to the new version of a 3rd party we integrated in our system. No big deal: they said! And everything would have been ok, except for realizing, after some weeks, that the new version of this product was not actually working with our new operating system. The result was a lot of trouble, blame games, fights, time wasted and, finally, the decision to roll back to the previous version.

What went wrong, then? The question is that requirements are prioritized according to business value, but product backlog is “ordered” instead, taking into account other factors than simply customer priority. Otherwise, what would be the added value of a Product Owner? My 10-yearsold son would be a perfect PO, if he could just follow a prioritized list given by someone else. Of course, I oversimplified the question a bit. But not too much indeed!

However, out of this failure, we learned how to groom our backlog, making use of competence and brains, not only from Product Owners, but from developers and managers as well.

From that moment on, we took into account 3 main parameters:

  • Business value
  • Dependencies
  • Risks

The PO team defines the backlog order, putting high in the list not necessarily the most valuable items, but first the ones which the others are dependant from and in many cases the riskiest ones, so that we can have an early feedback and take actions accordingly.

Actually there’s a fourth parameter which comes into play, which is cost: since the goal of a Product Owner is maximizing the Return on Investment, one could choose to anticipate cheaper features, given a certain business value.

Each MMF ordered in the global Product Backlog represents an item which can be pulled by any PO to be worked upon together with her development team and produce more detailed backlog items. Finally INVEST User Stories are ready to feed a Sprint and be transformed in a potentially shippable product increment. Pairing within the PO team, as well as collaboration with QA and Customer Support engineers, proved to help build high quality backlog items and then build a high quality product.

The cost estimation was refined iteratively, leveraging on estimation from development teams actually doing the work and a Release Plan was provided, either as scope or date first planning. The Release Plan was updated at the end of each Sprint, aggregating historical data from the different teams and possible re-estimates, given the newly built knowledge in the iteration.

15-min standup helped us follow-up the daily work on the different global backlog items and co-create a collaborative plan for the coming day, focusing on the most important tasks to allow come closer to the project goal. But all that is still not enough. A Continuous Integration of delivered stories, even during the Sprint, is essential to keep a consistent view of a unique working product, basically ready to be delivered at any time.

My conclusion is for you who think that your product is too big to be developed with Scrum. It is perfectly possible and much more effective to scale Scrum, by reiterating exactly the same patterns which make a single Scrum team successful: you know, like in fractals.

There’s no point in using overhead structures or additional roles; on the contrary, they might be detrimental.

Just try it out and don’t forget to keep always Scrum values as your compass: Focus, Courage, Openness, Commitment and Respect.