Building what’s useful: governance and agile delivery

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.

goverance-as-blocker-jpg

 

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:

 

agile_gov_v2_ol

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:

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

Moving to continuous delivery

I joined the Digital Engineering team in February as the Principal Service Manager. We’ve had a busy few months designing how we’re going to run the new digital services, the first of which being the Local Causes application website which forms part of our new Co-op Membership.

Picture of Michaela - Principal Service Manager

 

A different way of working

Coming from a background of traditional IT systems with on premise infrastructure, I knew from the moment I walked onto the 13th floor of 1 Angel Square that I’d have to start thinking differently. Every wall, surface and window was covered in sketches, Kanban boards and post its and the floor was buzzing with energy.

Picture of a Kanban board.

As a service team, our job is make sure the systems and services keep running, whether that’s by handling incidents, tackling problems or making sure that changes don’t cause outages or new issues. And that last one has been one of our biggest challenges. In the new digital teams, the pace is much faster than anything we’d been used to. Previously we’d been used to handling one or two big changes a month. The digital teams were aiming to release daily  – we needed a different way of working.

Our Challenge

The systems are quite complex with lots of different moving parts using lots of different technologies. Some front-end components like the website are built using new tools and technologies that build in automated deployment and automated regression testing. Other components down the stack are slower moving – they haven’t been built using these tools and require more manual intervention. We needed to build a change process that didn’t cause a bottle neck to releasing new features but at the same time would give us enough assurance that changes to one component weren’t going to cause issues up and down the stack (and at the same time making sure we’re not drowning in admin that doesn’t add value.)

Whilst we’re still keeping in line with the Co-op’s core change policies, we’ve tweaked the way we work to enable us to handle the higher volumes of change. At the moment whilst there’s a lot going on, we’re having daily Change Approval Board (CAB) meetings to make sure representatives from each of the components are aware of the changes going on across the whole  ecosystem. This way we’re catching any potential conflicts and we’ve seen some great challenges between the teams to make their changes safer by improving their testing or deployment approaches.

We’re trialling different ways to make sure everyone knows what’s going on, from post-its on a whiteboard to venturing into the world of chat ops with a shared calendar integrated into a Slack channel. And as we go, we’re collecting feedback from all of the different teams – What’s not working? How can we make it more efficient? How could we tackle the admin differently?

We hit a great milestone this month – over 13 days we hit an average of one successful deployment a day to the Co-op Local Community Fund. Whilst we’re not quite at full continuous delivery levels yet we’ve learnt a lot in getting this far.

Michaela Kurkiewicz
Principal Service Manager