Agile Delivery

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

Setting up communities of practice

Co-op4 Comments

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

Co-op5 Comments

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