The principles and practices behind Agile and Scrum are demonstrably better in terms of productivity, quality and job satisfaction. In the past 10 years in the UK, we have seen the Agile movement go from a crazy idea in the depths of Shoreditch to the defacto method of choice for government IT initiatives.
But Scrum is not perfect; it has weaknesses that all its practitioners should be aware of. In this short series of blog posts, I will aim to discuss these weaknesses (as I see them) and explore their mitigation.
The Product Owner Role
The Product Owner is one of the key members of the scrum team and a critical success factor to any Agile development project but the Scrum Guide gives barely half a page to describe the role. "
The Product Owner is responsible for maximizing the value of the product and the work of the development team. How this is done may vary widely across the organization
"
While the description is terse, it is powerful in what it
does not
say. Its guidance: "
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the product backlog...
"
But here is where I perceive the weakness: The Product Owner role is key, but in reality it is seldom possible to find
one
individual who can fulfill the role and be available to the team full time (and it is a full time role). As Product Owner, their duties include:
- Communicate product vision and mission
- Continually manage the backlog
- Manage stakeholders at all levels
- Explore and Discuss solutions with the development team
- Attend planning, stand-ups and review meetings
- and a whole lot more
In practical terms, projects need to find solutions that allows the product owner to perform well with limited availability, and when projects scale to medium and large sizes. Here are my alternatives:
Solution 1: The (mostly) unavailable Product Owner
Sometimes it is obvious who in an organization should be the product owner - but very often that person has a day job that they cant (or wont) delegate, even temporarily. The project should appoint a
proxy
product owner to share the role by taking on the day-to-day tactical effort, with the final strategic and authority staying with the Senior Product Owner.
Solution 2: Product Owner for multiple teams
When a project is of medium size (3 to 5 teams), the Product owner role can be shared between the teams - that is one product owner manages one backlog from which the teams select their sprint backlogs. Depending in the type of project and skill of the PO, this can be managed well. The main drawback is the workload of the PO is taken up by several planning meetings and reviews each sprint. A good idea here is to arrange the backlog into Epics which are assigned to the teams.
Solution 3: Scaled Product Ownership
For large projects, One product owner can no longer service all the teams, and so must delegate to other product owners. This is best done along epics to allow the minimum of dependencies and context changes for Product owners and their teams. Notice that the pattern of a single authority for a product owner is maintained - we don't create a committee of product owners.
NB:
There patterns can be used in combinations!
Conclusion:
Scrum and Agile lore has grown up quickly to support people to become good Scrum teams - developers and managers know about stand-ups, self-organizing, planning poker etc, but there is little common practice to help with the critical role of the Product Owner. To help with your unique situation, use the principles in the scrum guide to better organize your product owners.
I have used these patterns to good effect and hope they are useful in your projects.