Kanban University

Management Training, Consulting, Conferences, Publishing & Software

Kanban

Scrumsplaining #1: Kanban is Scrum Without Sprints

by

“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 #2: No Sense Of Urgency With Kanban

by

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

Will Role-based Training Be Introduced Into Kanban?

by

With the acknowledgement that two clear roles are emerging in Kanban implementations, the Service Delivery Manager, and the Service Request Manager, does this signal that Lean Kanban University will be reorganizing to offer role-based training? It’s a fair question, and the answer is “No.” This article explains why…

alternativepathtoagilityroadmap_0

This diagram shows the current Lean Kanban University Alternative Path to Agility currciulum roadmap. It shows the currently offered professional credential of KMP (Kanban Management Professional). KMP is offered to people who complete the KMP I & II classes, a total of 4 days of training. On completion of KMP I & II they know how to analyze and design a kanban system using the STATIK method, and they know how to implement the Kanban Cadences, identify opportunities for improvements, with many ideas on what to change and how it will affect capability. Hence, a KMP knows how to operate the Kanban Method for evolutionary change within their organization.

A KMP could play the role of Service Delivery Manager, Service Request Manager or Kanban Coach (though not at the level of expertise of Kanban Coaching Professional). The difference between a KCP and a KMP is that KCPs are trained in identifying resistance to change, devising strategies to avoid resistance and in counter-measures to overcome resistance and motivate people to get on-board with Kanban adoption. KMPs do not have this training. KMPs are qualified to operate a Kanban Method implementation, KCPs are qualified to introduce the Kanban Method successfully.

We do not feel the need to introduce role-based training because as much as 60-70% of the training for SDMs would overlap with SRMs. We also feel there is lots of value in KMP training for people who will not play the SDM or SRM roles. We hear reports from the field that there is a 60-70% overlap in the training for Scrum scrummasters and product owners taking the CSM and CSPO training. We feel that having role-based training with such a significant overlap in curriculum is inefficient and confusing, so Lean Kanban University will offer the one set of training and the single professional credential of KMP regardless of the role the individual is playing.

Proto-Replenishment Semi-Push System

by

There is a class of replenishment meeting which I believe we need to call out and name separately. In these replenishment meetings the backlog is already committed and often already prioritized. I am proposing we label these proto-replenishment meetings. This post explains why and asks whether the name proto-replenishment is appropriate or not…

protoreplenishment

Read more…

The job of replenishing the kanban system is somewhat trivial, generally inwardly facing and selection is often based on technical, resource, skillset, or coordinating delivery dependencies to facilitate flow. In other words, replenishment is more about “definition of ready” and selecting based on readiness, than it is about commitment, scheduling and sequencing of work from a business risk perspective. The pool to select from is referred to as a backlog and it is already committed. There is already an agreement with the customer that the backlog items are in-scope and must be delivered.

Full replenishment meetings as described in the Kanban (blue book) feature the customers (service requestors), work items submitted are not committed, instead the collection of them represents a pool of options. The replenishment features the selection of items from the pool and discussions around appropriate scheduling and sequencing of items. The replenishment meeting features the act of commitment. There is genuinely deferred commitment until kanban system replenishment and a proper pull system is in operation. Customer work is pulled based on capacity signaled by kanban in the system. At a full replenishment meeting customers are present and make the decisions. The focus is external and outward looking and decisions are made on immediate business impact of delivery: cost of delay is a key influence on decision making.

deferredcommitmentpull

In these other forms of replenishment, see diagram below, the work has been pushed, perhaps in large batches, perhaps based on a belief, or mathematical understanding of capability but nevertheless pushed into the system. Commitment is not deferred. Commitment is made early at the point the batch is pushed. This is common for large projects. When we are using Kanban with a large project, the project typically has a committed backlog. The kanban system replenishment meetings are simply about selecting work to flow through the project workflow. The main task is sequencing and typically, technical, delivery and resource risks are the main inputs to the selection process. At these alternative replenishment meetings, customers are seldom if ever present, the attendees are almost entirely from the delivery side. The focus is internal and the decision making is influenced by internal concerns.

protoreplenishment

So these meeting are different. They clearly represent a less mature, and shallower implementation of Kanban. The question is whether they should be labeled “proto-replenishment” or whether we need another alternative name? Proto-Kanban is an established term, usually used to refer to Kanban Boards without WIP limits, though other variants exist. The term was coined by Richard Turner, of the Stevens Institute, because the case study literature showed that these proto-Kanban implementations often matured into full Kanban implementations later. Hence, these boards without WIP limits were evolutionary predecessors of Kanban and the suffix “proto” indicates an expectation that they are a seed from which something more mature may develop.

