(or, why the right governance is good and how we’re approaching it at HackIT)
Governance as a service — governance so good, people prefer to use it
At HackIT we’ve been thinking about how we run ourselves, and our work. I’ve been looking at what we need to do next to iterate our approach to governance. Our HackIT manifesto already sets out our key principles — and there’s been lots of work done to remove some tortuous processes that weren’t working for us.
We’ve already opened up our work, use the local gov digital standards as a benchmark, have adopted the GDS tech code of practice to guide us, introduced pair programming and test driven development, and we’re using agile principles and rhythms to deliver value early, and increase pace of delivery.
But the team is changing and developing — new people are joining us from all sorts of different organisations (and we have 21 new apprentices starting). We need to be able to scale, develop and embed our approach effectively — recognising that we’ll learn along the way and we’ll want to adapt it as we go.
Why is governance important to us?
Governance helps us maximise the flow of valuable work. That’s basically its purpose — with three main functions:
- Coordinate what we’re doing and stop doing stuff, so we can go faster
- Focus our people and money, so we can deliver what matters
- Answer the question “How’s it going?”
My hypothesis is that we don’t need more governance. But because we are scaling a new approach to working using agile we do need to be really clear about what we’re doing and why, communicate it well, and keep checking in with ourselves to make sure it’s effective.
We’ve got some governance principles to help us get this right:
- Work in the open by default — because that enables us to reduce formal governance
- Most decisions should be made at team level — that’s where the best information is
- When a decision impacts more than one team — teams are responsible for discussing and agreeing what to do between them
- Where a decision impacts us all — we need to discuss that more formally at a senior level
- Clear protocols and guidance help us so we avoid overwriting each other’s decisions.
We’re still working on some of our protocols and guidance — for instance around our data strategy and our API strategy — and some, such as the GDS tech code of practice, and the local government service standard we’ve already adopted because we know they work.
What are we doing next?
We’re going to clearly delegate responsibility and decision making to team level wherever possible. To support our teams we’ll focus on growing key skills and behaviours around leadership, decision making, working in the open and use of evidence. As a senior team we’re committing to regularly and clearly communicating our approach including how we feel about risk.
These are big commitments and we know we can’t do everything at once. So over the next three months we’ve decided the focus will be on:
- Using the updated Pipeline tool that went live this week to openly show the flow of our work
- Running 5 service assessments, learning from doing these so that we know what our change process (production into live support) might look like in the future
- Carrying out a discovery phase on a next iteration of our Hackney Agile Lifecycle to support our understanding of and narrative about our governance approach
- Building a strategic procurement plan using data and insight from our contracts register
Standing on the shoulders of giants
Some really clever and thoughtful people have done great work on agile, governance and working at pace. Here’s my curation of some of the best blog posts/articles I’ve read, along with my thanks to all of them for sharing their work so openly: