OVO Tech Blog
OVO Tech Blog

Our journey navigating the technosphere

Amy Halford

Product Manager at Kaluza



Can we Kanban?

We recently changed from using Scrum to Kanban for managing our work, and we’d like to share our reflections and what we learned along the way.

I’m Amy, a Product Manager in Kaluza. Our team ensures we seamlessly handle our customer’s experience when they switch to a new energy company.

We recently changed from using Scrum to Kanban for managing our work, and we’d like to share our reflections and what we learned along the way.

What inspired us?

Our team dynamic had changed considerably over the course of 2020, with four new team members joining remotely during lockdown, we'd been working with an agile coach to improve our predictability. In some sprints we were only completing 60% of what we’d planned, often due to high levels of scope change.

We first focussed on improving our cycle time (how long a piece of work takes from in-progress through to released), and throughput (how many things we complete in a sprint). As a team we identified areas for improvement and improved our refinement process so we could more consistently deliver on our commitments. Our throughput rose as a result.

As our improvements gained momentum, we began looking further afield—what could we tackle next to optimise our predictability?

It felt like we were finally performing at peak productivity and it was a good time to embrace change.

Enter Kanban

Scrum forces you to be disciplined, but Kanban expects you to be disciplined.

We had many questions about moving to Kanban: would we lose the progress we’d made improving our processes? would we be disciplined enough? could we sustain our level of throughput? would delivery slow down? would the absence of a sprint deadline mean a lack of focus?

We decided we’d treat it as an experiment and see what we could learn. We would let it run for three months, defined our success criteria, and set up regular progress reviews.

Our success criteria included:

Our experiment

We reviewed our team performance every two weeks. I had expected to see an initial dip in our metrics in the first few weeks, but instead our cycle time and throughput remained consistent. Win!

Initial feedback from the team was positive too, everyone was happy. It felt like we’d made the right decision and our metrics were moving in the right direction.

Then came the dip

After two months, our cycle time was increasing, and our throughput had dropped. ‘What’s changed?’ we asked in our team retrospective. Was it dependencies outside of our control, someone in the team taking holiday, or other demands on our time? We asked ourselves if we were being disciplined enough.

We looked inward and identified two areas where we could improve:

  1. Reduce our work-in-progress, in order to reduce our cycle time.
  2. Reduce the backlog of stories that are ready to start, reducing waste and increasing our efficiency.

How we adapted

  1. "Stop starting and start finishing" — we agreed we needed to be better at checking what’s in-progress before starting new work, using standups to plan for the day. Agreeing which work to pick up next and surfacing opportunities for people to support work in progress all helped us complete work faster.
  2. Just In Time refinement — we stopped having a single session in advance for refining stories and instead assessed each story as close to it starting being worked on as is responsible. This gave us more dedicated time to focus on breaking down epic-level work, getting everyone on the same page about what we were delivering and why. This way, by the time we got to individual story refinement it was only the ‘how’ we would deliver it that we would need to refine.

These changes saw our performance improve: our cycle time decreased, and our throughput increased. Win!

By limiting our work-in-progress, we reduced context switching and increased engineer pairing. Shifting our refinement sessions to focus on epics had an interesting impact too — it forced us to make our epics smaller and better focussed on the specific value they deliver.

Kanban’s value

After our three month experiment we asked ourselves, ‘So, should we go back to Scrum?’

The answer was an emphatic ‘No way!’

The benefits

Improved focus

Our refinement and delivery Kanban board

Increased efficiency

Better collaboration

Happier team

More flexibility

Is Kanban for us?

While Kanban expects us to be disciplined, we found it to be massively valuable as a team.

It’s definitely worth giving it a go for yourself. Things to consider if you’re thinking of trying it out:

  1. Reflect on where you are as a team to determine what stage of group development you’re at, and whether timing and circumstances are right for implementing a change.
  2. Try it out as a timeboxed experiment, with a clear definition of what you want to learn.
  3. Define your success criteria. For us, it was team performance and happiness, but your team might be interested in tracking different things.
  4. Have a clear product vision and goals which are shared with your team — it enables autonomy.
  5. Tidy up your epic backlog before running the experiment; we saw some unexpected behaviour with our epic cycle time and throughput metrics due to leaving some old epics open.
  6. While you should regularly review how you’re doing against your success criteria, don’t spend too much time over-scrutinising your metrics. And don’t panic if your metrics take a bit of a bashing for a few weeks. Look for trends, rather than outliers.

Kanban isn’t a silver bullet which will solve all of your delivery woes. Our parting advice is to understand what you’re looking to learn from switching to Kanban, and how you’ll know your team will be successful with it. Let your metrics guide you, rather than define you, and find what works best for your team.

If any of this interests you, or you and your team are thinking of trying Kanban and you’d like to discuss, please get in touch.

Amy Halford

Amy Halford

Product Manager at Kaluza

View Comments