Having joined Pyxis Switzerland a few months ago, I had the opportunity to attend training given by my colleagues. After four years as a Scrum Master and having CSM, CSP and CSD certifications, was it really worthwhile to take Scrum.org’s Professional Scrum Product Owner training?
Four years of experience are enough for everything to be well understood and integrated, there is no doubt . . . And yet, I was very surprised to discover how essential it was for me to review the basics, to wring the neck of certain false truths and especially to be able to go further in my questioning, thanks to life and experience.
Here, I would like to present some elements that surprised me, which I had forgotten or that have changed.
The Product Owner
I had the opportunity to meet Product Owners with very different personalities:
- The Visionary: he always had new features to implement, was not very interested in the present and what was implemented. “I have a great new feature to propose . . . I do not have time to validate what has just been done.”
- The Project Manager: he checked if the developers were spending the time planned for the features. “Why did it take longer than expected? You should spend less time meeting and more time coding.”
- The Technician: a former developer, he was solution-oriented and everything seemed to be simple. “You’ll see, it’s very simple. It only takes 1 day of development.”
Ultimately, my vision of the Product Owner was rather partial and I mainly relied on the experiences I had to define the role’s outlines. By cons, I already conceived, and still do, that it is a difficult and delicate role.
In the Scrum guide, the Product Owner’s role seems to be the vaguest. It says: “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”
During the course, I realized how much the Product Owner’s role can be broad and ambitious. He can be an entrepreneur within the company. Ideally, he should have the power and leadership to do this: believe in his product and do everything possible for the good of it. We are talking about a Product Owner and not a Project Owner: he will be the guardian of the product in the long term and will not abandon it when he goes into production.
The review . . . the event that has lost its meaning
After years of unsuccessfully trying to have stakeholders present during the review, I realized that I had eventually forgotten its original purpose.
The review is not only a demo. It’s not a validation session between the development team and the PO. The review is the intended and official way of the Scrum Guide to receive feedback from stakeholders and to be able to present the upcoming backlog and adjust it if needed.
Now, I am happy to once again find meaning to this meeting and see the benefits. What a pleasure it was when I returned from the training and proposed to the Product Owner to share the upcoming backlog . . . and discovered, thanks to the stakeholders present at the meeting, that one of the stories he had planned as a priority was now in fact completely obsolete.
The new pitfall that I face since the stakeholders are actually there is to prevent the review from becoming a “progression status” meeting in the traditional sense where the development team may be slapped on the wrist. People constantly need to be reminded of the importance of having a participatory spirit and giving constructive feedback. Gradually, the change is made.
Do not talk to me about commitment anymore
During the sprint planning, I asked the team: “Are you confident? Do you agree on the backlog items planned in the sprint?”
I learned that we should no longer talk of commitment, but of projection, of forecasts. The term “commitment” was too accurate and made no sense with estimates. By the way, how many of us have ever been confronted about the accuracy of their estimates?
— “I don’t understand, you told me that it would last 10 days . . .”
— “No, no, I said my estimation was 10 days . . .”
By changing the vocabulary, from commitment to forecast, the Scrum guide tries to focus on the area of uncertainty. As an individual, I do not know if that has the desired effect, but it is true that changing the vocabulary makes it possible to question certain preconceived ideas.
These are just three examples of what I relearned during the Professional Scrum Product Owner training. So I found a lot of value there. And from there to saying that this training was a revelation thanks to the pedagogical qualities and the experience of my colleague Tremeur who gave it, there is only one step . . .