Most people I know in IT have already had experience with Scrum - often Scrum has been used in companies for years.
So you would think that the overall agile maturity level here is very high and the process is fully agile. But when Scrum is implemented, there is often a very technical focus, which is often only about executing the events and routines of Scrum and "agilising" the development teams. However, it is often overlooked that Scrum only works well if the product management also works in an agile way and adapts to the way of working.
And although the Scrum Guide has a lot of good things to say about the product backlog, planning and the role of the product owner, it is far too little to survive with in the field.
A few examples of what a product owner must do according to the Scrum Guide:
- „Developing […] the Product Goal“
- „Ordering Product Backlog items“
- „The Product Owner proposes how the product could increase its value”
Product owners I've geocached have asked me, "How do I do that?" What is the best way to create a product goal or a product vision? What rules should I use to prioritise in the backlog? And how does "value" fit into this?
And this is exactly the crux of the matter: Scrum demands these things, but focuses more on the core part, which is development/delivery - a decision that is, of course, completely justified from Scrum.org's point of view, because it is not possible to cover all functions and disciplines.
And it was exactly this gap that I wanted to close with my presentation at the Modern RE: The aim was to provide product owners with tools and techniques with which they can solve these daily problems in a structured way. For this purpose, I have compiled a coherent set of best practices.
Actually, the whole thing was only planned as a conference talk - but the longer I spent on summarising all the experiences, the more I realised that the connections are more complex than they first appear. As a coach, you usually only analyse and support where the biggest gaps are, because there are often many problems at the same time and you can't be everywhere at once. You already have the "ideal process" in your head - but you only communicate the part that is needed at the moment.
So over the last six months I have sat down and written up this "ideal process" and published it freely for all to see and use at https://agileproductmanagement.org/.
The framework is designed visually so that it can be understood as quickly as possible - because we all have little time to read hundreds of pages.
So you can either go through the individual steps, or download the summary in the form of a handy guide.
In addition, there are lots of examples and templates that you can use for your agile product development.
I would be happy if it helps someone to better deal with the challenges of agile product development and welcome feedback on it.