In the olden days of waterfall development, you had teams of Business Analysts that all sat together. When a junior BA joined an organisation, they had a number of colleagues sat around them that they could call upon for advice and help, and lots of time for requirements documents to be reviewed and revised before being thrown over the wall.
But with agile development teams, we embed Product Owners on their own within the dev team. They are surrounded by engineers and Scrum Masters, but don’t have colleagues doing the same role sat around them. A junior Product Owner with little previous experience may end up feeling that they have been thrown in at the deep end with little or no support.
So how do we develop a junior PO?
A graduate or junior Product Owner can’t just be expected to write amazing user stories on their first day. Even an experienced Business Analyst making the leap into agile can’t just transition to user stories without any help. So how do we do this?
Is it a case of sending new staff on Product Owner training as part of their induction? Do we enrol them on Product Owner certification courses with the likes of The Scrum Alliance before we let them loose on their first story?
I suspect it would be a bit of overload to front-load the training in the first few weeks of employment. Any new employee has enough to absorb in their first month without throwing a lot of agile theory into the mix.
A development plan for juniors
We can’t expect junior Product Owners to add value on day one. Ideally we need a development plan for them, based over a number of months, so that they can gain some initial experience on the job, and then maybe look at the certification courses to learn all the theory.
We can’t place a junior on their own in a development team. I know there are often pressures to fill open roles, but we should allocate the time for new people to shadow more experienced Product Owners — to observe what they do. They need to witness the secret sauce of Product Ownership, and learn how they gather and analyse information, how they communicate with their team, and manage their time.
Only after a couple of months working under the direct supervision of another Product Owner should the junior be allocated their own team — and even then the more experienced person should continue to offer mentoring.
Community of Practice
It’s great as well if the organisation has a good Product Owner community of practice where POs can come together to share their experiences and seek help. A good Community of Practice can help supplement the on-the-job training, and help juniors broaden their perspectives by engaging with a number of people.
It’s also good for more seasoned Product Owners to help them inspect and adapt their own behaviour and practices, to make sure they engage in continuous improvement!
Other sources of help
A Scrum Master or Agile Coach can help provide some good background on agile development, and maybe help explain how a Product Owner is meant to contribute towards the team.
It might also be worth tapping into the collective experience of the development team itself, to ask what they need from their Product Owner. I like the idea of allocating a retrospective session at least once per quarter to ask the questions about how a Product Owner can better serve their team.
After all the idea of writing user stories is to try and communicate requirements to the developers, so who better to give feedback on the usefulness and quality of those stories?