It is often said that the aim for the Scrum Master is to make themselves redundant. They should be looking to create such a high performing team that the team are able to remove their own impediments and no longer require any facilitation. Geoff Watts provides a great analogy in his book, Scrum Mastery, that of Nanny McPhee.
Hopefully you will have seen the film, but for those of you that haven’t, here is a quick synopsis. Mr Brown is a widower with seven badly behaved children. Following a string of unsuccessful nannies he stumbles upon Nanny McPhee. On her arrival she tells the children,
There is something you should understand about the way I work. When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.
Nanny McPhee implements changes to the children’s rules and processes that restrict their freedom making the children hate her. Over time they learn to appreciate these new rules, so much so that they don’t want her to leave, but with her job being complete, she must leave.
This got me thinking – is there a similar analogy for Product Owners?
Having taken a look back as my time as a Product Owner with both internal and external Development Teams, I made reference to the analogy of the Product Owner being the driver of a car, setting the direction of the development. Given the technical advances that are currently being made in the automotive industry, could this analogy be taken a step further – could they become a test driver of an autonomous vehicle?
Should a Product Owner have the aim of being so prepared with the elaboration and prioritisation of the Product Backlog, while at the same time building so much trust with a team that development can drive itself forward? Much like the test driver in a Google car, the Product Owner will need to remain in the vehicle. Firstly, they need to be there to provide details of the destination, while the team as the autonomous vehicle, decide how to get there and plan the route. Secondly, they need to be there in case things go wrong and they need to retake control in order to avoid a crash (or at least minimise the damage).
Just as Google are able to learn from the data they collate from the driving of autonomous vehicles, Development Teams should gather metrics on their performance for further analysis. Collection and analysis of data allows teams to learn from where they have been, but also allows them to predict where they may be able to get to in the future by making small incremental improvements. And, even if there is the odd car crash, this is just another opportunity for the team to learn and make improvements to be made to processes/procedures.
I don’t think that a Product Owner will ever be able to make themselves Nanny McPhee, but could aim to be a Google Car test driver.