We’ve recently switched from Scrum to Kanban, and we couldn’t be happier. Our development process feels more healthy and productive, artificial barriers and blockers have disappeared. But it’s not all roses - we do struggle at times to have a healthy heartbeat of delivery and demo.
So what made us change our tune? Well, we looked at the nature of our project and the nature of our problems.
Our project is a big greenfield redevelopment of our popular booking platform. As such, what we’re doing doesn’t fit obviously with lean principles. We don’t need to deliver a simple proof-of-concept product and then start iterating, because we actually already know our business domain and our existing product already proves it. In the analogy where a good lean engineering team builds a rollerskate, then a bike, then a moped, then a Porsche... well, we’ve already got a perfectly good VW Golf. We just want to build a Porsche to replace it; the bike and the moped would be a total waste of time.
Similarly, we weren’t finding two week sprints valuable. Developing a consistent velocity wasn’t important to us; there was nothing to deliver to market until the whole product was complete (until then, our existing product was infinitely better for clients), and since it was impossible to guess the total complexity needed to complete this behemoth our average velocity was going to be a meaningless metric for a very long time. Instead we wasted lots of planning time trying to break epics down so that there was something “meaningful” to deliver and demo every fortnight, yet as often as not, the stakeholder would show up mainly to show willing - because the product of a single sprint was too raw to decide whether it was “the right product” yet.
On the other hand, we had problems. Things we actually did care about were taking months to get properly “done” - long after the development work was finished there’d be test automations to catch up, or the legacy side of an integration wasn’t complete. But in the meantime the team had busted in on the next set of stories, and so the half-finished stuff dragged along in the background. Actual releases became a nightmare as there were buckets of conflicting dependencies to resolve.
So what made us change our tune? Well, we looked at the nature of our project and the nature of our problems.
This led us to Kanban.
Kanban excels in two particular areas.
Firstly, it helps teams make sure they get things “done”. Scrum focuses on productivity, on “how much complexity have we delivered”, whereas Kanban is focussed directly on your impact on the business, on “how long did this story take to get from backlog to done”.
With Scrum we found we often got in situations like this: “Development is finished, we’ve done a demo, sprint complete! Okay, so there’s still a data migration and some docs to do, oh, and obviously actually releasing it live, but we’ve got a new sprint to plan on Monday…” Kanban is dead simple. You can only have a maximum of X stories in progress at once, that’s the rule. Too many things in progress at the same time means you are failing to get things “done”. So you are just not allowed to start anything new until you’ve got something else finished. Simple.
Secondly, Kanban is a great tool for improving your development process by helping to recognise flaws. Retrospectives are just as important in Kanban as they are in Scrum, but the rules of Kanban itself actually help give them focus. They do this by clearly identifying where you have bottlenecks, what is slowing you down. If the “UAT” column of your Kanban board is always at max, that tells you loud and clear that there’s a bottleneck in getting things through UAT. Your retros can focus on that, week-in and week-out, until the situation improves, instead of just being a talking shop about whatever niggles the team bumped into over the last couple of weeks.
Both of these things were more important to us than the formality of trying to deliver something in a two week sprint. So we switched, Scrum to Kanban, and we’ve been happier ever since.
Comments