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

Attending the Digital Masterclass

Last week I attended the second Digital Masterclass. It’s a half-day session aimed at giving us all one consistent way of understanding digital ways of working –  what we do, how we work and better practice.

I’ve been at the Co-op for 11 months, 9 months leading the transition to our new look in our Food business and the last 2 working in the Digital team.

Picture of Jen Farmer
Jen Farmer

The move to our new look was date led and governed by more traditional project management methodology. After the launch I was asked to work within in Digital team, an opportunity I was really excited about, but a little nervous too. I imagined a world inhabited by people far cooler than me where plans or milestones didn’t exist. This is probably a common misconception and the reality is very different.

I had lots of questions. I had no idea what the difference was between a delivery and product manager, or how to work in an Agile way.  In my first week Wikipedia became my new best friend.  What I really needed was some kind of training on how to deliver successfully in an Agile way.

The masterclass isn’t just for people who are new to digital, it’s for everyone. It’s great to have a mix of new and more experienced colleagues so everyone can get the most out of the session.  There’s nothing more valuable than hearing people’s real life experiences of projects they’ve worked on (the good and the bad). During the class you get the opportunity to reflect on your own experience as well as listen to those of the experts across our communities of practice.

Picture of the second digital masterclass at Co-op
Amy Wagner sharing the Agile principles

The day was also really good for meeting colleagues from the digital team who I recognised but  had never spoken to before. I now know a few more people to call upon when I need help outside of my area.

So what did I learn? The biggest takeaways for me being the different methodologies in Agile, how we practically apply them and how we’re using Agile to deliver some great things in the Co-op.  I also learned that a game involving Lego brings out the competitive side in everyone and 2 minutes is not enough to build a Lego house (bit of advice if you’re going on the course – start small).

Picture of the second digital masterclass at Co-op
Jen Farmer (centre)

So my verdict, regardless of if you are new to digital or Agile, you’ll find these sessions useful. Even if you’re in a role where you think you don’t directly need to use these skills, understanding how the people around you work will be useful and will make us stronger.

Jen Farmer

Digital ways of working

Last week we held our first Digital MasterClass. We’ve talked a lot on the blog about the different ways in which we’re working in CoopDigital, Jamie’s post on agile delivery is a great example of this. We’ll continue to blog about how we’re working differently, but we also want to find other ways to share what we’re doing with all our colleagues.

Why would we want to share our ways of working? We’ve found that generally speaking, teams and organisations that adopt agile ways of working have a better chance of delivering the right thing, are happier and more collaborative. It’s perfectly suited to an organisation built on co-operation and doing the right thing for its people.

The first session was a pilot with the objective to provide an overview of digital and agile ways of working whilst gathering lots of feedback from attendees.

Picture of the first Digital masterclass

Anna Dick, Tom Taylor, Amy Wagner and Carl Burton all shared their experiences on topics including;

What is digital?
The habits of behaviours of successful digital businesses
Agile ways of working
Life as a product manager in CoopDigital.

We’re initially providing these sessions for colleagues in CoopDigital and will consider opening these up to other areas of Co-op in the future. The team are looking at lots of different ways for us to share experiences both internally and from people externally who we could learn a lot from. We’re trialling, learning and improving as we go.

We’re now reviewing the feedback to help us develop and improve the content and format for more sessions. We’ll also be talking with colleagues in our Group Transformation team about their work.

Picture of Jenni Moss - Delivery Manager

Jenni Moss
Delivery Manager

Wills Alpha

A small multi-disciplinary team at the Co-op have been working to rethink Wills. Mike promised at the AGM that we would talk openly about what we’ve done. This is a post about our 10 weeks working on an ‘Alpha’ prototype and what we’ve learned.

Wills are interesting

I never thought I’d be writing those words but Wills are interesting.

Over half the population die without a Will and these people don’t get a say over what happens to their property, possessions and children when they die. No Will means a mess for family and friends to clear up at a time of stress. At best this leads to confusion and at worse family breakdown.

And even though people know a Will is worth doing and most people say they’ll get round to it, procrastination is normal. In other words, what people say they’ll do and what people actually do are completely different.

Why do people do that?

Part of the reason behind this apathy is that people don’t like to think about their own death – which is understandable, but there are other factors too.

