Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification.
The reality that I see on most enterprise agile projects is that the product owner cannot possibly manage the work item list themselves. In fact, they are often not the best person to do this prioritization. I wish it were as easy as managing epics and user stories.
On my current project, we are in the process of taking ownership of a very large application built offshore. In DAD, we would describe this as the Transition phase of the product as we deploy the solution to our stakeholders. We will take over the build, deployment, support and enhancement going forward. This is a team of 20+ with responsibilities spanning development, infrastructure, and devops. Due to the complexity of the rollout we are doing it over a number of Transition iterations.
A simplistic view would suggest that the Program Manager is our product owner. At the end of the day he may have ultimate responsibility, but he is not collocated, and deals with the larger issues of the project, such as vendor management, governance, funding, resourcing, and other related issues. He delegates responsibility for the details to domain leads for the business, development, infrastructure and support.
My approach as the overall agile team lead is to treat the these traditional leads as product owners. They each have their own work items and priorities such as:
Development team:
setting up VM images for development support of code
determining a source code management strategy for parallel streams of maintenance and enhancements
automation of continuous integration & deployment
Support team:
establishing a customer support strategy, with triage process, roles, on call schedules etc.
Infrastructure/DevOps team:
setting up automated jobs
performance tuning
Business:
change requests/stories
defects
All:
knowledge transfer between vendor and support team
satisfying stage gate acceptance criteria
documentation of procedures
For these work items, who is responsible for designating priorities, assigning to iterations, and iteration planning? The last question is the easiest to answer. We let the team members doing the work do the task identification, estimating and assignment. The other questions are a bit more tricky. I don’t believe that any one person should determine the scope and prioriity of these diverse work items. Rather, as team lead, I would prefer to let the team leads of infrastructure, customer support and development (traditionally might be PMs) to self-organize and advise me on their priorities and in which iteration their work items should be completed. The summary of which is then reviewed with the Program Manager to assure alignment with the overall program’s goals.
Therefore what we are doing is co-managing the work item list with myself as facilitator.
This discussion shows some of the challenges in managing a DAD Transition iteration(s) using an agile approach. I understand that the idea of having shared product ownership is not consist with methods such as Scrum. However, in my world of large enterprise agile projects pragmatism trumps the agile “code”. As Barbossa says in Pirates of the Caribbean, “the code is more what you call guidelines than actual rules“.
