• Skip to primary navigation
  • Skip to main content
  • Skip to footer
Kanban University

Kanban University

Management Training, Consulting, Conferences, Publishing & Software

  • Contact Us
  • Certified Kanban
  • Events
  • Resources
  • About
  • Sign In

Scrum

Scrumsplaining #1: Kanban is Scrum Without Sprints

January 11, 2016 by David Anderson

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

Filed Under: Agile Tagged With: Kanban, Scrum, Scrumsplaining

Scrumsplaining #2: No Sense Of Urgency With Kanban

January 11, 2016 by David Anderson

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

Filed Under: Agile Tagged With: Kanban, Scrum, Scrumsplaining

Will Role-based Training Be Introduced Into Kanban?

January 7, 2016 by David Anderson

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.

Filed Under: Foundations Tagged With: Kanban, Kanban Management Professional, KMP, Lean Kanban University, Product Owner, Scrum, Scrummaster Certification

Are Scrum & Scaled Agile Damaging Morale At Your Firm?

January 5, 2016 by David Anderson

In 2008 I was scheduled to give a talk to the Bay Area APLN meetup group. The meeting was being held at the offices of The Gap in downtown San Francisco. The organizers arranged to meet up for a reception in a bar prior to the meeting. As the guest of honor some of the attendees naturally wanted to talk with me. Waiting patiently and quietly for her turn was Janice Linden-Reed. Janice’s story has become a familiar one. She was a project manager at a company where they had adopted Scrum a couple of years earlier along with the Rally tool for work tracking. They’d received training and coaching from Rally but for the last 6 to 9 months Scrum was proving very painful for them and morale was suffering. Meanwhile, the Rally consultants only had one song to sing, “you aren’t doing it right! If only you followed all the practices of Scrum then everything would be fine.” That company was Posit Science, a company pioneering the commercialization of brain plasticity science, and its staff were a combination of PhD neuroscientists and game developers. They were smart, highly motivated people, who believed they were bringing some good to society with their technology and yet Scrum was making them miserable. They simply refused to buy the argument that the problem was with them.

Over this recent holiday period, Grant Ammons lit up social media with his blog post, “Ditching Scrum for Kanban – the best decision we’ve made as a team.”

What makes Grant’s story interesting is that his is just the latest in a long line of similar stories – a thread that can be traced over at least 8 years since I first met Janice Linden-Reed and first heard about Posit Science and their challenges with Scrum.

Since 2009, the Lean Kanban conference in the United States, has been sponsored by Ultimate Software. Ultimate sponsor our conferences as a thank you and in recognition of what Kanban has done to maintain their corporate culture and enable them to thrive since they made a decision to ditch Scrum. In 2008, Steve Reid and Rafael Santos from Ultimate attended Agile 2008 in Toronto looking for a solution to the misery that Scrum was bringing to their workforce. Their story was similar to Janice’s and similar to Grant’s, Scrum had helped them for a while, it had worked for a while, but after a period of 9 to 18 months, it was clear that it was having an irreconcilable negative impact on staff morale. Ultimate prided themselves on their status in the best 100 places to work list. In the most recent survey they are ranked 21st best large employer to work for in the United States. In 2008, their status on this list was in jeopardy and Scrum was a key source of the dissatisfaction that was bubbling in the workforce.

Every story is a little different but there are clear themes. Perhaps half of our clients and half of the attendees at Lean Kanban training around the world are people looking for answers to challenged, painful or failed Scrum implementations. The first thing to realize is that these are real stories and the facts are what they are: people felt the way they did and they acted according to their situation. Wishful thinking or post hoc analysis that they could have done things differently doesn’t change the facts. So what are the common themes in these and so many other stories of challenged Scrum adoption?…

  1. Scrum worked and helped initially

With Posit Science and Pipeline Deals they were startups with smallish engineering teams and they simply needed some initial rigor, some process to follow and Scrum gave them that. With Ultimate, who were already larger, and several hundred engineers, Scrum helped them to focus on short term goals and to deliver more frequently. All of these were good things. So the initial reaction is nearly always positive. While I am only using 3 examples here there are many more such stories where people report, “Scrum helped us initially.” Here is another one by Charles Suscheck. You don’t have to look hard to find more like this on the Web.

  1. Morale starts to drop after 9 to 18 months of using Scrum

