Agile Delivery

Using guiding principles to communicate user research findings on quick commerce 

Co-op

Co-op first started an e-commerce service in 2019 and rolled out delivery nationwide during the pandemic. Ever since, we’ve been trying to find out more about why people use this service. In 2023 the Food customer experience team started to focus on quick commerce. 

Quick commerce means something different to each customer. Our insights told us that some customers think delivery within one day is quick. Expectations in city areas can be much faster than that and closer to 2 hours.  

When we carried out our user research, translating our findings into guiding principles helped us to explain these needs to colleagues. We could then build and design the customer experience using these principles. 

Research focus and approach 

Speaking to users regularly has given us a strong understanding of their motivations and expectations around rapid delivery services. We have also learned about how behaviour differs depending on whether people are doing a big shop or looking for products urgently.  

All the research was remote, which allowed us to speak to customers from across the country. We did comparison studies, gathering feedback on prototypes and co-creating journeys with participants. This allowed us to understand more about how rapid grocery delivery services fit into our customer’s lives. 

Why we created guiding principles  

After analysing the research observations, it became clear that our usual approach to communicating the findings would not achieve our goals. Summarising the key insights would help us to understand what we’d heard, but not how to apply these user needs to the redesign of Co-op Food’s online experience.  

Colleagues recognise the importance of user research, but it is sometimes hard to know how to apply the insights to our day-to-day work. It was important to think about how to make it easier for everyone to digest what we’d heard in research and think about how it impacts our roles. 

It’s also easy for Miro boards and presentations of research findings to get forgotten about when we are often working remotely. 

The research findings were going to be vital for setting direction across the team, so we created a set of ‘guiding principles’ to communicate our findings. 

How guiding principles work 

The principles: 

  • have brought the team together around a shared problem
  • are actionable 
  • are memorable and easily referenced 

Guiding principles felt appropriate because they relate to different types of customers, across different shopping situations. They are different to traditional personas which focus on a single group of people and are not always flexible across different situations.  

“I think you’ve highlighted a real problem in the research space, creating TANGIBLE outputs”

Suhail Hussain, Lead Interaction Designer

 How we use the guiding principles  

Lead Interaction Designer, Sam Sheriston, designed a set of posters to illustrate the guiding principles. We printed some and put them up in our team area and regularly pin them to Miro boards to keep them in mind. 

The team are using the guiding principles in different ways. Our: 

  • designers use them to inform ideation sessions and the development of new digital experiences 
  • engineering leaders use them to communicate about the level of service we want to achieve 

We also use them alongside data and testing to make sure we’re doing the right thing and used them to present work to the Co-op board. 

“The design principle ‘seconds count’ was just referenced in the huddle, totally unprompted and not even part of a customer products update. That is success! Influencing people’s day-to-day language takes time but is so powerful.” 

Elise Nollent, Principal Delivery Manager
They’re on the wall in 1AS

How guiding principles are helping our customers 

The guiding principle ‘be upfront’ influenced us to explain additional charges to the customer in a clear way. 

When we thought about what ‘tell me how I could benefit’ means we added more content at the start of the journey, explaining why we need the customer’s postcode, and what the service is. 

The principle ‘don’t distract me’ guided us throughout the design of the customer’s journey.  We made sure we kept the customers main task in mind and focused on helping them to get from the start to the finish in efficient time. 

What we learned  

Guiding principles can be a great way of keeping user needs front of mind. They’re a visual way of representing what we’ve heard in research and keeping everyone on track. 

It’s not easy to leave out the details of our findings when we’ve spoken to so many customers and found out so many new things. It is tempting to want to say more, but keeping these principles short and snappy has had a huge impact on the focus.  

The principles are memorable, easy to remember and have become a natural way for us to talk about our customer’s needs. It’s also easier for designers to reference the guiding principles throughout their work. 

The team now use slimmed down components in Figma files to back up rational on design decisions

 
How you could use the guiding principles: 

If you work within Co-op’s Food business, you could think about how the guiding principles apply to your area. They’re relevant to all stages of the customer experience. 

