Why we moved from Scrum to Kanban

In the two short years we’ve been developing software at Skim.it, we’ve always taken an agile approach to our work. It’s not always been easy, and now more so than ever — like true Agile ninja’s — we’re questioning, testing and improving our processes.

There’s a misguided belief among tech startups that the only way to effectively manage a development team is by deploying Scrum — the poster child of Agile project management. It’s favoured by the tech elite, and has been filtering down to the not-so-elite over the last few years — as ‘best practices’ and ‘must do’s’ appear in blog articles posted by militant scrum masters.

However, at Skim.it, we’ve recently fallen out of love with Scrum. Our sprint deadlines kept slipping, motivation dropped and features got put on hold. So in an attempt to find solace in Agile, we’re converting — back! — to Kanban.

Therefore I’ve decided to write this piece to highlight the issues we’ve experienced with Scrum and why we’ve now made the decision to change.

It all started with Kanban

In the very early days, with only two developers in the company we tried Kanban. We’d recently gone through a big UX design, which spurted out a huge long feature list of backlog items to work through. Since we were so early in the products life, the list just kept getting longer and longer with no let up for Josh and Neil who were working every hour of the day, and then some.

Motivation was low, to say the very least. For myself as the Product Owner (PO), and founder of the business it was also massively frustrating. It seemed like no progress was being made, and I was irritating the team by constantly asking for updates. Something had to change.

At around the same time we’d hired three new developers, and thought if we were going to make changes to our process then now was the time to do so.

Our experience with Scrum

I spent a week looking into various best practices, trying to figure out the best approach. Eventually we made the decision to move over to Scrum. We hoped by doing this it would give us more visibility as PO’s and stakeholders, and that it would give the team more focus over shorter periods, meaning motivation and output would be higher.

The first sprint was a disaster. It was no great surprise really, given we weren’t experienced enough in sprint planning and the developers weren’t used to pointing up their stories. Inevitably, we ended up over estimating the sprint. Not all was lost however, we had enjoyed the sprint planning process, especially communicating on what work we could focus on over the two weeks we’d set. I found as a PO that I had much more control over the features we could ship, and planning was becoming a lot more straightforward as we broke down epics into sprints. Generally communication was much better and the first retrospective was extremely constructive.

So we continued with Scrum. We improved our story pointing, and introduced various changes to the sprints. Things like rules for handling technical debt and bug fixes; by taking a zero-bug tolerance approach — as soon as a bug was reported it had to be fixed. Or doing standups in Slack rather than Google Hangouts, as phone quality was poor, and we could just write down any issues and blockers.

Stakeholders were much happier, as they could see features being released, and had a lot more visibility over peoples work.

Then we started getting REALLY busy, and cracks started to appear.

At this point I should precede this by admitting we didn’t follow Scrum by the book. So I don’t think we can blame Scrum, but more so ourselves. As a small team with limited resources we couldn’t afford to have a dedicated Scrum Master. I was taking on the role of Product Owner, Scrum Master, and Project Manager, amongst 100 and 1 other roles — something most founders will be familiar with.

The aforementioned really affected the sprints more than anything. My time started to get pulled in other directions, as the business went through another funding round, and customers started to come onto the product, which also meant I was out of the office a lot.

As the PO, I had been the one doing the sprint planning, communicating with stakeholders, and I would chair the retrospectives — totally not by the book.

Now that time was so short, we’d cut corners. We’d hold a brief half hour planning meeting, which I’d already put the sprint board together for, asking developers to just point up what was on there. I started over estimating sprints because I wasn’t communicating with the team properly to understand technical complexities. I sometimes didn’t have time to do a retrospective, and there was so much still in the backlog that I would just extend the sprint by another week or two — a big no-no in Scrum!

This meant we ended up where we left off, with a trailing backlog, a demotivated development team, and poor visibility for stakeholders.

The lessons learnt from our experience with Scrum:

You spend so much time planning sprints, and holding retrospectives that you loose about 2 days in every 10 trying to pull everyone together and plan. Sprints slip, and backlogs grow, which in turn frustrates everyone involved. You really have to be regimented to the process to ensure each sprint is run properly and for a small team with changing priorities it’s very hard to stay on top of.

Is Kanban the answer?

I’m not completely discounting Scrum, and in the future when we’ve got the resources and time to afford a dedicated Scrum Master and Project Manager, we’ll most definitely revert back, as I can see the benefits. But for a small team with changing customer needs Kanban can allow us the flexibility to deliver features as we prioritise them.

We’ll have a strict WIP limit on Progress and Code Review, which should allow a continuous deployment of features — in Scrum we were pushing half done stories from progress into back log as they didn’t match the next Sprints theme.

We will continue doing retrospectives, but instead of every two weeks, we’ll do them when we feel the time is right, letting the development team decide when is necessary.

We’ll continue with planning meetings, as and when we get new requirements through from our customers.

And we’ll keep doing standups in Slack.

As with any Agile approach we’ll also continue questioning, testing and improving our process. I hope in about three months time, I can write about how great the change has been, or lessons learnt.