OVO Tech Blog

Can we Kanban?


Amy Halford

Amy Halford

Product Manager at Kaluza

Kanban Kaluza Onion Product Management

Can we Kanban?

Posted by Amy Halford on .

Kanban Kaluza Onion Product Management

Can we Kanban?

Posted by Amy Halford on .

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:

  • current performance of cycle time and throughput should stay the same, or improve — we don’t make things worse
  • team happiness — switching to Kanban doesn’t make teammates less happy than using Scrum

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

  • There was more focus on keeping epics small: breaking them into more manageable pieces of work with better representation of the value they would deliver.
  • We were working on fewer epics at any one time, with more focus on finishing an epic in progress before moving onto the next one.
  • We loved using Jira’s combined Refinement & Delivery Cycle Time Kanban Board, it helped focus our daily standup discussions and reduce noise from our backlog.
Our refinement and delivery Kanban board

Increased efficiency

  • Just In Time refinement, often daily, helped us reduce time wasted on refining work we wouldn’t pick up straight away and gave us more time to spend refining epics and planning long-term.
  • It felt like we were using our time more effectively and having more of the important conversations about our team’s strategy and solution design.

Better collaboration

  • Engineers were spending more time pairing with each other on refinement, solution design, and code review.
  • More transparency and balance as we were sharing information and challenging each other more openly.

Happier team

  • Having a continuous flow of work felt more sustainable, no more last-day-of-sprint dash to complete work in time, possibly compromising on quality to get things done.

More flexibility

  • By having less “planned” our team could be more reactive to changes

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...