The question is whether proto-replenishment is appropriate or not? I believe it is. Generally, proto-kanban implementations are inwardly facing and they are often at what Klaus Leopold labeled Flight Level I & II. When a kanban system is designed in an outwardly facing fashion asking the questions, who are our customers? And what do they request from us? Then we typically see much deeper implementations including WIP limits, pull and classes of service. However, getting from proto-replenishment to full replenishment will not happen without leadership. This transition highlights the true crux of Kanban implementation. If you can get beyond proto-replenishment then you have implemented a pull system. This is a non-trivial step. It is the non-trivial step that Kanban Coaching Professionals (KCPs) are trained to help you take.

Recognizing proto-replenishment as a concept introduces a whole new way to understand and teach improving depth of Kanban and tuning implementation to organizational maturity. It will enable coaches and change agents to point out a lack of deferred commitment and the associated business risks that early commitment carries with it. It also gives a another very clear and simple test for “are we doing Kanban or not?” To have truly implemented Kanban your replenishment meetings will involve customers, you won’t have a backlog, you will have a pool of options, and commitment will be made at the replenishment meeting as you pull work into your kanban system. If that isn’t happening you are still in the proto-kanban stage and have a lot more opportunity ahead of you.

Emerging Roles in Kanban – SDM and SRM

by

Kanban has always been the “start with what you do now” method, and no one gets a “new role, responsibilities, or job titles” at least not initially. However, it is now clear that some roles are emerging in the field with some implementations. So, it is valuable to report this, while they remain suggestions, options, or ideas, rather than prescribed roles for a Kanban implementation. This post follows my previous one that Kanban doesn’t share Agile’s cross-functional team reogranization agenda, and has always been a cross team, cross function solution for service delivery workflows. What follows is in the context of a service delivery workflow which spans functions or teams and is (most likely) orthogonal to the organizational structure of the enterprise, business or product unit.

Service Delivery Manager

From the early days of Kanban, we talked about the need for a manager to take on responsibility for flow of work. Perhaps, echoing the concept of scrummaster, in some implementations the role of person responsible for flow has been nicknamed flow manager or sometimes “flowmaster”. It’s a sticky, if arcane and tribal, title. For our official literature, I wanted something more corporate friendly, and something that is more outwardly facing. “Flow manager” is inwardly facing and focused on process problems. I prefer names that are outwardly focused and address customer needs. This is in line with the Kanban value of “Customer Focus.”

There is precedent for renaming concepts in Kanban to give them more customer focus. Inspired by the Improvement Kata in Toyota Kata, we defined and named, the System Capability Review meeting in 2012. This was later renamed to Service Delivery Review (SDR). The name change was to give the meeting an outward focus on customer needs, rather than an inward focus on process performance. By keeping the naming, the language, and the values, externally focused, we insure that the right metrics are used to drive relevant, valuable improvements. An outward focus is vital to insure “fitness for purpose” and to deliver on the Kanban agenda of survivability.

So, the “flow manager” concept is called the Service Delivery Manager. It is primarily intended to be a role played by an existing member of staff and not a new job title or position. So, by creating Service Delivery Manager, we do weaken the message that no one gets new responsibilities – actually someone does, the someone who takes on the SDM role.

sdmroleinservicedelivery

The SDM role existed in 2007 in our first full scale Kanban Method implementation. It was usually played by a project manager from the PMO. The SDM carried responsibility for the Replenishment Meeting, the Delivery Planning Meeting, escalating blocker tickets, and what we would now call Risk Review. Replenishment, Delivery Planning and Risk Review are 3 of the Kanban Cadences.

In more recent implementations the SDM also facilitates the daily Kanban Meeting. In 2007, this role was taken by one of the function managers in the workflow. The SDM role was usually played by someone from the PMO.

Service Request Manager

For some number of years, the question has existed, what do you do with middle-men in the workflow? As a general rule, we wish to remove non-value-adding middle-men positions from the workflow. However, we also wish to avoid resistance to change. These are two core tenets of Kanban coaching and general goals we might have for change management when deploying Kanban in an organization. And the following guidance has existed since 2009: we seek to elevate the role of the middle-man, above the workflow, out of the value stream. The most common example of this is shown in the diagram, “What do you do with the Product Owners?”

whatdoyoudowithpos

The goal is to reposition the role of product owner as a risk manager and facilitator: someone who owns the policies for the system which frame decisions together with facilitating the decision making mechanism. This role is of higher value, is transparent and open to scrutiny and relieves us of the risk of the “hero product owner” who magically understand where the best business value is to be found. This elevated risk management and policy owning position improves corporate governance, improves consistency of process, and reduces personnel risk associated with a single individual.

Nevertheless, an individual with a “hero product owner” self-image will resist such a change. Kanban Coaching Professionals are trained to manage this resistance as part of their training in the Kanban Coaching Masterclass.

When the product owner is successfully repositioned above the workflow as the owner of the policies for risk assessment, scheduling, sequencing and selection, they have successfully transitioned into the Service Request Manager (SRM) role.

Again, we are weakening the “no one gets new responsibilities” principle, but this transition is generally managed over a period of time and isn’t necessarily thrust upon individuals at the start of Kanban adoption.

