The Product Owner and Governance?
This is going to be a quick little post to see if I can get some feedback from you guys…
In my recent post 12 Key Agile Assumptions, I made the assertion that agile methods assume you have minimal process governance. Here is an except from that post:
11. Minimal process governance – Agile doesn’t deal with phases, budget approvals, business cases, templates, change management, audit controls, charter documents, scope sign-off and the like… at least not explicitly. Much of this is left to the strength of relationship, and the degree of trust, between the customer and the team. In larger, more complex organizations, at least for now, governance is part of the equation. We need to have a credible story in place to deal with it. There are tons of things we can do here, it’s just that agile doesn’t have the answer… and in all honesty, that’s kinda by design.
I got a comment from one of my Twitter followers @AgilePME telling me that my point was wrong:
AgilePME: @mcottmeyer re http://bit.ly/gUHLj6 – 11 is wrong. These are the core responsibilities of effective Product Owners & aren’t outside #scrum.
Are we really suggesting that the Product Owner is the embodiment of process governance for the team? Or is it that the Product Owner simply abstracts process governance from the team? If we are suggesting that the PO is process governance, I would suggest that is by its very definition, minimal. If we are suggesting that the PO should abstract process governance from the team, I might suggest that there is a ton of heavy weight governance models out there that would be totally incongruent, and potentially disruptive to a Scrum team.
So… have we all decided that Governance is within scope for a PO? I’d love it if anyone happens to have reference to something definitive you could point me to. Obviously I am missing something. Would love to hear your thoughts.
Comments (3)
vic williams
We’re blending apples, oranges, and pecans. Scrum is a pattern or way developed from “new new product development” (Nonaka’s game) first for software dev, and now gone into Churches etc. It doesn’t carry factory or business process baggage along with it. Agile includes a whole swack of styles or processes or ways. Most don’t have what they call a ‘product owner’, nor a project manager, nor a mass of ‘heavyweight’ firestarter materials. The basic agile pattern matches the business startup pattern, an entrepreneurial pattern – not tied to bureaucratic anchors. A scrum team grows, inspecting and adapting, into a more agile team. A company or army may squash any agile process with heavyweight requirements.
In the heavyweight class area, the US army is going agile adaptable via a Design Thinking program. Google on ‘banach design thinking’ or “martin rotman us army design thinking ” (this second is the rotman business school comments). Their main obstacle is “just give us a checklist, and let us use ‘shock and awe’.”
In the cultural awareness and marketing area, lots of people are imprinting ‘agile’ or ‘scrum’ on their ties and foreheads and claiming all kinds of project management ways are THE agile way. If you don’t offer XZY that appears on their checklist, or as it appears as a feature in their software, then you are WwRrOoNnGg. So you’re probably wrong. Peel the apple and eat it.
Vic,
Thanks for your comment. That was kinda my initial point. Agile assumes little governance (I think it can accommodate a little), but governance DOES exist in most organizations that are considering a adoption of Scrum. The presence of this governance will derail your adoption efforts if you don’t change it or eliminate it. @AgilePME asserted the governance was the domain of the PO… I disagreed… I think I know where you stand ;-)
Mike
Felix
Not only governance but the whole complexity of all “non agile” parts of the company are hidden behind the Product Owner.
The PO is the key success factor when introducing agile processes in organizations. Its not the “normal” Scrum Master – a guy who focuses on getting the rules right in his area of influence and working on “simple” impediments. A SM will highlight organizational issues but during the last years I saw SMs failing time after time when trying to fix organizational impediments. The real progress came when the PO was addressing the topics.
The problem is that there are only a few good POs out there as it needs the skills, the experience and the empowerment to do the job right. Just ask at your local Scrum User group an you will find out that everybody says that there is still huge potential for improvement in the work of the PO. That is because everything that does not fit into “productivity & production focus of the dev team” has been declared the responsibility of t he PO. Good for the focused dev team, a huge challenge for the PO.
I have been writing (in German) about this quite some time ago:
– http://www.armerkater.de/2009/12/scrum-user-group-karlsruhe-die-leiden-des-scrum-product-owner/
– http://www.armerkater.de/2009/03/scrum-product-owner-eine-sehr-anspruchsvolle-aufgabe/