Scrumsplaining

“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!”

“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.

In this 2nd post in the series we look the argument that you need the peer pressure elements designed into Scrum in order to maintain a sense of urgency and get things done.

Scrumsplaining #2: If we adopt Kanban we’ll lose our sense of urgency

[The following conversation paraphrases a VP of a business unit at a major Internet/telecom equipment manufacturer. I’ve allowed 12+ months to elapse before posting this, and it remains anonymous. The company is American. The BU is based in New England. The Scrumsplainer was in charge of a 600 person BU partly staffed in India.]

Without the daily Scrum and regular Sprint commitments there will be no sense of urgency!

I see. Why do you think that is?

Well we need people making commitments to their peers everyday or they’ll just slack off and play ping pong all the time.

I see. Why is that?

Well, they’re inherently lazy. We need to keep them under pressure or we’ll get nothing done.

You really believe that?

Yes. Our people are too comfortable!

How many people in this BU?

About 600!

How many are new since you arrived?

About 300!

So you’ve hired 300 lazy people since you started? Do you select lazy people when hiring?

No. No, of course not.

So they become lazy after you hire them?

Well, they are all very comfortable. There is no sense of urgency.

Every Scrum team in your BU missed its sprint commitment last sprint. Every team in the building has missed its sprint commitment for the last 22 sprints. On average they are missing each commitment by 50%. At today’s retrospective not a single Scrummaster reported this. No one is willing to own the missed commitments.

Exactly, there is no sense of urgency!

So you are currently using Scrum and yet there is no sense of urgency. So tell me again why you would lose the sense of urgency if you adopt Kanban?

Our people are too comfortable and we need to keep them under pressure.

Would you say that you believe in McGregor’s Theory X and people need to be extrinsically motivated?

No. I believe in Theory Y. People are intrinsically motivated.

And yet, you need to keep them under pressure with daily and di-weekly commitments or they’ll just slack off? In what way are they intrinsically motivated?

….

Do you really believe your people, hundreds of them are inherently lazy?

Our people are too comfortable and need to be kept under pressure.

Have you considered that if your people aren’t intrinsically motivated and have no sense of urgency, there may be a failure of leadership?

Kanban has a (usually) daily Kanban meeting around the kanban board. It isn’t however a Scrum meeting. In a Kanban meeting you iterate over the tickets from right to left: Closest to completion to most recently started. There is a focus on the work and not on managing the workers or peer pressuring them to complete tasks.

Kanban has no time-boxed batch planning mechanism such as the Sprint in Scrum. Instead items are pulled individually and delivery is measured against a service level expectation or agreement on lead time.

So the elements of Scrum which are designed to create a sense of urgency using peer pressure are indeed missing.

Kanban simply uses a different paradigm. Kanban is service-oriented and models service delivery workflows from request to delivery. Kanban makes the customer/service requestor and the business need or business risks visible and transparent throughout the workflow. Workers in a kanban system know who the work is for and why they are doing it. They know which business risks are associated with the item and they understand why it being given a specific class of service.

There isn’t a sense of urgency, there is a sense of service. There is a collective pride in service delivery excellence. A sense of pride in service delivery creates urgency where and when it is appropriate. Transparency and visibility, collaborative working and a sense of pride are what make Kanban work. Kanban is designed around the assumption that knowledge workers indeed conform to Theory Y: They are intrinsically motivated.

To make Kanban work there needs to be leadership. That leadership has to value customer service and instill a sense of collective pride in good service. When you hear a scrumsplainer, arguing Kanban lacks a sense of urgency, you are actually listening to a misdirection. The scrumsplainer lacks courage and fails to show leadership!