Scrumsplaining #1: Kanban is Scrum Without Sprints

“scrumsplaining” is the phenomena where a Scrum practitioner tries to explain why you can’t use some alternative approach without actually making any attempt to understand the other approach or a different point of view or paradigm. In “scrumsplaining” everything is explained using the paradigm of the Scrum framework.

Scrumsplainers are generally people who’ve been using Scrum for a while but there performance has plateaued, no further improvements have been occurring and they are looking for something fresh to inject innovative thinking and further improvements. Alternatively Scrumsplainers are consultants and advisors who are afraid that they’ll lose status as an authority figure if a client or practitioner who looks up to them decides to adopt something that would erode the use of Scrum practices in their workplace.

This is the first of a series of Scrumsplaining Kanban blogs.

Scrumsplaining #1: Kanban is just Scrum without Sprints

If you are already doing Scrum and you stop using Sprints and drop the regular cadence and just use a single continuous Sprint then you are doing Kanban.

Except, dropping sprints would be bad. People get exhausted from just working, working, working, all the time. And then you don’t have a cadence, and there would be no retrospectives, so things would never improve.

Hmmm. I see. So, you need sprints so that people take a rest?

Yes!

Really? Why don’t you just stop for a rest when you need one?

People forget to do that. Without sprints the pace isn’t sustainable.

I see. So what happens if something is too big to complete within a sprint?

Well, we break it up into smaller pieces, 2 or more.

So you start working on something, and before it is finished you stop for a rest when the sprint is finished?

Yes.

Wouldn’t it be better to stop once you’ve finished and before you start something else?

No. It’s better to stop on a regular cadence.

Isn’t that disruptive? Isn’t there a cost when you re-immerse yourself in the next part of the work?

Well yes, but that is better than not stopping for a rest and maintaining a sustainable pace.

Hmmm. So tell me again why you don’t just stop for a rest when you need one?

That would be bad.

Doesnt Kanban suggest we limit our WIP to keep the pace sustainable?

But some things could be big and take a long time, that wouldn’t be sustainable.

Hmmm. Isn’t Kanban an approach to evolutionary change? Aren’t things meant to improve as you use it? Can’t you just hold regular retrospectives without sprints?

That would be weird. Why would you do that? It isn’t efficient to hold a retrospective on its own without a demo or a planning meeting.

Kanban isn’t Scrum without Sprints. Kanban is born out of a different paradigm and a different philosophy. Kanban uses the paradigm of limit work items in progress and the concept of a system capacity for a single service. New work is pulled into the system for service delivery when capacity is available. Limiting WIP creates a stress that stimulates about improving flow of work through the system to improve service delivery lead time and predictability. Service Level Expectations (SLEs) or formal Service Level Agreements (SLAs) are used and compared to Service Level Capabilities (SLCs) at regularly scheduled retrospectives called Service Delivery Reviews.

Kanban takes a service-oriented and evolutionary approach to improvement. You start with what you do now and design a kanban system to wrap over it. Kanban adapts to your existing context and helps you improve from there. Kanban is not prescriptive instead it is adaptive and designed in context. You limit WIP and you pull work when there capacity free as other work is completed. Kanban systems model entire service delivery workflows and span multiple teams. Kanban system workflows have been known to involve up yo 100 people but 20 to 30 is more typical. Commitment to customers is made using a probabilistic approach of service level expectations/agreements. In every respect this is different from Scrum.

Scrum expects you to change your context so that Scrum as a prescriptive and defined process will work. Scrum expects you to make grand revolutionary changes to your organization, workflow, planning and interaction with customers. Scrum uses daily and sprint (usually two-weekly) planning commitments as the catalyst for improvements. Scrum limits time into periods called Sprints, it does not explicitly limit work items and pull work as capacity is free. Scrum uses batch-transfers at each Sprint. Scrum uses deterministic planning and specific deterministic commitments. It does not use probabilistic planning. Scrum is designed to work at a team level where a team is 3 to 12 people and most typically around 6.

While the mechanics of a kanban system could be loosely described as “Scrum without sprints” and the popular Scrum tracking tool, Rally, implements its shallow Kanban functionality using a single, continuous Sprint, it is so wrong-headed to describe Kanban as “Scrum without sprints” it prevents people from seeing the applicability, the benefits, and the opportunity.

When you view Kanban through the lens of the Scrum paradigm, you get “Scrumsplaining!”