If you’re a researcher or designer, how could you communicate your research findings in a more compelling way? How might you ensure that they are actionable and help colleagues to make decisions that benefit your end-users? 

The app and offers team have already taken inspiration and created a set of principles for designing interactive games for Co-op customers. 

Vicki Riley, Principal User Researcher 

With special thanks to Sam Sheriston, Lead Designer, for designing the posters   

More information on topics in this blog post:  

How user-centred design reduces risk for colleagues and our Co-op 

Matt Tyas

We’ve followed the Horizon Post Office scandal with empathy for everyone that it has impacted and is still affecting. It’s clear that the postmasters and their families were failed on many levels and we cannot address them all here.   

Looking at it from a digital technology perspective, it shows how important it is to build systems using user-centred design. Working in a user-centred way plays a valuable part in designing the right solutions for colleagues and customers. Listening to them, and questioning technology and processes, provides confidence that you are meeting their needs. It also mitigates the high-level risks and consequences of not testing or having active and open feedback channels. 

How we work in product teams to understand user needs  

User-centred design is based on understanding the tasks users need to perform and the environments they are in. It reduces the potential for us to negatively affect anyone who interacts with the Co-op.

We have specialists within our teams that make sure that our services are user-centred and delivering value to the Co-op. That value could be commercial, or creating efficiencies in how we work. 

Although skills often overlap, each specialism is an important part of a product team. Collaboration between disciplines helps us to consider everything within a user’s experience and design the right solutions. 

User researchers 

User researchers talk to the users of our services and provide insights to help the team make decisions. They empower team members and stakeholders to fully understand user needs and build confidence through testing. User researchers also help to identify and mitigate any problems with our services.  

Interaction designers 

Interaction designers are sometimes known as UX (user experience) designers. They help create accessible interfaces and consistent user experiences to solve user problems.  Interaction designers do things like sketching, creating digital prototypes and producing digital designs for a product or service.

Content designers 

Content designers create and organise information in the clearest way to help users complete tasks. They work closely with user researchers, interaction designers and engineers to make sure the content is accessible and easy to understand. 

Service designers 

Service designers design the end-to-end journeys of our services. They help teams to think about all channels to help users complete their goals. They align their work with business needs and measurable value. 

Product managers  

Product managers focus on the product vision, providing direction on objectives, strategy, the Co-op’s goals and wider market. They help to assess the value of work, prioritising it into plans that meet the team goals and contribute to sustainable growth.

Product owners  

Product owners translate strategy and objectives into tasks for designers and engineers to enable the team to deliver the product. In smaller product teams the product manager will also perform the duties of the product owner. Both roles work strategically and need to communicate with the team on how to achieve goals.  

Delivery managers 

Delivery managers enable their team to build and iterate user-centred services. They remove obstacles to progress, helping the team to explore better ways of working and deliver outcomes more effectively. 

Engineers 

Engineers craft the code that makes our digital products work for our users. Our engineers build software with users in mind and follow standards to ensure people have the best experience when they use our products. 

Quality coaches 

Quality coaches embed quality into every stage of product development, working with product, design, delivery and engineering specialists. They take a risk-based approach to tackle any problems early and deliver a high quality product or service.

Subject matter experts 

We work closely with the people who do the jobs we’re designing for (or the customers they serve). They are the experts, and we listen to their expertise and experiences, often co-designing solutions with them. 

Supporting teams 

At Co-op we take a service-first approach and the technology teams that support us make sure that our digital products are secure, robust and accurate.  

Why we start small and iterate  

We gradually improve products and services over time, which is sometimes called an ‘agile’ way of working. By using quick cycles of experimentation, learning and releases we can deliver value early and change direction quickly. If we learn something new about our market or spot any problems, we can fix it straight away and build everything else around a solid foundation.  

We define the most important features first, then work on the less important features over time. 

How we test to help us learn and improve  

We test to validate new ideas or create a better solution to an existing service. We use mock-ups, sketches, and other low-fidelity visuals like coded prototypes. By testing early, we can develop onto higher fidelity versions and products with more confidence.  