All of these stories report that following Scrum started to damage morale after a period of time. There are usually several stated reasons for this: missed commitments / trouble planning and estimating; estimation and planning are taking too long and seem random, error prone, or just plain nonsensical; urgent work arrives more quickly than our sprint cadence and there is pressure to reduce the sprint length but we don’t know how to do that given the current overheads and the existing problems planning and estimating; there is pressure to break the sprint boundaries and add urgent work; product owners show favoritism to one stakeholder over others; product owners have trouble balancing demands from multiple stakeholders; stories are being split over multiple sprints and actual customer service is very poor with long lead times and a lack of predictability and transparency; product owners are suffering anxiety because they are making up numbers to facilitate prioritization and planning activities.

Scrum as a process is engineered to use peer pressure to produce results. This is true at the daily Scrum meeting where individuals make commitments on what they will work on and complete today and have to report the following day on whether they made their daily Scrum commitment, while entire teams makes sprint commitments for the collective work they will complete in a single time period such as two weeks. The problem with this peer pressure, commitment-based approach is that it uses very deterministic mechanisms for estimation and planning, in what is actually a non-deterministic domain. Meanwhile, the social engineering in Scrum also uses peer pressure to drive conformance. It is well understood in sociology that pressure to be part of a group can be strong and can often override individual judgment or logic. So when things aren’t working, individuals are pressured into believing the fault is with them, when in fact the fault is the use of deterministic methods in a domain that has a non-deterministic natural philosophy. When the system is to blame, Scrum teaches its practitioners to blame the people and not the system. This is at the core of the stress and dissatisfaction practitioners feel with Scrum.

I am now seeing similar reports from the field with Scaled Agile Framework which has largely adopted scaled up versions of many Scrum practices. It uses similar deterministic approaches to planning, estimation and prioritization over longer time periods. This practice is known as quarterly release train planning. Some of the same complaints – anxiety that the numbers were guessed in order to follow the process, and that attempts to resolve dependencies in advance are error prone and just guess work, while everyone is being held accountable for their commitments. Once, again, the same problem is being repeated – a deterministic approach is being used to plan 3 month windows of work when the underlying domain is non-deterministic. The practitioners are being set up for failure and made to carry the burden of this failure as their own incompetence.

  1. When things go wrong the consultants always blame the people

In every one of these stories, when the people and organizations complain about the stress that Scrum is bringing to them individually and organizationally, they are universally told that the fault lies with them. Scrum works! Scrum is without flaws! The problem lies with them, if only they were doing it right everything would be wonderful.

As Ken Schwaber has said, “Scrum works! Scrum is designed to work in a context. Your job is to change your context so that Scrum will work for you.” And I truly believe that this is a genuinely correct statement. It, however, disguises the truly difficult bit, “your job is to change your context.” If we look at Grant Ammons story, or Janice Linden-Reed’s story (we use it in our training classes), or the Ultimate story (captured for a future book), or others on our web site such as Nemetschek Scia what we see is a pattern that these were all firms where the business they were in simply made it impossible for them to control their environment and to create a context in which Scrum would work. It wasn’t that they were doing it wrong, rather, in order for Scrum to work, they would have to have changed their business and their business model. Ultimately, canonical Scrum was poor choice for them. If it helped them initially, it should never have been intended as a final solution, instead it should be a first step on a journey of process change and improvement.

Earlier this week, Larry Maccherone shared this story and cumulative flow diagram via his Facebook page. If you read the comment thread you will see that Mike Beedle, one of the founders of Scrum posts his thoughts. Rather than look at the data and analyze it, he quickly jumps to the conclusion that neither Scrum nor Kanban could help these poor souls because they are evidently very poor at technical practices and need to shape up. Compare Mike’s response to mine, as someone seasoned in analyzing cumulative flow data and with a deep understanding of flow efficiency and lead time. This post and the comment thread deeply underscores the differences between Scrum and Kanban communities. With Scrum the practitioners are almost always belittled and blamed, with Kanban we seek to understand the underlying natural philosophy of the domain, understand how the system is operating within it, and seek to find the systemic problems. With Kanban the system is always the number one suspect, not the people working within that system.

Interesting phenomenon that I have seen many times in the past. I have to say though that all but one such example in my…

Posted by Larry Maccherone on Saturday, January 2, 2016

  1. Scrum failure stories often involve leaders in the community and professional certified trainers and coaches

