In collecting information for the ebook, Choosing an Agile Scaling Framework: A handbook for decision-makers, I was surprised to notice that the Kanban Method kept bubbling up to the top of the list of choices in nearly every scenario. For every business need except one, it was the best or one of the best choices. (The exception is the case when the organization only intends to pretend to change. For that purpose, less-expensive alternatives are available.)
Why would that be true? I wondered.
For context, allow me to reiterate a couple of basic points. There have been many success stories about agility at the level of individual teams or small groups of teams, and now larger organizations are interested in bringing the same sort of results to the enterprise as a whole. In answer to this need, quite a few “agile scaling frameworks” have been devised, and are now being marketed.
As all these products are based on the same general ideas, some of them distinguish themselves by insisting they are not frameworks, but rather something else. Is it meaningful to lump them all together and compare them? One could say yes or no, I suppose.
In any case, Kanban Method is not one of them. So, why include it in the ebook? Because it is sold directly against the agile scaling frameworks. An organization is unlikely to buy both an agile scaling framework and Kanban Method. And the community around Kanban does tend to take an “us versus them” approach to marketing. That opens them up to comparison. Therefore, it’s reasonable to include it in the comparison.
Proponents of an agile scaling framework will insist theirs is different from the others. What do they have in common, then? I’ve already mentioned they are all based on the same general ideas. A second characteristic is that they all comprise a set of rules to be followed. Each defines organizational structure, team structure, process steps, roles and responsibilities. Each coins new buzzwords for the same ideas, and each creates compelling and unique diagrams of the same thing, making it appear like different things.
Not to be too snarky about all this, I know of cases when a framework was applied mindfully to produce very positive outcomes. I know individuals who use a framework as a tool to help their clients do the right things. The problem is more about how these things are marketed, and about what people actually do with them, than about the frameworks as such.
In the majority of cases people are just looking for a set of rules to follow by rote. They don’t implement a framework mindfully. They merely layer the superficialities of a framework on top of their industrial-era mentality, which they never question.
So, the typical case is that an organization seeks to qualify for the “agile badge” by undertaking a superficial and largely fake adoption of an agile scaling framework. They never change the way they think. They retain individual employee performance appraisal with a stack ranking scheme. They retain heavyweight governance procedures based on blame-shifting and lack of trust. They retain year-long budget cycles that depend on detailed predictions 18 to 24 months into the future. They retain a belief in the Iron Triangle and Death Marches. They pursue the false economies of component teams and offshore personnel. They see humans as “resources.”
That problem is the responsibility of client organizations. Purveyors of agile scaling frameworks introduce a different problem. They propose a one-size-fits-all solution. In broad strokes, all large organizations based on industrial-era thinking share a few key characteristics. But once you dig below the surface, you find each organization to be unique. A one-size-fits-all solution doesn’t actually fit all. Broad patterns are common to most large organizations, but the devil is in the details. A standard solution begins to break down as soon as it goes beyond the initial stage of adoption.
If Kanban Method emerges as a superior choice, what is different about it? My observation is that the agile scaling frameworks all bring a predefined “end state” to the table from the outset. Trainers and consultants focus on helping clients implement the rules of the framework. Leadership continues to think and act as they always have done. For that reason, there is little chance of deep or lasting improvement.
Kanban Method takes a very different approach. This is an oversimplification, of course, but in essence they train the leadership of an organization to think differently. Then the re-tooled leadership takes the organization in whatever direction they choose. Trainers and consultants help them measure the right things, understand the meaning of the measurements, and choose appropriate next steps. This approach is far more effective than merely instituting a set of rules and new job titles.
Having come to the realization that this was the key difference, it occurred to me others surely must have been thinking along the same lines. There surely must be additional alternatives to agile scaling frameworks.
That’s how I discovered Leading Agile. They aren’t mentioned in the book about agile scaling frameworks because that isn’t what they do. They have a model that helps clients understand their organization’s relationship to its own market, and to understand how the organization might have to change in order to realize business goals. Then they use a sort of roadmap to guide clients forward. It isn’t a rigid set of rules, but a flexible outline. They speak in terms of guiding rather than training. No two solutions are the same.
The Leading Agile model, which they call a “compass,” is described on their website here: http://www.leadingagile.com/our-compass/. It’s different from agile scaling frameworks in that the frameworks assume the same solution applies to all organizations and all circumstances. It’s different from Kanban Method in that it actually does suggest a way forward above and beyond awareness and measurement. And, with all due respect to the Kanban community, Leading Agile isn’t focused on selling expensive training classes.
Working as an independent subcontractor in this space, I’ve been frustrated in recent years as the agile community began to address Late Majority and Laggard adopters. The community’s approach has been to pander to industrial-era leadership in order to win contracts. Everything is about “scaling” now, and “scaling” apparently means re-instituting industrial-era management methods under an “agile” banner.
A number of agile consultancies and staffing agencies that used to take a neutral approach to helping clients have now changed their focus, and they merely sell one of the agile scaling frameworks. “Agility” is defined, simply, as following the rules of the chosen framework. Often, there is no connection between adoption of the framework and any business objectives. The framework is an end in itself. Typically, they don’t push clients to make any substantive changes at all, at any level. They introduce new buzzwords and stick paper on the walls. Below the surface, nothing changes.
As a subcontractor, I’m usually brought into the picture after expectations have been set, and my only task is to push the framework onto the client. The work has ceased to be about helping clients achieve goals and solve problems. It’s only about buzzwords and job titles; yarn, pipe cleaners, and plastic building blocks. The possibility to achieve meaningful work as an agile coach is fading into history.
Fortunately, better choices are available.
The Kanban community applies scientific method, well-reasoned models, meaningful measurement, and experiments to help clients progress toward their own goals. Leading Agile does much the same, adding a flexible roadmap that helps people address enterprise-scale problems through lean and agile principles, rather than by re-instituting industrial-era methods.
If your organization is dissatisfied with the status quo, I suggest you take the time to investigate alternatives to the popular agile scaling frameworks. The two I mention here are probably not the only ones. Look for helpers who will actually help, rather than simply sell you a framework.