When the SRM role exists, the SRM usually takes responsibility for the Replenishment Meeting and will play a role in the Strategy Review and Risk Review.

When Do We Need SDM & SRM Roles With Kanban?

by

With the emergence of the SDM & SRM roles with Kanban, we need to ask the questions, when do we need these roles? When do we need both? And are they merely roles an existing member of staff takes on as new responsibilities, or might they be new positions for which we need to hire? This post provides guidance based on what we’ve seen in the field so far.

rolesandservicedeliveryworkflow

When do we need a Service Delivery Manager?

I genuinely believe you always need a service delivery manager. This role has existed since the first Kanban at Microsoft in 2005. In the early days the SDM role was always played by a project manager. So it isn’t a new position but a refinement of existing responsibilities for an existing member of the staff. The SDM is therefore a role played by someone external to the value stream or workflow.

In the upper diagram, a service delivery workflow is shown spanning a functionally silo’d organization. The SDM facilitates the Replenishment Meeting receiving customer requests and facilitating a collaborative decision making process to select, sequence and schedule work to flow through to delivery. The SDM will collaborate with the functional manager or team leads and play a reasonably active part in the day-to-day operation of the kanban system, definitely attending and perhaps facilitating the Kanban Meeting.

It’s been reported to me that in some organizations, the concept of a service delivery workflow is very weak, while the functional silos and structure are very strong. Usually, such companies lack any significant focus on customer satisfaction or any service-orientation in their thinking, mindset or value system. I’ve specifically had this reported to me from a large Swedish industrial company and several companies in China in the technology or finance sectors. In these instances, the change agents, usually process coaches or members of the PMO, felt it was necessary to create the Service Delivery Manager role as a specific position within the firm. The act of doing so, is actually making a very clear commitment to service delivery and customer satisfaction. In other words, the bar for the change initiative is raised – senior leaders are being asked to acknowledge that service delivery and customer satisfaction are important. They are being asked to explicitly put customer focus in the spotlight and make it part of the corporate value system. This is a non-trivial but hugely important step.

So where there is a current lack of customer focus and a lack of understanding of existing service delivery workflows, where the concept is weak, you need to create a position for SDMs.

When do we need a Service Request Manager?

A Service Request Manager is likely to be needed when contact with the customers, or service requestors is weak or distant. The SRM becomes a proxy or advocate for the customers. However, it is important that we don’t place the SRM in a decision making role. We don’t want them becoming a dysfunctional proxy for the customer, showing bias towards one over the others. We always want the SRM as the facilitator of selection not the person doing the selection. In organizations, where contact with the customers is weak, there is often already an intermediary possibly a sales engineer, an account manager, a product manager or in Agile adopting organizations a product owner. So we want to elevate that person’s role into the role of SRM. It is a set of new responsibilities, not a new position.

When the SRM role exists, the SRM will take on the responsibility for the Replenishment Meeting and will play roles in the Strategy Review and Risk Review.

When might we need SRM as a new position? If the SDM is the “flow manager” for service delivery, then the SRM is the “flow manager” for ideation or discovery. So we might expect to see SRM emerge as a specific role when we have an upstream or discovery kanban system. The more focus we have on ideation, option validation and discard, and discovery and validation of concepts (or minimum viable products, MVPs) the more likely we are to need a SRM as a specific position in our organization.

discoverydeliverywithroles

The SRM role is described as “marshalling options”. This is the act of facilitating flow, and discard or upstream kanban work.

When might we need both roles?

In discussing this amongst my colleagues and with leaders in the Kanban community, Mike Burrows commented, “I have seen the need for one or the other but never both.” And that is probably a fair statement, we have seen firms adopting SDM or SRM roles but so far we haven’t seen both, at least not explicitly. With larger scale ESP implementations, we do see a lot of SRMs. One client advertised for SRMs by placing job advertisements for Product Owners. This makes sense. You recruit for a title that people are familiar with, then you mold them into what you need. That client has a strong sense of service delivery and without doubt function managers or team leads are playing the role of SDM. It just hasn’t been made explicit in that company.

So I suspect that as we see greater emphasis on the use of Kanban upstream and the growth of Enterprise Services Planning, with business emerging where ESP/Kanban is _the_ way that they manage their professional services company then we will see strong growth and use of both SRM and SDM roles.

At smaller scale and where there is little ideation, option development and discard, and a strong connection to the customer together with a strong sense of service delivery, in these cases, I expect only one role, SDM, played by an existing member of the staff. So Kanban as we knew it in 2005-2008 doesn’t involve new positions or additional headcount, but the future with Enterprise Services Planning, particularly in organizations with a weak sense of service delivery and a lack of customer focus, we are likely to see the new job title of Service Delivery Manager emerge. In companies that do a lot of innovation and act as a market leader in an uncertain and emerging market, we are likely to see the emergence of Service Request Manager as a new position. Where both circumstances exist, we’ll see both roles in use, perhaps both as new positions and additional headcount.