The Gatherer mainly focuses on gathering as much information/feedback from stakeholders as he can. This helps him build a direction for the product for a specific period of time. Although he gets new requirements, features and requests, he strives to keep the direction steady and aligns new requirements to it. Together with the team, he prioritizes the backlog consequently. This helps him ensure that the direction is clear to the team.
The Gatherer keeps a personal log for all the possible long-term features that could be implemented in the product. He notes everything down regardless of whether the come from from customers, or by comparing with other similar products in the market. As soon as one of these features is barely considered valid for implementation, adds them to the product backlog and discussed it with the team.
He insists on frequent grooming sessions; they keep everyone in the team informed and mentally prepared for the forthcoming tasks. Moreover, grooming sessions keep the backlog clean and optimised, since most of the old issues would have been already solved and need to be deleted or rephrased.
The Gatherer always tries to keep the team involved. At the regular meetings with customers, he usually summarises the notes and shares them with the team. Likewise, he tends to convey the feedback from stakeholders (positive or negative) about the development process, the quality of deliverables, and their expectation to the product and the team.
As a Product Owner, he believes in the role as responsible for defining the product path. That is of course after analysing requirements, business needs and use cases. He has established a strong relationship with the customers, based on mutual trust and sending a clear signal that he takes product ownership seriously.
This post concludes the series about different flavours of a Product Owner.
What makes us unique as Product Owners?
What defines and characterises each of us?
In the coming weeks, we will try to characterise how we are different as Product Owners in our organisation in order to highlight the quality of variety. By identifying our differences we can work better to support each other – something which is easy to overlook outside the traditional scrum team configuration.
Whatever your title, I’m sure you do your job differently than anyone else with that title.
What you focus on is the result of a combination of things: varying expectations (from boss, colleagues, self) or a preference for some specific tasks – probably those where you experience success more often.
Sometimes, you place your focus where you feel the need to improve.
Most important of all, you contribute where you feel your contribution is valuable. If there’s an unoccupied space that you think it would make sense for you to step into, you do it. You claim ownership of that space and do your best with it because you feel it’s the right thing to do at that time.
As a Product Owner in a truly agile organisation, you get to make a choice about where you want to place your focus at any given time and provide value to someone. One minute you are working within a development team and the next you are aligning with a customer, trying to make more sense of what value they are actually looking for. To build a useful network and gain more understanding of the product in full, you spend time in the server room with an admin installing hardware and deploying software.
The above tasks are all vastly different aspects of crafting software. All of those things need to be done to make it in our game, but nobody expects anyone to do all of it. That’s why we work in teams.
We are currently 5 Product Owners working with each our product. Some products have overlaps and collaborative opportunities. Others don’t. Regardless, we can use each other and our differences to become better at our jobs and create better products.
Working in a team doesn’t apply only to developers, testers and devops:
That is why we are trying to be a team of Product Owners.
In forming ourselves as a team, we have discovered that we have vastly different interests, skills, experience and focus, which we can use to help each other and deliver more value, faster. Just like a team.
To get an idea of how we complement each other, we are working with identifying what makes us unique as Product Owners; what defines and characterises each of us. In addition, it’s also an attempt to show that none of those unique qualities are better or worse than any other. Rather, it’s to encourage that everybody benefits from us working as a team.
The Visual Product Owner has an ability to put himself in the users’ place. He thinks visually and spends time generating ideas and designing an experience for the user. This makes it easier for him to communicate the value to the team.
He has a challenge: suggestions for implementation can easily be construed as dictating a solution to the team, so he has to ensure that the experience he designed in his mockups are perceived as suggestions from someone who cares intimately about the product.
He spends a lot of time producing social glue and listening to what the team says about priority and product. As a positive side-effect, he is included in the team to a great extent.
To ensure there’s no doubt about responsibilities, both he and the team sometimes address him explicitly as “PO” when a Product Owner decision or opinion is required. His personal opinion is not always the same as his professional Product Owner opinion, particularly when it comes to prioritisation.
When working on the backlog, he looks through what is in the top third-ish and make sure that each user story has a clear description of value using the syntax:
In order to <value>
As a <stakeholder>
I want <feature>
He looks only as far in time, as he can couple with events in “real life”, with the reasoning that: “If I don’t know what I am doing in my spare time 3 weeks hence, it’s likely to change anyway”. It’s the same with the product backlog. Things beyond the structured top of the backlog are constantly subject to change.
Epics are used as a tool for grouping. The groups can be prioritised and the priority of the epics help when working on the backlog. User stories from different epics can easily be worked on at the same time. The epics are more a tool for managing stakeholder expectations to when delivery of specific work is planned.
Next week, we’ll look at another flavour: The Inquirer.
tl;dr Make sure to talk about why you do the work you do and what the value of said work is.
Historically, we have had several teams working on separate components (stand alone products at the time) for one of our products. The choice of organising in component teams was natural evolution of people’s interests, how we group in the offices and how the separate products grew, before turning into components for a whole product. It might even be a related to Conways Law.
Now, as these components are merging into one single product, several pains are now manifesting.
The obvious pitfalls with component teams, like communication on related work and integration testing was handled as best as we could. To minimise the impact of these pitfalls, we tried to coordinate between teams so that related Stories were being worked on at the same time; Hopefully minimizing how much we impede each other and our turnaround time on issues found. Unfortunately, this approach took control of the work to be done away from the teams, and still duplicate work and uncertainty about responsibilities was prevalent.
Previously, much of the work being done has been described with a focus on the functionality (the what) and technical solution (the how) and more often than not, the value (the why) provided would slide into the background. We would all sorta – kinda know why, but our conversations tended to be more about the how. This approach has worked well with component teams, as the tasks describing changes to the components were technical by nature – with focus being on the what and how. But this does not invite discussions about the why.
We would like to increase visibility of the value we deliver and foster discussions about the why. An important step in doing so, is actually talking about the value of the work we do. When we talk value, we talk about it in the broadest sense. We ask questions about the kind of value a given Story adds or subtracts. Does it add value for the user? How about the customer? Could the perceived user value could be achieved in another way? How about the strategic value? Does that influence the customer value? All valid questions and the conversations stemming from these is what we want to have more of.
The introduction of the value-driven Stories did not happen overnight, but it has been a gradual shift in how we talk about the work we do. An interesting side-effect of the value-driven Stories is that it became natural to talk about Stories across the product without being specific about each component. So how did that work with our setup of component teams? The flow for a value-driven Story ended up looking something like this:
“But wait”, the observant reader objects, “is a component story then really a value-driven Story?”. No, no it is not. The component Stories are more like technical tasks.
I’ve touched on some of the pains we were experiencing with component teams. Given these pains, we had known for some time that feature teams would be an interesting change. But the final push came from the move towards value-driven Stories. In the above model, the conversations about value were happening between all of the involved people when discussing the product as a whole. But as the component stories were about the what and how, the conversation died in the day-to-day work for the teams.
So we started a journey towards feature teams. For us, feature teams mean that all teams are able to commit to a Story from the backlog and handle work responsibly across all components. We have only taken our first steps on this journey and there are still lots of quirks in how we organize around the feature-driven Stories. We have already had the first wins, like the teams aligning on various agreements around the whole product, such as quality and Definition of Done. It has also fostered communication between teams, as each team has limited knowledge about the other components.
But most importantly, we are now having conversations about why we are working on a Story, and what the value is, on a daily basis. That, I think, is a success.