This post is the first (out of 4) of blog series about Product Ownership Evolution. Our organization has been evolving quite a bit in our Product Ownership thinking and understanding during our transformation journey. In these blog posts I try to summarize our main approaches, the evolution and some thinking and challenges that have been visible in our context (some of these thoughts may also be something you can relate to).
1. Simplistic Scrum approach (this post)
2. Scaled-Up Scrum (part 2)
3. Requirement Areas (part 3)
4. Enterprise Product Ownership (part 4)
We started more than 3 years ago with basic and simple Scrum approach. Scrum definition of Product Owner:
The Product Owner is the one and only person responsible
for managing and controlling the Product Backlog. This is the
person who is officially responsible for the value of the work
done. This person maintains the Product Backlog and ensures
that it is visible to everyone. (Scrum Guide page 4)
This approach assumes a few vital fundamentals that are in place, otherwise we
might will face problems:
1. Scrum team is in place: we have a ScrumMaster, PO and a team. Team should be crossfunctional end-to-end feature team. In my thinking this implies that enterprise level operative view is embedded within one team. In other words the whole value chain is realized with 5-7 persons and multiplied (if scaling is required) with additional teams that share the same approach.
2. Customer collaboration over contract negotiation. This is the fundamental from Agile Manifesto which is maybe the most important (and most often misused) when considering PO. In enterprise this means that there should not be separate Product Management and R&D organization. PO (as fully responsible of value of the work done) has the authority and responsibility to use all assets as he/she prioritizes. There is no role for R&D line organizations to decide what work is done by people or machinery. The traditional commitment game has disappeared. Unfortunately I have not seen or heard this being realized in any large organization. If this is not in place (as I have witnessed) -Scrum does not work.
While we now seem to somehow understand these we do not have (or did not have) these fully in place. This created a lot of confusion and additional challenge in understanding how Agile is realized within Scrum context. A couple of examples.
Product Owner did not understand what is the level of technical detail he/she needs to go. This was partially due to missing authority on the business side -focus was put on the technical issues instead of business value. This was partially fixed with moving more responsibility of technical work to System level Communities, which were for developers (I will open up this more in part3 of this series)
System test was completely missing from the early User Stories and Epics. This resulted that work was only partially done within Scrum teams. This division also was visible also within Product Owner: “Done” features could not be delivered to customer before additional testing or configuration (outside Scrum teams) and this was not perceived as responsibility of PO.
Impediment handling was not sufficient. Only part of the organization was attending to the continuous improvement work withing Scrum context. A lean principle “see the whole” was missing and this resulted to sub-optimization.
To summarize: our organization was not able to adopt simplistic Scrum approach to make it work sufficiently. We might come back on these ideas when we learn how to implement more vital key fundamentals but initially our decision was to adapt. Our next approach was to introduce Scaled-Up Scrum (more on next part of this series).