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

What we mean when we talk about a ‘minimum viable product’

Co-op Digital is helping the wider Co-op transform its business by building digital products and services. We know some of our readers have an interest in how technology and digital skills can help businesses but if they’re not part of that digital and design community they’re unlikely to be familiar with some of the terms we use in our blog posts. Soon, we’ll be publishing a post from the wills team on their ‘minimum viable product’ so it’s worth explaining this particular term now.

‘Minimum viable product’ or ‘MVP’ means slightly different things to different people and organisations but here’s what we mean when we talk about MVPs.

Defining ‘MVP’

At Co-op Digital we work in an ‘agile’ way to deliver software because we believe it’s important to give the user value, quickly. Part of working in an agile way is releasing an MVP to help us learn what’s working and what isn’t so that we can improve products quickly, cost-effectively and without needless risk or waste.

An MVP isn’t the first release of a big concept made up of smaller features. It doesn’t come with a plan to add more features in the next iteration whilst also trying to fix features that don’t work. It’s not the final product either.

To us at Co-op Digital, an MVP is the first attempt to solve our users’ problems. It’s an experiment. It’s the smallest ‘thing’ we think could be valuable to our members, our customers or other users. We then grow that thing based on the feedback we get from real use, by real people.

What’s the ‘minimum’ bit?

We want the most meaningful feedback and to do that, the product that users see must be real. But if we release loads of features at the same time it becomes difficult to work out which part of what we built was useful and which bits weren’t.

Des Traynor uses this graphic (adapted from a Peter Merholz presentation) to explain MVPs on the Intercom blog. It’s a good analogy to help explain.

image split into two parts. part 1 shows a cake base, cake filling and icing. part 2 shows a cupcake, a cake and a wedding cake

If our end goal was making a new kind of wedding cake, we might first test with a simple cupcake. We’d include just enough features to maximise our learning. We could get it into people’s hands so they could taste it and we could check the flavours and uncover any problems in our factory. With the feedback we’d get, we could then iterate quickly, safe in the knowledge we have the right ingredients and that our oven works, and so on. At each iteration we are providing value to the customer (cake to eat) and value to the business (cake to sell). We’d do that rather than try to build the wedding cake straight away.

In other words, building an MVP is about doing the least to learn the most.

Quick feedback, efficient improvement

Starting small means we can get a tangible product in front of users quickly, and start to observe, analyse and measure quantitatively and qualitatively. Getting started as soon as possible helps us quickly create a feedback loop that can prove or disprove our ideas for how to improve the product.

Starting with an MVP is a proven way to make the best use of an organisation’s effort and maximises the value for members, customers and other users. Best of all we’ll know the thing we’ve done works, before we invest in building it.

Ben Aldred, product software engineer

Lean Agile Manchester

This month we welcomed Lean Agile Manchester to our support centre at One Angel Square for the first time. This meet-up ran by Ian Carroll brings together local Agile practitioners from around Manchester and the North West.

Picture of Lean Agile Manchester Meet up
Lean Agile Manchester

The evening started with Tom Loosemore, our Digital Services Director. Tom shared his experiences of introducing an Agile mindset and ways of working to more traditional organisations. It was a really insightful talk on some key learnings he’s made along the way.

Tom Loosemore presenting at Lean Agile Manchester
Tom Loosemore

The night was complimented by some great lightning talks. Gemma Cameron updated us on the upcoming tech events in Manchester.  Ruta Blazeviciute spoke about the importance of changing organisations from the inside. Kevin Rutherford shared with us why it’s critical to bring your developers along on any agile adoption journey.

I closed the night with a brief introduction to an estimating technique that Kevin had introduced to me a few years ago.  Rather than guess the estimate for the story, Kevin’s technique challenges the story to fit into the time and collect data that can be used to relatively size for future items. Keeping the stories small also ensures you’re not spending lots of time estimating work you may never do if priorities change. 

