Kanban Misconceptions

Drop your 2 week sprints and bingo, you're now Kanban. A free for all, system-less, system for software development. Or are you...?

2/9/2023 agilekanban

In Agile, working in Kanban is like Scrum but without the sprints.

Well, as a big fan of Kanban, and having worked in a Kanban environment previously, this was news to me.

Written in an article called “Solving the 7 most common Kanban mistakes that ruin your development”, the rest of the article came up with some salient points on how to run Kanban well. However, Kanban is not just Scrum without the sprints.

To this end, I thought I’d throw out a few misconceptions about Kanban and why they’re wrong.

Scrum without the sprints

Let’s start with the first one.

Kanban is essentially a set of principles, built out from Lean principles, that aim to help you deliver software efficiently.

It includes having a board to visualise work (kanban literally translates into “signboard”), Work in Progress (WIP) limits to avoid bottlenecks, defined policies, feedback loops and time set aside to improve. None of this sounds unachievable within the framework of Scrum.

You don’t have that “look what we achieved moment” in Kanban

One thing I’ve heard before is that, in Scrum, you get that end-of-sprint get-together and celebration of everything you’ve achieved (or not achieved) within the sprint. The team demos their work and celebrates what they’ve delivered. Moving to Kanban causes this event to be lost and the team misses out on an end-of-sprint morale boost.

But why can’t you do this in Kanban? Is the only reason you’re doing such demos because the scrum guide tells you to? Or because it’s a good idea?

If Scrum is an “incomplete framework” (which if you don’t think it is, read the scrum guide) then Kanban is a barely started one!

Kanban sets out the principles, but you are free to tackle work however you wish. Kanban teams are more than welcome to continue splitting work into increments, projects, or whatever you wish to call them. These projects should be short (weeks, not months) and after you complete them you can, and should, get together and reflect on what you’ve achieved.

You can’t plan in Kanban

Another common one is that scrum helps you plan. “Knowing” how many sprints a set of work will take can enable you to see how far through the work you are.

My issue with this is the assumed accuracy of these things. At best: you’re wrong, you need to add a sprint two and that’s fine. At worse: you’re held to this “number of sprints” and towards the end of the project the effort increases to achieve this.

Outside of sprinting, there are still options to plan. One option is to create high-level User Stories, t-shirt size them and track how many are still to complete. These can then be refined, broken down into tasks, and further understood as you progress. The ultimate indicator of how long a project has left is how long it’ll take for you to burn down to 0 stories. Initially, you can create a rough estimate of how long you think something should take (or, even better, decide how much time a problem is worth solving and tailor your solutions to that), but once you start to complete things you can use cycle & lead time calculations to predict a supposed completion date. The good thing here is you never have to come up with another number of “how many more sprints do you think?” The numbers are entirely reactive.

I’ve got another article in progress on planning and talking in more depth about why Scrum is not a planning tool. Hit subscribe to get updated when it’s released.

Dude, where’s my retro?

Anywhere you want it to be! Just because you’re not working in increments of set length doesn’t mean you can’t meet regularly to review your processes and improve. Because you don’t have prescribed intervals to reflect, you may find your team coming up with more novel ways of bringing about improvements.

5 whys sessions and a “stop the line” mentality can all bring about process improvements and don’t require a 2-week interval to implement. Of course, you can still choose to meet every 2 weeks and that’s also fine, just because you haven’t finished a project doesn’t mean you can’t meet to review how to improve. The world is your oyster, your destiny yours to create, choose to improve how you wish (and then improve how you improve).

So what’s the point?

I suppose my point is this: Kanban has much more to it other than “scrum but without the sprints”. And, I guess, the bits that make scrum useful aren’t solely things that exist in Scrum.

Planning, retros, refinements, demos; all these things are helpful and useful no matter what process you follow and aren’t exclusive to Scrum. If the only reason you do these things now is because the scrum guide says so, I’d recommend reviewing what you find useful in your process and looking at how you go about those things.

Kanban and Scrum can be used in conjunction together, but if you find that sprints don’t work for you, dropping them and opening yourself up to more lean principles can offer you ways of working that increase all that is good about agile.