On Agile Governance
How agile working can mitigate, not compound, risk
During the shift to more adaptive, agile ways of working (and particularly as agile scales beyond the tech team) questions often arise around governance and control. Concerns can be raised about alignment, control of costs and direction. People often feel uncomfortable moving away from the apparent comfort of a detailed, forecast end point, and leaders shy away from the apparent inherent risks. The irony being of-course, that many traditional approaches are built on false certainty anyway. Plans and forecasts become outdated as soon as they’re inked. Predicted outcomes quickly become obsolete and in need of updating.
So I really liked what the Co-Op digital team had to say about their approach to agile governance. If by governance we essentially mean doing the right things in the right way, then agile, iterative working actually mitigates risk rather than compounds it. The ability to be more adaptive means that we never get too far before we can switch course. The practice of working closely with end-user input and feedback. Continuous testing and delivery.
Jamie Arnold, the Head of Agile Delivery at the Co-Op details eight key components for how to do governance well in an agile context (I’m paraphrasing for brevity here but worth reading the whole thing):
- Outcomes are better than deliverables: the importance of orienting the team around what the product or service actually does, aligning that with the wider vision, easily measurable mid or long-term goals, space to learn what works rather than specifying the solution upfront.
- Measure the right things at the right time: measure a few quantitative things, make the measures visible, independently verifiable, review often. The right measures can motivate, focus and build confidence
- Teams are the units of delivery: small, multidisciplinary, non-hierarchical teams focused on momentum and given enough autonomy to plan, prioritise and do the work in the order that works for them
- Network of teams beats hierarchy: networks of small, self-directed teams with minimal inter-dependencies using data to plan and prioritise
- Quality is everyone’s responsibility: common agreement around what quality means, how to measure it, user feedback validating the delivery of business value, continuous quality assurance
- Assure as you go: improvement is continuous and supported by regular, short, challenging forums, minimal stop-start but instead the flow of value delivery
- Behaviours matter more than documents: less long-term documentation, more user research logs, weeknotes, verified metrics. Focus on how the team collaborates, responds to feedback, is part of a network of teams, involves stakeholders, removes blockers
- See delivery for yourself: not just talk, but regularly showing work in progress
Much to like about this. Yet the wider point here, and one that we bring to life in the book, is that this again speaks to principles, behaviours, and approaches that have far wider benefit than just the tech team. As Jamie says in his post agile is more of a mindset than a set of defined processes. It’s about being agile, not just doing agile.
Originally published at Building The Agile Business.