An interesting and thought provoking article …
I feel Death Knell (DK) 1 and 2 could be directed at any roles that are not properly understood or landed within an organisation — does this really mean we should give up???
The main issue I see around POs is lack of authority, influence or connection back to the business, rather than some dark art that needs 20 years mastery. Does this matter? Well if you value clear, timely and decisive decision making “Yes” — so if organisational agility is the aim, understanding the value of the product owner role would really help the organisation maximise business value. In my experience, you tend to get Jira Monkey POs when there is a complete misunderstanding of what the PO role is, and here, the entry level Scrum training and exams are effective at pointing out the way it should be (as should any SM worth their salt)
Whilst I agree that the Scrum Master exams are basic and don’t teach you everything to be a ninja Agile Coach, they are a start not an end to the journey. There are parallels with most other exams like ITIL or PRINCE2 which have foundation level, practitioner and beyond. Many US based Agile educational organisations could learn from this naming clarity — ICAgile being a beacon of good practice in an otherwise confusing market place.
On DK3 — Around the Scrum events, it is a surprisingly common misconception that you can only release once in Scrum — at the end after the Sprint Review. I don’t really understand this as in the Scrum Guide states very clearly that “Release products and enhancements, as frequently as many times per day”.
These events, not only do they help to develop physiological safety and team building, they provide the main mechanisms to facilitate Transparency, Inspection and Adaption — which are central to any empirical approach. I simply don’t see them as start or a stop, I see that as essential activities of doing the work. They embody “Individuals and interactions over processes and tools” — line one of the Agile Manifesto. This is central to high performance teams and complex adaptive systems; lose this, lose being “Agile”. If we ignore the value of the events and relationships with the SM and PO, we slip away from empowered teams to subservient teams — losing 20 years of hard earned improvements.
We also need to consider the physiological effort of not having a (Sprint) goal to commit too. I know at least one organisation that has adopted a CD approach only to revert to a sprint based approach due to the physiological impact of not being able to clearly visualise a goal. Ask yourself the question, if you wanted to run a marathon, would you prefer to do this on a tread mill or actually get out on the open road with a clear goal and reward at the end? I know which one I would choose!
Finally, I don’t see Scrum is a panacea. It is only a framework albeit a simple and effective one. As a framework it is intentionally incomplete and needs augmenting with domain specific practices. The real challenge in software delivery is not the process you use, but the ideas and technology you are working with. CD is a great technique to getting product out quicker, but I would urge people not to confuse it with an approach that encompasses the complexity of working with actual human beings.
Thanks Gary or the well articulated argument — it is an excellent example of “Inspection”. Whilst I always keep an open mind, for me, I’m not persuaded there is anything better (currently) which would make me “Adapt” and ditch Scrum.
