Ditch the Sprint: How Kanban Streamlines Agile Workflows

Today I'd like to convince you that Scrum sucks and Kanban is the best thing since sliced bread…

Yeah, it’s an opinionated article, and I’d love to engage with the community on your own experiences. My experience has been that Scrum is more difficult to deploy correctly, is less adaptable to rapid change, has a higher ceremonies overhead, and breaks down into anti-patterns far more easily than Kanban does. Kanban, you might say, is Scrum without the bullshit.

First, I’m going to give you a brief definition of the two processes as I understand them. The goal isn't to explain both processes in depth – there's plenty of literature available for that. Here I'm going to take a more practical approaches, assuming you have a decent level of familiarity with Scrum.

A Brief Comparison

You will note here that Kanban is lighter weight in terms of ceremonies, and values getting a story from start to finish as quickly as possible rather than making sure everyone on the team has work to do.

Let's drill into some of these points a little more closely.

Process Entropy: ScrumBut

A common anti-pattern I've encountered in a lot of Scrum teams is known as ScrumBut. Here's an in-depth article describing it, but in short, the motto of a ScrumBut team is "We do Scrum, but... we don't like short sprints and so we don't do them." Or "We don't like daily standups," or "we don't like retrospectives..." You get the idea.

There's a big problem with this approach. Every process, independent of whether it's Waterfall, Scrum, XP, Kanban, or anything else, is a house of cards. As long as all the cards hold in place, the process works as intended. But remove any of those cards, and the whole thing starts crumbling. I could write in-depth about why every part of Scrum holds up every other part, but this article isn't about that.

My main point is that Kanban is a house of cards too... but there are fewer cards. Less cogs to keep oiled. Because of that, when the cogs it does require are kept in working order, Kanban can be very resilient to process entropy.

Adaptability

As an Engineering Manager, I value adaptability as a key attribute of any process. In other words, how well does the process allow for rapid change, whether it be in priorities, in scheduling, in team resourcing, etc.

The big reason why Agile became popular is in its name: "agile." Waterfall, in its standard form, was extremely inefficient when it came to rapid change. The Agile umbrella (Scrum, Kanban, etc) are much better at this. Scrum's insistence on short sprints means the team can adapt in sprint intervals or even sooner with a full sprint reset.

But Kanban doesn't have a fixed time window. It can adapt to shifting circumstances as quickly as the human ability to context switch allows. This allows the team to quickly ingest changing priorities or (in combination with thin slicing/swarming) personnel changes or when a story thought to be two weeks turns out to take two months.

Ceremonies

People hate meetings. Well, sane people hate meetings. Especially meetings where they're bored. This implies that the less meetings a process requires while remaining functional, the better.

In Scrum's case, you would likely have a day's worth of meetings at the end of every two-week sprint. Demos, Planning, Costing, Retrospective. Demos are often quick, but Planning and Costing meetings can easily go 2-3 hours. (I know Scrum practitioners say they should be much quicker than that, but I have yet to see an effective Planning or Costing meeting take less than 1-2 hours, and that's on teams who have been doing Scrum a long time.)

Kanban only has Demos and Retro. For my team, that's usually 90 minutes, tops, every two weeks. That's an arbitrary timeframe, but we've found a two-week cadence of those two works pretty well.

Measurement

In the Scrum model, measurement is often all about "velocity," which is essentially a score that tells you how much work your team can complete in a sprint. It's a bit like your car's speedometer, but instead of tracking miles per hour, you're tracking "work per sprint."

Now, to set this velocity, a lot of debate and calibration are involved. Teams have to agree on what constitutes a "story point," which becomes the unit of measurement. It's like agreeing that one "mile" is the distance from Point A to Point B, and then calculating how many "miles" you can cover in a day. But here's the catch: What if your roadmap suddenly includes mountainous terrains or unfamiliar roads? The whole scale needs to be adjusted, and all your past velocity readings may become irrelevant.

It's important to note that no actual work is getting done while the team is arguing about how big a story point is, and whether Story A is 5 or 8 of those story points. It's all overhead.

Kanban takes a different approach. It focuses on "cycle time," the actual time it takes to complete a task from start to finish. It's more like a GPS that constantly updates the ETA based on your current speed and traffic conditions. If you notice your cycle time going up, you instantly know something is slowing down the workflow, and you can address it. No need to debate how many "story points" a mountain or a highway is worth; you're dealing directly with real-world, actionable data.

By focusing on cycle time, Kanban sidesteps the need for complex estimations and recalibrations. It provides a dynamic, real-time measure of your team's capability, making it easier to adapt and optimize.

Delivery Timeframe

The PMs like Kanban too, once they understand it. Having a single prioritized stack of work means they know exactly how far their asks are from being executed on. If they come up with a critical task, they know the Kanban team can pick it up immediately, whereas a Scrum team (modulo breaking process) will have to do a sprint reset – that's a procedure filled with unnecessary meetings.

What I've seen teams do is given a certain deliverable time-period (e.g. 3 months), they would color-code their stacks based on their level of confidence for each story. For example, if you have stories A, B, C, D on the stack (in that order), you can be green on A (because you're sure you'll get it done in 3 months), yellow on B and C, and red on D.

Now PMs know exactly the likelihood of getting their stories finished. What happens if story E goes between B and C? C moves to red. Easy.

What about your team's process?

To sum it up, Kanban is a more natural way to work. No unnecessary meetings, no artificial scheduling wizardry. It's a practice that focuses in on the work to be done without extra overhead.

Can Kanban fail? Of course! The biggest three ways of failing Kanban is:

1. Not having a prioritized stack of work
2. Not having your board set up to represent each state work goes through. (i.e. In Progress, In Review, In Release, In Design, and so forth.)
3. Not limiting the amount of work in progress. (WIP limits)

I could write a separate article diving deep into those concepts, but there's plenty on this on the net. Still, hit me up if you want more information there.

So what about you? What kind of process does your team run? What do you like about it? What do you hate about it? Comment below!

And if you want to see more content like this, please consider following us on LinkedIn.