Getting agile governance right
In product development, governance is essential for ensuring quality and problem/market fit of the solution. Governance should provide broad oversight of the wider organisational implications of the solution so that the team building the product can maintain their flow and focus.
In a traditional waterfall or stage-gated development process quality assurance and approval checks happen towards the end of the work. It makes sense if you’re optimising for efficiency as all the quality check governance happens when the development is as close to it’s live and finished state as possible. But it’s based on the assumption that it’s possible to know ahead of the development work all the possible considerations and implications, which approval checks can refer to and confirm met or not.
The agile perspective is that its not possible to know all those implications ahead of doing the development work and so the better approach is to get smaller feedback more regularly and respond to it more quickly. This is better than waiting until near the end because changes are easier to make whilst development work is in progress. This approach optimises for effectiveness where getting it right is more important than doing it quickly.
Getting agile governance right takes three things; showing work in progress, educating stakeholders, and building feedback mechanisms.
Showing work in progress
Working in the open is not a nice-to-have, its an essential part of agile governance.
Show and tells, weeknotes, public roadmaps, and regular discussions with stakeholders, are all part of working in the open. They are about showing progress, but they aren’t status updates, they are quality control. By showing work in progress regularly and prompting stakeholders to ask the right questions, product teams can make explicit any assumptions they have and clarify things they are unclear about.
For some teams, this is where agile governance stops (and fails). They show the work but stakeholders don’t know what to do with what they’ve seen. Teams can easily spot this by the amount and quality of discussion they have with stakeholders.
Educating stakeholders
Understanding the implications of what the product team is doing requires dedicated and widespread organisational knowledge.
A stakeholder is anyone for whom a change matters because it affects their ability to achieve their goals. They need to be able to think critically about what they’ve seen from the product team, to consider the implications on their area of the organisation, and to ask the right questions to clarify the impact. This doesn’t happen by accident. Stakeholders need to learn how to be an effective part of agile governance, and often it falls to product teams to do that.
Educating stakeholders means helping them be clear about which of their goals might be impacted by the product. If the product helps user’s self-serve, what are the implications for call centre capacity and workforce planning? A development team won’t have the knowledge to answers those questions but a stakeholder who manages the call centre might. But only if they come to a show and tell or read weeknotes with that question in mind.
Generally, stakeholders need to be explicitly told that their role is to understand enough about the overlap a product has with their area that they can spot implications that no one else sees. Once they’ve noticed implications they need a way to tell the product team and have confidence the they’ll be discussed and resolved.
Building a feedback mechanism
Product teams need to put processes and tools in place to collect, manage and communicate a response to stakeholder feedback.
All too often, stakeholder feedback is managed in an ad hoc way because it’s seen as a challenge to the product rather than an opportunity to achieve a wider and more coherent solution. But when teams and stakeholders understand that feedback is an important part of agile governance, and being able to do it effectively is the difference between a product launching without unexpected issues and it landing with positive impact.
Big public show and tells often aren’t the right forums for discussing the details of feedback, so instead teams should make it known among stakeholders who to speak to, how to get in touch, what kind of information to provide, how the discussion will happen and how long it’ll take. Those kinds of expectations should be the basics of stakeholder engagement.
Sometimes that discussion leads to development work, sometimes to a change in business process or providing additional information to someone. Sometimes its a big change but more often, and especially if the agile governance process is working well, it’s a small change caught early enough to be made without lots of consequences.
How to know it’s succeeding
When agile governance is succeeding, no one should notice. Perfect governance results in zero issues and zero rework, and we don’t notice what isn’t there. So we can only judge agile governance by its failure. If work goes live and causes issues, not just in the code but for other parts of the organisation, then governance failed. If that happens, run a retro with stakeholders to find out why and what you can do to fix it.
More thoughts from others: