Kanban - the anti-SAFe for almost a decade already

Posted on July 31, 2013 by David Anderson

Increasingly this year I'm being asked to comment about the Scaled Agile Framework (of SAFe) being offered in the market by Dean Leffingwell (and others). One of the main Agile project management software vendors is pushing it very heavily with their clients as a solution to the increasingly recognized problem of scaling Agile adoption in large corporations. It is gaining some market traction. In two specific examples, both large corporations, one in the healthcare sector, one in the DACH region of central Europe and the other in North America, Kanban advocates have had some concerns about their firm's large scale move to adopt SAFe and asked me to share my thoughts with them. I thought I'd share them with everyone else too...

To be honest, I don't know a great deal about SAFe. I haven't taken the classes or spent much time studying it. Most of what I know is reported second hand from those who have taken the classes or are working in organizations that are now going through SAFe adoption. I am much more focused on solving real problems, for real clients and addressing issues in the market which are appropriate for Kanban, as well as encouraging the growth of the Kanban market and the ecosystem of vendors globally that support it, than I am with learning SAFe. However, from a brief skimming of SAFe material and things reported to me, I can make the following observations about how it differs from Kanban...

SAFe - a collection of proven techniques (including kanban systems)

SAFe appears to collect together a number of techniques from software development processes from the 1990s and 2000s. It offers these as one large framework. Individually, these techniques are considered successful and there are positive case studies showing their adoption and benefits. It is assumed that the collected set of successful practices will also be successful in aggregate. I would compare this assumption to individually testing the 300,000 components in a modern passenger jet aircraft and then declaring that as all the components are tested the entire plane composed of those parts is _SAFE_! The very nature of process tailoring from a framework means that every implementation may be unique and the process design is therefore untested and unproven. The new process is implemented in a single change. It isn't implemented in an evolutionary fashion that allows each incremental step to be tested for fitness and selected based on its success. The risks from this are well established historically.

The concept for SAFe adoption within an organization is a familiar one - clients should employ a (so called) "Certified SAFe" consultant to assist them in tailoring the elements of the framework appropriately for their organization. To me this seems awfully similar to Rational Unified Process (RUP) from the 1990s but updated to include Agile practices from the 2000s. Kanban is even included, somewhat bizarrely as a portfolio prioritization method. This strikes me as serving some need to include every current buzzword and show that, somehow, SAFe has "Kanban inside." I'm not impressed with the Kanban related material or its suggested usage in SAFe.

Assumptions

Where SAFe really differs from Kanban and why I chose the title for this blog post, is in a combination of the delivery mechanism and the underlying assumptions about how to drive and manage change in knowledge work and creative industries. SAFe is delivered as a framework that must be tailored. Ideally you pay an expert or team of experts to do this. They design your solution from elements within SAFe and then they manage a transition initiative to "install" the process solution in your organization. This approach fits right in with the requirements in CMMI ML3 for process tailoring. It could be straight out of a 1990s textbook on process engineering. It's a process-centric approach delivered using change management techniques that are 80 years old and most strongly associated with the early years of the McKinsey consulting firm operating with manufacturing businesses in the North East of the United States. So SAFe offers you individually proven techniques and practices from the previous two decades delivered with an almost century old consulting model developed for 20th Century production industries. There is an underlying assumption that the consultant knows best and change is imposed from outside and its adoption is managed using a planned approach within a project framework. This has been a popular and successful model for many consulting firms for so long, so we must assume that is is popular with clients too, or surely they would stop buying these services? It is fair to say that this approach is the antithesis of the Kanban Method!

Peter Drucker defined the term "knowledge worker" (in the 1960s) as someone who knows better how to perform their work than their supervisor. He didn't think to add the phrase, "or industrial engineers, process consultants, or experts from outside the firm." I think that is a pity! It seems we continue to live in an era where we continue to believe that the process design consultant knows better than the workers about how to do their work. Most consulting firms operating in the Agile Software Development space offer a process engineer led approach but cunningly call these people "Agile Coaches" to soften the resistance and present a veneer that is modern and acceptable to a highly educated workforce. It remains an approach that is underpinned by the assumption that the coach knows best. Kanban abandons this notion. With the Kanban Method we assume that the workers know best how to do their work and are also best at discovering what is impeding it and affecting performance and customer satisfaction. What they need is a mechanism to understand their problems, a method to evaluate those problems, models to suggest changes and improvements, and empowerment to make the changes required. Kanban delivers this. Kanban delivers evolutionary change, by the workers, for the benefit of the whole system. There is no concept of a process designer, or managing a transition initiative to a designed or tailored solution.

Kanban and Complexity

Kanban is about installing an adaptive capability in your organization, about taking a management led approach to cultural change. Every knowledge worker is a manager. They manage work and make decisions that affect the performance of the business that they are part of. Peter Drucker observed that "every knowledge worker is an executive." They make decisions that affect the bottom line performance of the business and often those decisions are made without the knowledge or input from a supervisor.

It is well understood that knowledge work involves complexity and that a complex situation requires an adaptive approach in order to be robust to the uncertainties and unknown events that may emerge. Part of that complexity is that human beings resist change in organizations. The traditional managed-change consulting approach is appealing to buyers and sellers because it comes with a plan, a schedule and a price. It can be measured, and invoiced, and audited and so forth. What it doesn't account for is that people resist. Kanban was specifically designed as a method that accepts that people do resist change. The concept is to install a mechanism that catalyzes and motivates internal change. You start with what you do now and you evolve. What makes Kanban new and fairly unique is that it embraces the human condition and is designed to work with human nature rather than agaist it. Organizations adopting Kanban evolve in their own ways through a series of management decisions - decisions made by an often highly empowered workforce.

Abandoning a Process-Centric Approach to Improvement

One organization, I was told, adopted SAFe, in preference to Kanban "because SAFe offered a requirements definition solution." Indeed this problem comes up often for us. I am often asked in classes, "Can you teach us a better way to write requirements (and/or define finer-grained work items)?" It seems many organizations adopting Agile methods stuggle with requirements definition. My answer is always, "yes, I could, but it is not the business I am in." My preferred method for requirements exploration and definition is the Coad Method and Peter Coad's modeling in color and feature definition technique adopted in the Agile method, Feature-Driven Development, more than 15 years old now. This method of requirements exploration and definition, is in my opinion, far superior - faster, leaner, better, cheaper - than anything else that emerged in the 1990s or any of the Use Case modeling techniques offered in RUP or derivatives during that same time period. It is also fair to say that I am an expect level practitioner of this method. I also know all the experts in the method. It would be straightforward for me to make a business from offering the Coad Method approach to requirements discovery and elaboration as a service. However, teaching requirements definition is not the business I am in. I prefer to refer people to sources such as Ellen Gottesdiener, or Jeff Patton who are doing good modern work in requirements elaboration.

I came to develop the Kanban Method precisely because scaling Agile adoption with Feature-Driven Development at Sprint PCS and later Motorola (over a decade ago), met with resistance. The prime focus of resistance was adoption of a new approach to requirements exploration and development - the Coad Method. Asking people to change their behavior, to adopt a different way of working, was hugely threatening. After several years of trying, in 2003 I decided to focus on a whole different problem - the problem of reducing or eliminating resistance to change. A process-centric focus wasn't working without a lot of money, positional power and fear to motivate individuals to fall into line. What was needed was a cultural approach to self-motivated evolutionary change. All of this is documented in my most recent book, Lessons in Agile Management. If you seek to understand Kanban, how it came about and what makes it different from first generation Agile methods, that story is told in Lessons in Agile Management. It is heavily ironic that Kanban came about for me because of the problems of scaling Agile adoption in large corporations - problems that I recognized as early as 2002 as a recurrinng pattern - and that now SAFe is offered in the market for very similar reasons - other attempts to scale Agile adoption such as Scrum-of-Scrums now appear to have largely been discarded as ineffective. Two more disparate solutions to the challenge of delivering agility at scale, such as SAFe and Kanban, are hard to imagine.

Silver Bullets and Panaceas

This brings me to my final observation about SAFe and Kanban. Another company told me that they adopted SAFe because it was a single solution (that they could buy from a single vendor.) This is very convenient but does it work? The buyer wants to believe in a "silver bullet" - that one solution that will solve all of their problems. Some vendors will seek to make offers and package frameworks of techniques as a single solution, as they know there is a market for it. I am afraid I don't believe in "silver bullets". Kanban is complete in the sense that it delivers what it claims - an adaptive capability for evolutionary change. It is not a process definition or a framework to be tailored. It will not help you architect software or perform tests or write requirements. For these technical practices you will have to look elsewhere. What Kanban enables you to do is identify the areas that need improving and focus your efforts. It enables you to seek out great solutions in niche areas and spend your time and money wisely. I'm cynical about cure-all, panaceas. It's difficult in this modern era to be an expert at one thing nevermind a great many. Developing the Kanban ecosystem globally, we're trying to be good at one thing - a hedgehog concept, if you like - we are seeking to be good at delivering a repeatable solution for adaptive capability through a focus on management training, better decision making and a change to a higher social capital, more effective and empowered culture. We do this by teaching and aiding adoption of the Kanban Method.

It is inevitable that many people in the market will find it convenient to choose a single vendor, to select what they believe is a single solution to all of their problems, and to believe that this solution can work over a fixed time period using a managed approach to the adoption of a new process solution, designed by experts who know best. And I am fine with that! Kanban was never about a religious conversion of the masses or an attempt to bring the world of knowledge work to the one true way of behaving. It has always been about solving real problems, for real people and business through an approach that is humane, aligned with the human condition and the complex nature of creative knowledge work. It's about helping people who want help and have sought out a new modern approach, a different way of working to improve their situation and deliver greater customer satisfaction.

Conclusion

The Kanban Method will coexist with SAFe in the marketplace. People will choose between a modern 21st Century approach to complex situations or a familiar 20th Century approach to change and their software engineering processes. Choice is good in a marketplace! Kanban offers a counter-intuitive innovative modern approach. SAFe offers something familiar. People need alternatives to evaluate, and from which to select the approach with which they are most comfortable. Many will choose something that feels familiar and intuitive and we have to accept their choice and respect that. Coexistence of SAFe and Kanban is a good thing. Providing alternative approaches to large scale business agility is a good thing. Both approaches will carry the label "Agile." Both will be marketed as solutions scaling Agile. I believe there is considerable irony in that.

Comments:

Helpful viewpoint

SAFe keeps cropping up in conversation at the moment with increasing frequency, so thanks for documenting your viewpoint.

My favourite line is "[Kanban] embraces the human condition and is designed to work with human nature rather than against it."

neither is perfect.

Some of the comments that follow this article are symptomatic with what i see as the problem with any Agile framework, but specifically SCRUM and SAFe - the idea that any customer/business requiring an idea of scope, delivery phases and budget up-front aslre somehow "quaint" or living in the past.

Kanban is not perfect, but it is designed based on business models that actually have to produce products on time and on budget. SCRUM and the SAFe relative are based on inward-facing ideals that somehow you can always de-scope, extend deadlines or drop deliverables, whereas businesses actually have a legal obligation to contractually agree budgets and schedules.

SAFe, to me, represents an attempt to address the fact that SCRUM doesn't scale to enterprise levels, nor does it cope well with inventive tasks. The Kanban "pull" of tasks allows for WIP-level to define Velocity without the need to guess at tasks up-front to plan Sprints, only to fail on delivery. Kanban is not perfect by any means, but it is light enough in its footprint and lack of ceremony that adoption is far eaier and it can sit nicely inside a phase-gated model for programme delivery easily.

Kanban Method is a Coaching Method

"With the Kanban Method we assume that the workers know best how to do their work and are also best at discovering what is impeding it and affecting performance and customer satisfaction."

This is the definition of a coach, as defined by the International Coaching Federation, and is one of the reasons I think the Kanban Method is a Coaching model.

"The International Coach Federation adheres to a form of coaching that honors the client as the expert in his/her life and work, and believes that every client is creative, resourceful and whole. Standing on this foundation, the coach's responsibility is to:
• Discover, clarify, and align with what the client wants to achieve
• Encourage client self-discovery
• Elicit client-generated solutions and strategies
• Hold the client responsible and accountable"

Thanks,
John Miller

As I said to another so

As I said to another so called thought leader, this oneupmanship won't do any good to anyone, David. Calling Kanban better than SAFe or any other method sounds degenerative and tries to divide people into various camps. This won't do any good in the long run. I see LKU as a money making Business and anyone who dares to stand against you is shunted from the community itself. Is this how you envisioned Kanban method to be? "Respect to people" should be the foremost value to uphold, which I don't think is happening here. Here, 2 camps are fighting against a new one, coz they are fearful that they are going to lose some business on training or consulting.

I'm not sure whether you'll allow to have this comment posted. But, if you do, I would still have some faith in you.

Agaur Rua

Excellent assessment

This nails it: "People will choose between a modern 21st Century approach to complex situations or a familiar 20th Century approach to change and their software engineering processes."

It dismays me just how tight so many are clinging on to old ideas—and perhaps even worse convincing themselves that new packaging and buzzwords makes the old ideas new. SAFe is rooted in old-think. It may help organizations keep the status quo breathing for a while longer, but breathing is not living and eventually someone has to make the decision to turn off the life support machine. Companies embracing 21st century ideas will survive, the others will not. This is inevitable.

Great insights

Great insights David! - and a bit of nostalgia too, re FDD. I will never forget Singapore or Glenmorangie!

You are right that the model of consultants coming in and analyzing the processes and defining a future state is 80 years old and does not work.

But what does work is if one takes an _AGILE_ approach to this. Processes are a critical aspect of what goes on outside of and around projects: all the things that projects rely on, like deployment, and security, and how projects are created and resourced in the first place, including contracts. All these things are processes. So these things need to be re-worked, because agile requires that a-lot of this be done in a collaborative, cross-functional manner, rather than a silo based manner. And making that happen is quite hard. And this is all about process - not the process of projects but the process of things that support projects.

So what I advocate is taking an agile approach, rather than a "here is the solution approach". Just as you say, the latter will not work. So I challenge managers to come up with better processes. I make _THEM_ define the future state. And we don't do it BDUF, but we take an issue-focused approach, one problem at a time. And then we re-calibrate and adjust - experiment.

You are right that the SAFe framework will no doubt lead to "SAFe certified" consultants and people coming in to tell us the answer, and they will be wrong. Agile is first and foremost about thinking, and as you say, there is no "silver bullet", no canned answer for this.

No framework should be applied out of the box. We need to use our brains - we need to think!

- Cliff Berg

An Agile Consulting Model

Hi Cliff,

Great to hear from you after so long!

Yes, I agree an Agile Consulting model is required. We do talk about this in my coaching workshops. Agile Consulting looks a lot more like true management coaching, where the coach is really a catalyst for a thinking process.

For this reason, we are now positioning Kanban as a management training and coaching method and differentiating it from a process methodology. When people think processes and process engineers or coaching they stop thinking for themselves and making decisions about specific problems. We want to teach people to manage their work and actively improve their service delivery.

I hope you'll find the space and time to come to one of our conferences. It would be great to talk about this stuff. Reach out to me if you would like an invite to the Leadership Retreat in Monterey, CA in January.

Best wishes
David

Thanks

Insightful and historically accurate assessment of SAFe. Apparently the gold rush in on.
Thanks for the blog, David.
Ken Schwaber

When does Ken like kanban?

This is interesting. The last time I read from Ken, he was criticizing kanban (as a substitute of Scrum).

When does Ken from Scrum like Kanban by David?

The last time I read something from Ken, I think he did not like Kanban which he was criticizing as a Scrum substitute.
I am glad that Ken has found a common enemy with David in SAFe.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options

To prevent automated spam submissions leave this field empty.