Most people do not understand the language and concepts used in a Will.  Even those people that sit down and think “I’m going to do this” end up baffled by, and lost in legalese. They start the process, then stop when they come up against a barrier.

Then there’s the practicalities. Overwhelmingly people want to speak to someone to get advice and the reassurance that they’ve done it right. Usually that means trips to the local solicitor’s office, maybe some time off work, form filling, and a couple of hundred pounds for a document that gathers dust in the filing cabinet upstairs. That doesn’t feel like a good use of people’s time.

These make for some really interesting service design challenges and there’s a lot that can be improved about Wills. By applying the culture, practices, processes and technologies of the Internet-era we hope to do just that.

Wills Blog Image

10 people, 10 weeks to build an Alpha

For the last 10 weeks a small team of developers, designers, lawyers and user researchers were given space to explore Wills. We used agile ways of working to build an early prototype version (an Alpha) and test it with real people.

Mobile screen shot of Wills alpha

Mobile screen shot of Wills alpha

Mobile screen shot of Wills alpha

Mobile screen shot of Wills alpha

 

The purpose of creating an Alpha is to learn about the problem space, learn how to work together as a team, test our assumptions and to build confidence in delivery.

Designing for humans

Every two weeks we delivered working software and put it in front of six or seven people (in the market for a Will and not connected to the Co-op) to observe what they did with it. We asked them questions like “what do you think happens next?” and where we reached the edges of what we’d built we used paper prototypes or mocked-up service.

This helped us better understand people’s actual needs, fears and motivations – even when they were only using a partially developed service. Our user research taught us things that we would have missed had we specified a solution up-front. For example, we learned:

  • People want advice when they need it. They want a Will that is right for them, not just any Will. This may seem obvious, but it is visceral and trumps convenience. People want to talk it through and in this respect, conversations are reassuring and remove some of the fear of Wills.
  • Some people want a Will immediately, others want to go away and think about something or ask some questions. In other words the service needs to be designed to go at people’s own pace.
  • People’s expectations have changed. People no longer understand why they can’t update a Will when they want to, or why it is such a long winded process described in arcane terminology. People want the process to be robust but also more modern and accessible and for it to change as their lives change.

Onwards to Beta

Agile ways of working allow teams and businesses to experiment with new service ideas quickly and cheaply without needing to specify the problem and the solution up front (you can’t and you shouldn’t) or needing to commit to plans based on big, up-front assumptions. Our sponsors gave a small multi-disciplinary team a problem to solve and allowed us the space to work it out.  They empowered a team to learn and experiment. This means happier team and we think, better product.

We’ve now been given permission to develop a public Beta of the Co-op Wills service so you’ll hear more about this in the next few months.  We’ll share more about that as we go along.

Jamie Arnold

 

 

We’re looking for Delivery Managers.

I joined The Co-op at the beginning of the year as Head of Agile Delivery. It’s my job to help The Co-op get the most out of modern ways of delivering its services, so that:

  • It’s quicker to deliver and test them with real people.
  • They’re more responsive to feedback from the people that use them.
  • Teams self organise around continuous improvement.

Generally speaking, teams and organisations that adopt agile ways of working have a better chance of delivering the right thing, are happier and more collaborative. It is perfectly suited to an organisation built on co-operation and doing the right thing for its people.

By giving a group of people authority to solve a problem we've made them feel stronger and more confident

Since joining I’ve been doing the rounds in The Co-op to explain it in more detail and how other teams can adopt this mindset to delivery. Some teams are already on their way, but others need help.

The conversation goes something like this:

“Can you help Jamie?”
“Yes, of course. You probably need a Delivery Manager to help get you going.”
“What’s one of those? We’ve got project managers. Is that the same?”

At which point I usually share this excellent post by Emily Webber explaining the role of a Delivery Manager, because the answer is, it is different in important ways:

“It describes the person on the agile team whose main concern is enabling a team of skilled people to deliver value. They create the right environment for the team. They facilitate the team and remove obstacles and blockers that might get in their way. They work closely with the product manager (sometimes known as product owner), but while the product manager is concerned with the vision the delivery manager is concerned with making it happen. The perfect visionary and doer pairing”
Emily Webber

Have a read of the post and if you’re that person and have the right experience then get in touch. It’d be good to hear from you.

You can see more information about vacancies for Delivery Managers on our career site.

Jamie Arnold
Head of Agile Delivery