When we release products early and often, we reduce the risk involved in complex solutions. We also create value for Co-op and our customers or colleagues sooner. We test results consistently to see what’s working and what needs to be better. 

Why we collaborate and empower our team members 

We value collaboration and empowerment across teams. A product team owns their product and should be in full control of making changes to it.   

We collaborate closely with other teams and stakeholders to make sure that we’re considering all the factors that influence a product’s success.  

This means decision making sits closely with the experts of the product and its users, so that we can move quickly and gain the most value from our time. 

How user-centred design helps us avoid mistakes 

We make a minimum version of our work live as soon as we’re sure that it is working for our colleagues and customers. If a simple version is working well and doing what it needs to do, then we can build additional features on top.  

Fixing problems early or before we make something live, also helps us to save time and money. We avoid the expense of making changes on a higher fidelity product later. Most importantly, we minimise exposing our customers and colleagues to systems that impact them negatively or cause them harm. 

At Co-op we always want to do the best we can for our members, customers and colleagues. User-centred design is an important part of making sure we do this for our digital products and services.   

Thank you to the Content Design community and Customer Products team for their collaboration on this post.

Matt Tyas – Head of Design.

More information on topics in this blog post:

Lessons learnt by a non-digital colleague: the benefits of agile ways of working

Co-op1 Comment

Last month we introduced ‘Visit’ to 55 Co-op Food stores. Visit allows store visitors to efficiently, and independently, check in and check out on store tablets or customer till screens.

We began designing Visit in October 2018. Below is a photo of me setting up an early alpha test in store.

Photograph of Nick, middle-aged man wearing a smart coat and shirt holding a paper sign saying 'Visits' above a tablet with the Visit product on there.

Visit is in beta right now meaning that our research and testing are ongoing and we’re making small improvements regularly. We’re hopeful that we can roll it out to all Food stores by autumn and that it will save time and solve efficiency problems.

But this post isn’t really about how we went about researching and prototyping a new product. It’s about the processes and practices associated with agile – a way of working that was unfamiliar to me and many of my immediate colleagues. It’s about the benefits of working in this way and why non-digital teams should be collaborative, open-minded and committed to learning about, and designing for, their user.

The problem: a long, old process

I work in the Risk team. Visits to a store are frequent and essential, and as part of my role I saw a lot of inefficiency when it came to signing in store visitors. The process would often be:

  • ask a colleague at the till for the visitor book and a pen
  • fill in your details
  • listen to the colleague to explain the store fire process
  • wait for a manager to take you to the back office
  • sign on to the PC
  • read the asbestos report
  • sign a paper acknowledgement of the report in the health and safety folder

It shouldn’t have so many steps in the process. It shouldn’t take this long. It shouldn’t involve so many people.

Our Field risk team regularly visit stores to train management on health and safety controls. As a result of the complicated, long-winded visitor flow, this was one of the least followed processes. There was also a lack of visibility around who has visited, so on occasions third parties have claimed to have visited a site but there is no evidence they have been.

I wasn’t the only one who wanted to improve this process.

Learning new skills and different ways of working

At this point, my knowledge of digital design was limited. I knew that digital product Shifts was co-designed for Co-op Food colleagues, and that other pieces of the Leading the way work relied on expertise from Digital, Food colleagues at support centre as well as Food colleagues in stores. I was aware that this coming together of specialists had been successful within the Co-op before.

I signed up for the Digital masterclass, a half-day training session that helps colleagues whose skills are outside digital understand how the Co-op Digital team works (more information at the end of the post). Richard Sullivan who ran the training introduced me to the benefits of agile ways of working.

Getting support

I’d identified the problem around checking visitors in and out but to fix it I needed expertise from the engineers from Retail IT as well as the Digital team including delivery managers Lee Connnolly and user researcher Rachel Hand.

Together, we started to learn more about the problem.

Putting theory into practice and learning more

Working on this project in an agile way, in a multidisciplinary team was very different to how traditional teams would tackle it. That includes the Risk team I’ve been part of. It was a sharp learning curve.

Here are 3 reasons why:

1.Testing over requirements

I’d been used to handing over a list of requirements to a technology team and asking them to find or create a piece of software that might fix a problem. For Visit, we put paper prototypes in front of store colleagues as soon as we knew enough about the problem. Their feedback helped shape the design meaning the product was tailored to their specific needs rather than it being an off-the-shelf solution.

2.Questions over assumptions

I approached the problem (the process of checking visitors in and out is inefficient), with a solution (so we’ll put software on store tablets to make it better). It seemed such an obvious solution to me (and in the end this is in fact our solution) but the Digital team showed me the dangers of assuming rather than questioning. We did an ‘assumption mapping’ session which helped us see if or where we were making assumptions about the desirability, feasibility of the product. Identifying assumptions reduces risk.

Photograph of a whiteboard with many yellow post it notes of notes arranged across a grid. This is an example of assumption mapping. 

3.Build in team time

I’d never worked in a team where we’d schedule regular time to reflect on our progress and our team health. This is what retrospectives are for. Until now, praise and problems were private – not something a team could be part of together. I didn’t realise how essential I’d begun to consider retros until we had to cancel one.

Progress through collaboration and thinking differently

Despite this being my very first digital product, I feel I can say with confidence that when Visits rolls out to all Food stores later this year, it will solve problems and meet our store colleagues’ needs. This is because the product is design-led. We were never tied to a solution, we changed our minds as we learnt more and our understanding of what store colleagues need improves.  

If you recognise opportunities for operational improvement, no matter which team you’re in, you can speak to Chris Ward, Product manager for Operational Innovation Store. You can also email Richard Sullivan to arrange a place on the Digital masterclass.  

Nick Bullough
Product owner

Introducing local.co.uk – Co-op’s new marketplace

Co-op

We’ve recently launched local.co.uk – a marketplace that connects independent businesses to customers across the UK. We’re doing this because we want to give small businesses a fairer way to trade and help make communities across the UK stronger.

We built the service in 13 weeks and we’re proud of what we’ve achieved. But we know it’s far from perfect – there are parts of the service that could be smoother and features that we want to improve and introduce.

We launched it when we did so that we could learn quickly from real users and make the service valuable for them.

We’ve done a lot and learnt a lot.

This video shows how we created local.co.uk (2 minutes 26 seconds) 

We’re trialling an agile immersion course for all colleagues

2 Comments

Tuesday was the first session of the agile ‘immersion’ course – a free training course, put together and delivered by the team to help colleagues not working in digital experience agile working in a multi-disciplinary team.

The immersive nature of the course helps the team work collaboratively and aims to build on the foundations set by the Digital Skills Masterclasses which are more theory-based.

During the course, the group apply agile techniques and rituals to projects they’ve researched and selected. The course ends with colleagues showcasing their learnings at a show and tell in front of Co-op Digital’s heads of practice.

photograph of 4 colleagues on the course

Co-op Digital colleagues can help

The group is also required to work together outside of the sessions, with additional support provided by Digital colleagues. We’re looking for people across the communities of practice to help out with mentoring. If you have a spare 30 minutes a week for the next 2 weeks, get in touch with me.

Opening up opportunities in Digital

Since being seconded and then permanently employed by Digital last year, I’ve thought a lot about how to open up opportunities for non-Digital colleagues to experience agile ways of working, without taking time out of their day-to day-roles.

My hope is that after experiencing working in this way, colleagues would feel better equipped to:

  • introduce new ways of working to their teams 
  • apply for roles in the Digital team

We’ll listen and observe, then iterate

10 colleagues are enrolled on the trial course, all from our Support Centre in Manchester. We felt it was important to start learning about what works and what doesn’t as quickly as possible so we can make improvements and schedule another course early in 2018.

This time, the course runs 2 evenings a week for 3 weeks which means that it doesn’t interfere with day-to-day roles. Moving forward, the hope is we’ll be able to open it out, have more convenient hours and include colleagues from further afield.

The groups show and tell will be on 7 December at 12pm in Federation. Come along to see what we’ve learnt.

Annette Joseph
Delivery manager