There are many stories of failed Kanban in the market: sometimes the failure comes from inappropriate alignment with culture such as resistance to transparency that comes with adopting Kanban boards; sometimes the failure comes from a failure to install and this would generally be avoidable if the protagonists had taken Kanban System Design training; sometimes a proto-Kanban implementation would have been easier initially than a full Kanban and a trained coach would have been able to help the organization scale the depth of their Kanban to the current level of organizational maturity and leadership tolerance. In general, where we see failed Kanban in the market, the failures come in organizations where they had no training, and did not invest in qualified trainers or consultants with credentials from Lean Kanban University.

However, with Scrum the failure stories are often very different. Often large numbers of the work force have been given certified training from Scrum Alliance certified trainers. Often leading consulting firms are involved and all of their consultants had certifications and professional credentials from the Scrum Alliance or other similar bodies. Despite the available expertise, Scrum remains challenged or fails and the story follows the pattern described in 1 through 3 above.

At Posit Science all their Scrum training and coaching was conducted by Rally, the largest Agile consulting firm in the World. At Ultimate the Scrum training had been conducted by Jeff Sutherland and later by Mike Cohn. Despite having two of the leading 3 Scrum experts in the World, Ultimate were unable to make it work.

The conclusion I’ve come to during the last 15 years of Agile is that Scrum has been widely oversold. There is no doubt that it can and does work but the circumstances under which it can be effective are rarely considered. There has in this respect been a considerable amount of professional misconduct in the overselling and the failure to make any reasonable consideration of context when choosing to implement it. The standard practice of blaming the people in the organizations having Scrum forced upon them inappropriately is a practice that is both morally and ethically bankrupt.

The importance of context and appropriate application of methods

Kanban is not an Agile software development method or process. Kanban was deliberately designed as a mechanism that acts on existing underlying processes. There needs to be an existing context into which we apply Kanban. So fundamentally Kanban eliminates a whole class of potential mis-selling of Agile methods. Kanban is the “start with what you do now” method and evolve from there. Every Kanban implementation will have its own unique workflow and policies. As a consequence, Kanban is adaptable to your context and culture.

However, this is not to say that we haven’t learned a lot about applying Kanban in specific situations. We now have the Kanban Appropriateness Appraisal Framework and the Depth of Kanban Assessment Framework. Both of these coaching tools are part of the standard curriculum for Kanban Coaching Professional training. The appropriateness appraisal looks at both the appropriateness of use of pull systems and the cultural fit for an evolutionary approach to change and incremental improvement. Not every organization has a suitable culture or the appropriate level of organizational maturity or leadership tolerance for Kanban to work. We now know that specific styles of Kanban implementation, implementations at different depths, correlate with different levels of organizational maturity, and as a consequence of this we now train Kanban coaches to be aware of this and to initially apply Kanban practices at an appropriate level of depth. The Appropriateness Appraisal and the Depth of Kanban Assessment Framework go hand-in-hand to insure a much greater level of success with Kanban implementations. It is the use of tools such as these and the knowledge and experience that went into creating them that mean you truly get value when employing a qualified Kanban Coaching Professional (KCP).

And meanwhile, it is never the people who take the blame for challenges with Kanban implementations with the exception of instances where the protagonists quite clearly never received any Kanban training or coaching, and did not make any attempt to actually understand what it is or how it works before they attempted to use it. At some level there is no accounting for stupidity. When people stick a board on the wall and declare they are doing Kanban, if it fails to produce the gains they were hoping for then the fault is quite clearly with them. Meanwhile, our community has an extensive capability for learning, including formal events such as Kanban Leadership Retreats which have led to the development of specific consulting tools such as the Depth of Kanban Assessment Framework and the Kanban Appropriateness Appraisal.

If you are feeling the stress and anxiety or a challenged Scrum or Scaled Agile implementation and you are sick of being told that the fault is with you, then there is an alternative path to agility – consider Kanban in 2016 and see how far it can take you!

Filed Under: Agile Tagged With: Agile, Depth of Kanban Assessment, Kanban, Kanban Appropriateness Appraisal, SAFe, Scaled Agile Framework, Scrum

Footer

Subscribe to our newsletter

Privacy Policy

Address

Kanban University
1570 W Armory Way Ste 101,
#188, Seattle, WA 98119
USA

Contact Us

info@kanban.university
© 2022 Kanban University. All rights reserved. Accredited Kanban Trainer and Kanban Coaching Professional are registered trademarks of Kanban University.