November 04, 2015
Get in touch
When business admin professionals* hear the term “redundant resources”, their hackles are raised instinctively. It's no surprise, as this is often synonymous with “a waste of money.” “Restructuring” measures are often carried out with the rationale that “redundant resources”, need to be reduced.
Because of its poor image, I would like to strike a blow for redundancy.
* As one of them I can state this categorically
In truth, Scrum is based on redundancy from the get-go. After all, in Scrum the dev team is assembled to be as cross-functional as possible. Team members are developed in the direction of “T-shaped people”, that is people with broad-based common knowledge and at least one in-depth specialization. Information should be disseminated as broadly as possible to avoid isolated pockets of knowledge. Team members should be able to take vacation without the entire product development grinding to a halt.
Why, then, does the Scrum framework allow for only one product owner?
Of course it is sometimes simpler when a “single wringable neck” has the final word in prioritizing the backlog. Giving the product owner ultimate authority when doubts arise, especially in large companies with complex matrix organizations, ensures that a product backlog – and with it the product itself – are even taken care of.
However, these same advantages that are created through redundancies within the team are lost in the case of a single product owner.
Thus, a lot can be said for trying the process with two product owners.
As mentioned in a previous post, our team works successfully with two (proxy) product owners. In my opinion there are several reasons for this.
For one, the project is relatively complex, where we are dependent on technical concepts that are translated into wireframes before the necessary interfaces can be executed by another service provider. It is only then that a user story reaches the development stage in our team.
This long journey of a user story from the initial idea to the stage where the “Definition of Ready” has been fulfilled takes at least three sprints. This gives rise to complex dependencies that must be kept in mind.
To overlook a detail here causes immense time delays. To ensure this doesn’t happen, four eyes definitely see more than two – particularly if one considers that vacations and illnesses alone are enough to make sure that the product owner is often a bottleneck. We were able to reduce this risk significantly by our dual-role concept.
In addition, our team is very large (at least for a Scrum team). We could effortlessly create two Scrum teams, which would still be relatively large, from our single team and would therefore need two product owners anyway.
To avoid inflating the development process we decided to not split the team. The consequence of this is that there are considerably more uncertainties and questions from within the team – and these can also be handled much better by two product owners.
Overall, therefore, “single wringable neck” also means “single bottleneck”. If cycle- and lead times – that is, the time a task needs to traverse through the entire process chain or parts of it – are values that require optimization, then there can be no single persons in the process that might lead to informational backlogs or pockets of knowledge.
Cycle- and lead times, especially, are factors that have a powerful influence on the degree of agility within a process. In this respect, Scrum teams aren't the only ones can benefit from redundancy.
In any organization bottlenecks should be identified ways found to eliminate these – reducing redundancies can only be the wrong approach here.
If I start thinking about what I have had to wait for the longest during my career, then it's surely been decisions.
Traditional organizations, however, tend to tie decisions to individuals. And, the more important these decisions are, the stronger these ties become. Systemically, this is counterproductive. Rather, creating redundancies may be the solution here as well. Another: Reducing the load (another term that sends shivers down the spine of business admin types). The question is, however, if it doesn't make more sense to significantly increase the total productivity of a system by using one additional person, rather than lowering productivity by having to adjust it to a single bottleneck.
A functional system needs to proide means, then, to make decisions efficiently – and the best place to make those decisions is where they are needed. We've now arrived at agile organizations and one of the reasons why they work so well.
One of the characteristics of agile organizations is that they don't bundle decision-making abilities by avoiding redundancies of any kind. Instead, redundancies are actively created and employees are empowered to optimize the overall system.
As my grandmother used to say: Better safe than sorry.
