The difference between Kanban and SAFe for enterprise agility
Increasingly this year (2013) 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.
