I’ve had lots of conversations with colleagues in the Co-op about working in agile ways. A concern that comes up often is: how do you make sure costs don’t run away with you when you’re working in an agile way? Another one is: how do you do governance if you’re working in this way? (They’re actually pretty similar questions).
It makes sense to have a piece of internet that I could point to which explains how to do governance when you’re doing agile delivery. That’s what this blog post is about.
Governance is about so much more than ‘stage gates’
What do we *really* mean when we say “governance”? We mean that we’re doing the right things, and in the right way.
Organisations that adopt agile ways of working have a better chance of doing this. Why’s that? Firstly because agile teams are used to having to adapt and change direction quickly, because what they’re going to do isn’t set in stone before they start working. They work closely with people who are actually going to use what they build, which is a faster way of delivering and testing services than working in a waterfall way. And because the teams organise themselves around continuous improvement, and put their products and services in front of real users regularly, they’re better at responding to any feedback they get.
Teams often talk about being agile not doing agile. The implication is that agile is more of a mindset than a set of defined processes. It’s also an acknowledgement that no 2 teams work in exactly the same way.
For the past year, I’ve been running masterclasses on agile ways of working. These are the main things I share for how you do governance in an agile team:
A lot of this will sound familiar to people who have seen the National Audit Office’s governance principles, or the Government Digital Service’s governance principles. I’ve been inspired by them. That’s not just because I think they’re good and because my most recent job was in government. It’s also because government is one of the few big organisation that talks about how it does governance.
I think the Co-op should too.
1. Outcomes are better than deliverables
What does the product or service you’re building do? Orient your team around that. What it does should make sense in terms of the company or organisation’s mission. Leaders should help teams define mid and long-term goals. They should be easy to measure and everyone working on the project should be committed to fulfilling them. Instead of specifying the solution beforehand, give the teams space to learn what works, by building things quickly and failing fast. Be open about how things are going, and trust that everyone is good at what they do and working as hard as they can.
Examples:
- Goals, cycles and people: running an agile, complex programme in government
- Missions are built on words and then actions
2. Measure the right things at the right time
Picking the right things to measure, at the right time helps motivate and focus the team. Trust teams to monitor their own performance. Make sure what you’re measuring can be verified independently. This helps build trust and confidence in what the team is doing.
Everyone should:
- agree early on measuring a few quantitative things
- make these metrics visible to everyone and independently verifiable
- review these often to make sure that what you’re measuring is useful
Example:
3. Teams are the units of delivery
A team is in charge of how it delivers products and services. There’s no hierarchy within teams, even though they contain people from all levels of the organisation.
Organisations that want to be agile should:
- ensure teams are multidisciplinary to include a mix of people to design, deliver and operate a thing
- let teams experiment, fail fast, learn quickly and improve how they work
- allow teams to decide if, when and how to grow
- make sure teams are planning and prioritising their work in the order they see fit
- focus on flow and momentum over false certainties
4. Network of teams beats hierarchy
Organisations that are set up to work in an agile way have a network of small self-directed teams. Dependencies between teams are kept to a minimum. Strict hierarchies, where too many decisions need senior-level approval, make it difficult for teams to do their jobs and gets in the way of delivery.
Organisations should ensure that:
- teams use data to prioritise what and when to deliver
- they’re set up to support agile teams
- they encourage teams to talk to each other
- remove blockers
Examples:
5. Quality is everyone’s responsibility
Everyone involved needs to understand what good looks like, because everyone is responsible for delivering that. Quality assurance isn’t a ‘gate’, title or a role. It’s what agile teams do every day.
Sponsors, key stakeholders and teams should:
- agree what quality means and how to measure it
- understand what ‘done’ means
- ensure that user feedback validates the delivery of business value
- organise so that external assessors (for example, auditors or security) and subject experts are integral to the team, not gatekeepers
Example:
6. Assure as you go
Assurance isn’t a one-off in agile delivery. Quality, business value and compliance are regularly demonstrated. These have been agreed together with the teams and are part of continuously improving the products and services.
The assurance framework should:
- turn governance into engagement
- have external assessors and subject experts be part of the team
- hold regular, short and challenging forums with the right people
- make sure that improvement is continuous, baked into the ways of working
- understand the implementation details of continuous integration and test-driven development
- ensure that the team regularly seeks and acts on user feedback
- seek to avoid stop-start and promote the flow of value delivery
- promote the use of standards over box-ticking exercises
Example:
7. Behaviours matter more than documents
Documents exist and they’re important but typically agile teams produce less long-form documentation. Progress is recorded in user research notes, blog posts, weeknotes, test harnesses, release notes, verifiable metrics.
By regularly observing team behaviours an assessor should:
- witness and understand how the team collaborates
- regularly see demo’s of working, valuable products and services
- witness motivated individuals, driven to deliver the right thing
- see how a team responds to feedback and how that impacts improvements
- see that a network of relationships exists with other teams, groups, communities
- ensure that the team is multidisciplinary and has the skills it needs
- make sure the subject experts and business are embedded and engaged
- understand the inner workings of the team’s quality controls
- stakeholders are involved and providing intelligent challenge
- hear the team talk about risks and how they are dealing with them
- see how blockers are communicated and removed
8. See delivery for yourself
Teams should talk about work in progress by showing work in progress every week or fortnight. These events are usually called ‘show and tells’ or ‘showcases’. For sponsors, stakeholders and assessors this is a time to see the thing take shape, raise any questions, and support the team. A team’s ‘Show and Tell’ is an essential part of their rhythm and is a key governance moment.
Everyone committed to achieving an outcome should:
- attend and promote show and tells
- regularly see user research sessions
- be able to see working software, product or service
- not be afraid to challenge
- offer support and remove blockers
- use the thing – especially sponsors
- not expect a status report because you cannot make it
- walk the team walls
Jamie Arnold
Head of agile delivery
Jamie this sounds really important to the Coop Member’s Council. Will you be at Federation House on Friday Feb 24th at 10 am when the Council Digital Working group has (finally) been invited to see for ourselves how and what you are all up to ??? Hope so 🙂
Happy to chat about it Barbara. I’m not about on the 24th, but contact me on my coop.co.uk email and we’ll arrange something for another time.
…but don’t fuck up the culture http://scottberkun.com/2014/critique-dont-fuck-up-culture/
That’s a great link Anthony – thanks for sharing. “Culture is emotional”
This is great Jamie! I have a feeling I’ll be referring to this often.
This is really useful stuff, and very timely as in Wales we have the Wellbeing of Future Generations Act looking to embed long term change beyond tickbox exercises. The Wales Audit Office will need to audit the act whilst thinking about outcomes rather than outputs, so this is a really useful framework to hang some of that on. Cheers!
Dyfrig
Very “content-rich” article.
The links yield some further great insights – not just applicable for a digital team.
Wouldn’t it be great if we could have this statement from Spotify above the door to every boardroom :
“Leader’s job : Communicate what problem needs to be solved. And why.”
“Squads’ job: Collaborate with each other to build the best solution”
https://spotifylabscom.files.wordpress.com/2014/03/spotify-engineering-culture-part1.jpeg
As Chair of the recently established Audit & Risk Assurance Committee of the Future Generations Commissioner for Wales, we are looking to develop a new approach to governance, risk management, assurance & audit. Your blogs provides some really useful pointers to a more agile approach based more on behaviours and actions and less on systems and processes.