Warning! Your MVP may cause discomfort (but it’s worth it)

Co-op

We recently posted about how Co-op Digital and the Co-op Legal Service (CLS) combined their digital and legal expertise to build a service that makes it simpler to get a Co-op will. Together, we built something that’s both legally robust and easy to understand. In other words, it meets the needs of our customers.

But bringing together 2 contrasting ways of working so we could deliver this was tricky. The challenge was wider than combining the 2 disciplines. It involved building trust in the agile way of working with the wider Co-op business.

We start small

The digital team works in an agile way. Part of being agile is about getting value to your user as soon as you can through a minimum viable product (MVP). This means building the smallest usable thing that might be useful to them. Then, you watch how real users interact with it, listen to what they say about it and iterate and improve quickly based on what we learn from research.

Being perfect’s not the point

Releasing an MVP helps us build something useful at each stage of delivery and it’ll help us build the right thing. The point of working in this way is to avoid building and overspending on something that doesn’t meet user needs. So, releasing an MVP actually makes sound business sense.

But it takes time to learn about the needs of your users which means it takes time to build the best solution. This is a daunting process for anyone who isn’t used to working in this way, because an MVP is very rarely pretty.

In fact as Reid Hoffman, Founder of LinkedIn says:

“If you’re not embarrassed by the first version of your product, you’ve launched too late.”

A reputation to uphold

When we released our MVP, real Co-op customers were going to be using it to give details about their situation and to book in a call with one of our will writers. It’s understandable that anyone who’s unfamiliar with this way of working would be nervous about releasing a product with known problems. We’re operating in a competitive environment and what if potential customers were put off by a poor user experience? What if they went to a competitor instead? Would releasing an MVP put the Co-op’s wills services’ reputation on the line?

Reaching a compromise

The biggest sticking point was that the digital team wanted to release a very stripped back version that didn’t cater for a whole customer segment. CLS had an assumption that launching such a minimal service without the option to make a ‘mirror will’ (something often used by spouses) would put potential customers off.

As David Bland says in his post Spruce, the corporate minimum viable product:

“The challenge with a minimum viable product is that you decide what’s minimum, but the customer determines if it’s viable.”

The digital team had to trust CLS’s judgement on their customers and release something more developed than we might usually expect an MVP to be. We were happy to do this because we knew we could learn lots from doing things this way.  

Understanding each other better

The more the 2 teams worked together, the more the trust grew. CLS came round to the idea of releasing an MVP (or something close to one) after we explained:

  • it’s possible to iterate to fix any customer concerns in a matter of days
  • we could ‘turn off’ the beta instantly and we could also control the traffic to the online version and only allow access to a small percentage
  • the phone call part of the journey could act as a backup and we could help customers over the phone if they had any problems online part of the service

Data-driven decision making

Once we’d launched there was a mindset shift in the team and the wider business. Together we looked at data and tied that to user research instead of relying on assumptions.

Tracking user behaviour with analytics tools really helped confirm that releasing as early as possible was the right thing to do. It was like having a window to view a customer’s behaviour and we used the data to help make decisions about the product development.

We could see at which points customers were stopping their journey and this helped us prioritise work. For example, we knew that an automatic postcode lookup feature would be useful here. It was coming up in user research regularly as something that would help smooth the user experience. However, when we looked at the data in our analytics we found that the vast majority of people were filling in the address fields manually just fine. So we decided to de-prioritise building postcode lookup. There were other areas that needed attention before this.

Taking a leap of faith was worth it

The metrics tools helped us show stakeholders and the Co-op Legal Service the connection between our product improvements and the bookings and sales. We could also show that the online business is generating a new set of customers that’s not cannibalising the original service. We knew we could potentially scale this up which is really positive from a business point of view.

In the next few weeks the digital part of the team will start transitioning over to Co-op Legal Services who will continue to iterate the product.

Find out more about Co-op wills.

Ben Aldred
Product engineer

Building what’s useful: governance and agile delivery

Co-op9 Comments

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-op2 Comments

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

Co-op

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

Co-op1 Comment

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