In a previous post, I wrote about the challenges and strains on roles and processes when a traditional waterfall (or even agile) organisation introduces devops. Most people focus on the tools needed and how you must establish a build pipeline and support for continuous deployment to production. However, the success of devops is in the practices of the people involved, not the tools themselves.
After writing the post, I realised that I have to write something about the backlog and the product owner. The backlog because without one single, common backlog, your velocity goes dramatically down, and the product owner, because this role might be the single most critical role in both agile and devops.
I see quite a few people who do not really understand the backlog. Very often, we see multiple flavours of backlogs for the same product or service. Let’s look at the variations.
The product manager’s backlog is a list of customer features. Typically, these are prioritised based on a number of factors, like the business case for a new feature, the number of customers (or size) screaming to get it, deals being blocked by the lack of it, critical bugs found by customers, and so on. Truth is, this is what makes the product sell and pays for your job, but it is not a backlog! It is a feature or business outcome wish list.
So, what do you do? Well, you can go through a formal process, get engineering to estimate the effort, and get yourself an approved or committed set of asks. But just making a cut-off somewhere, “the rest goes below the line”, does not make it into a backlog. The reason is that engineering has a bunch of things it needs to do as well. So, when estimating the effort, they will be conservative, because they know that module X needs to be refactored before this new feature can be added, or they have a database scale issue they need to fix. So, some organisations add these engineering asks to the list. Do you have a backlog now?
Nope, because there are a bunch of things the senior engineers and architects believe needs to be done now in order to deliver features and quality code in the future. These can be based on the strategic direction of the company, on-going technical initiatives, or just re-architecting parts of the application. But, these activities will not deliver features in the upcoming release or cycle. I see some teams hide work like this by excluding some senior engineers from the priority and resource discussions, thus effectively creating a stealth team. Unfortunately, this means that some of the most important engineering investments into the future success of the product is not visible to anybody outside the team.
Some teams “partner” with their product manager and agree to a “backlog” of features, with some engineering asks added in. Then, they go ahead and track their work items through a post-it board or a kanban system where you can deduce to some extent what a work item is delivering into, but not always. The “official backlog” of features may be kept in a planning system like Rally, with user stories written for each feature. However, the “hidden” engineering activities may be kept outside the planning system.
So, you got the product manager’s backlog, the engineers’ backlog, and the architect’s backlog. How do you manage this in a good way? In too many cases, they are kept separate, and a lack of transparency and limited understanding of what is going on create frustration and friction for all parties.
It is my view that the only true backlog is the list of work items that the engineers have in front of them. You get up, choose the next task from the wall, the whiteboard or the tracking system, and you get cranking (as a team!). That’s the product or service backlog. All other lists are just input to the backlog, and unless you manage this properly, there will be competition to get stuff onto the real backlog. This is where the product owner comes in. The product owner is the undisputed gatekeeper of the real backlog and makes decisions on what gets in and when. If the product owner is only managing the “official backlog” or the feature list, then you don’t have a real product owner, just a partial owner. Typically, a product owner comes from engineering, but I have seen good product owners with product management background as well. But how do you identify a product owner? The title doesn’t cut it, so for some time I have asked “who writes the user stories?” But after I encountered teams where the official user stories were only written for customer features, my question is now “who prioritises the backlog items for the each development iteration?” This question reveals the true product owner.
A note on the more pragmatic side: roles are often combined and real life is more complex and based on real people and real relationships and experience of what works and what doesn’t. The most successful teams to manage a backlog seem to have a small group of people who together covers the product owner, the engineering lead (or project manager), and the senior engineer/architect roles, either formally through a backlog grooming meeting or informally. This triad is essential in managing a high quality backlog that keeps the team’s velocity and quality. I might later cover how successful backlog triads work.
If you have multiple teams and products, you have multiple backlogs. If you have a large number of teams working on the same product, you can split the backlog into areas (as described by Craig Larman et al in the LeSS framework). However, if you have many products that are interconnected and that deliver into multiple solutions with other products, this does not work. Only a small part of the backlog is shared with another set of products. What often happens is the “interlock” thinking. Representatives of each of the roles in each product group come together once in a while to interlock their priorities. Then they go off and develop their part of the priority and do another interlock late in the development cycle. This always fails, sometimes spectacularly. What is needed is a shift in mindset from shared planning to shared development. Each team needs to have a subset of the backlog that is shared with other teams and then the team members actually work with their peers in the other teams as if they work on the same team for the duration of implementing those backlog items. Design workshops should be done together, iteration planning, testing, and so on. If iterations cannot be aligned, APIs and flows should be stubbed and tested (with some standby support from the development team) to ensure that the other team can work on their part.
RSS - Posts