Picture of Anna Dick speaking at Lean Agile Manchester
Anna Dick

Thank you to all the speakers and to everyone who came along.

We’ll be hosting future Agile events in 2017, we’ll share them on Twitter nearer the time.

Anna Dick

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

Setting up communities of practice

This is a post about setting up a community of practice and why this is a good thing for organisations embracing agile ways of working.

Setting up a community of practice

In the early summer a group of us, herded by the brilliant Emily Webber, took a day out to talk about setting up a community of practice for agile delivery people.  We recognise that in a networked, progressive organisation of small and agile self-directed teams, there is a role for these communities to act as the glue across teams and the wider organisation.

Communities of practice: “… groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly”  Etienne Wenger-Trayer and Beverly Wenger-Trayer

We wanted to create a community that:

  • could evolve naturally – for its members and by its members
  • was a safe space for open dialogue and learning
  • allowed different levels of participation – there’s nothing worse than forced fun!
  • had a regular rhythm to it

We agreed our community’s mission:

Our mission is to: Inspire others at Co-op and beyond by setting and continuously improving the standard of agile, collaborative delivery

And discussed its values:

Agile Delivery Community Manifesto. We will develop a community of practice that sets and improves the standard of agile ways of working in Co-op and beyond. We will do this by: Being open and honest Encouraging and helping each other Making an active contribution Always sharing, learning and improving Not judging

It’s early days but already there’s a growing level of self-organisation and trust amongst members.  The community is sharing ways of working, practical tips and techniques.

Beware silos

To help smooth the flow of knowledge sharing everyone is encouraged to be open.  Tools like Slack, Google apps and open invites to each team’s Showcase really help spread better practice – but only partially.  

Sometimes, everyone working in a product team is in danger of being so focussed on the thing they are making, they forget that they are part of a much wider organisation. It takes extra effort to look around, to dig deeper, to ask questions about why something works in one situation and not so well in another.  Sometimes we’re just too polite or don’t feel safe asking the difficult question.

Other communities of practice are springing up too

If you wander around our office in Angel Square you’ll see the signs of agile working blooming.  There are now more than a dozen teams working in this way, spread across the business from Membership, Funerals, Food to new digital products.  

The teams share some common characteristics (usually less than 10 people, a flat hierarchy, cross-disciplinary and empowered to experiment to solve a problem) but each team works differently.  They own their process and what works for one team might not work so well for another.  That’s a healthy thing and it’s fascinating to see how different ways of working are evolving and improving.

In fact, it feels a lot like a Co-op.  

We’re recruiting now.

Jamie Arnold
Head of Agile Delivery

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

Co-op Finder Alpha

Co-op-Finder-Alpha
Co-op Finder Alpha – list results view

We’ve made live our Co-op Finder Alpha. Have a look https://alpha.coop.co.uk/finder.

If you’ve ever used our old store locator, you’ll see there are lots of things that aren’t in the new one. There’s a reason for that. We don’t know whether it was useful or not, in fact there’s a lot we don’t know. 

We’ll use our Co-op Finder Alpha to learn more.

We do know a lot of people choose to come to our website to use our store locator to see whether we are open, usually around those times when opening hours in general are not obvious, like Sunday evenings and national holidays.

We also know that the next most common thing customers need, is to know where the nearest Co-op is to a specific location. 

We’ve kept a few obvious elements, like telephone numbers and links to get directions, but other than that we’ve removed anything that we don’t have an evidenced user need for.

There are two opportunities for users to provide feedback on the experience itself and whether the information is correct, through this and further user research we will understand better what needs to be there.

We’ve already learnt a lot and have some solid improvements in the pipeline that we’ll make live shortly.

Our show & tell is part of the coop.co.uk session every Wednesday, 10th Floor, 10.15-10.45 – all colleagues and Council members welcome.

Please let us know what you think.

Ben Rieveley
Product Manager