Please note: This is article 6 in a series that explores mapping agile certifications to what Daniel Luschwitz and I have coined the Agile Political Spectrum. The previous blogs in the series are available here:
A note on our political comparisons: These political comparisons are playful metaphors designed to illustrate philosophical positions on the agile spectrum. No certification body was harmed in the making of this analysis.
Every political spectrum has its quietly effective parties. Not the idealists demanding systemic overhaul. Not the establishment parties jostling for the centre. But the movements that do serious, disciplined work, build a loyal following, and somehow never quite break through to the mainstream because a louder, more charismatic neighbour took all the air out of the room.
In the agile certification world, that party is Kanban.
Ask most practitioners if they ‘use Kanban’ and a majority will say yes. Ask them whether they actively limit work in progress, track flow metrics, use service level expectations, or practice evolutionary change discipline and the numbers drop sharply.
David J. Anderson, who pioneered the Kanban Method for knowledge work, has himself declared “Kanban is ubiquitous, it’s time to declare victory.” And in one sense, he’s right. Kanban boards are everywhere however the Kanban Method is far less common than you might think. That gap, between widespread adoption of the surface and shallow understanding of the substance, is precisely what makes Kanban one of the most underappreciated certifications on our Agile Political Spectrum.
Kanban’s roots stretch back to post-war Japan and the Toyota Production System, not as ideology, but as operational discipline. The original Kanban was a signalling card used to trigger replenishment in a pull-based production line. No manifesto. No cultural revolution. A control mechanism designed to reduce inventory risk and improve flow.
When Anderson introduced the Kanban Method to knowledge work in the mid-2000s, he was deliberate about what it was and wasn’t. He made the positioning explicit from the outset: start with what you do now, respect current roles and responsibilities, and pursue incremental, evolutionary improvement.
Kanban does not require new roles, it does not demand reorganisation or assume that hierarchy must be dismantled. Instead, it asks organisations to visualise their work, limit work in progress, measure flow, manage risk, and improve gradually over time. This is not structural reform. It is structural preservation combined with operational discipline.
Over time, Kanban matured into a serious professional discipline. Kanban University formalised the certification pathway, building a rigorous body of knowledge around flow metrics, service-level expectations, probabilistic forecasting, and the Kanban Maturity Model. The emphasis was never on ceremonies or team rituals. It was on service delivery systems and organisational capability.
So who is Kanban’s political counterpart?
As our right-of-centre, disciplined, and chronically underrated agile certification, Kanban maps to the Australian Democrats.
The Australian Democrats were a centrist party founded in 1977, best known for holding the balance of power in the Senate and their rallying cry: “keeping the bastards honest.” At their peak they wielded influence well beyond their vote share, doing serious legislative work while louder voices on both sides dominated the headlines.
The parallels with Kanban are immediate and striking.
Both built serious, rigorous bodies of knowledge and operated with genuine discipline. Both accumulated loyal, knowledgeable followings that punched above their weight in terms of real-world influence. And both were ultimately drowned out, not because their ideas were wrong, but because a louder movement captured the room.
Against the noise of certification ecosystems that scaled aggressively through the 2000s and 2010s, Kanban University’s comparatively modest global network barely registers. And yet, in organisations that genuinely implement it, the Kanban Method consistently delivers improved flow, reduced risk, greater predictability, and a cleaner picture of organisational capacity.
The Democrats were never trying to win government. They were trying to make the system work better. Kanban was never trying to replace whatever else was in the room. It was trying to improve how work flows through whatever system already exists. Both found meaningful influence in that role. Neither got the recognition their contribution deserved.
Kanban boards have become so ubiquitous that many practitioners genuinely believe they are “doing Kanban” simply by moving cards across columns in a tool or on a physical whiteboard. Far fewer implement WIP limits with discipline. Fewer still track cycle time, use probabilistic forecasting, or develop capability in flow analytics. The Kanban Maturity Model, one of the more thoughtful frameworks for understanding organisational development in the agile world, is largely unknown outside the Kanban community itself.
This creates a peculiar market dynamic. Kanban suffers not from bad press, but from misrepresentation by familiarity. Nobody declares Kanban adoption a failure. They just assume they’re already doing it. The certification therefore struggles to communicate its genuine depth to a market that thinks it already knows what Kanban is.
The agile world generated years of passionate debate, consultant wars, and certification inflation around louder frameworks, which paradoxically gave them more visibility. Kanban slipped in the back door, got implemented on whiteboards everywhere, and then got largely forgotten as a serious discipline.
Kanban sits on the right-conservative side of our Agile Political Spectrum, but in a particular way. It is not conservative because it adds bureaucracy or resists change. It is conservative because it genuinely respects existing structures and pursues improvement within them rather than demanding their replacement.
This makes Kanban valuable in a range of contexts that more progressive certifications struggle to serve. For teams operating in complex, highly regulated, or politically sensitive environments where structural redesign is simply not on the table, Kanban offers a credible, evidence-based path to improvement. For leaders who need to demonstrate results without triggering a governance revolt, Kanban’s language of flow, throughput, and risk is far more accessible than the vocabulary of transformation.
For organisations genuinely committed to a product operating model and cultural transformation, Kanban may feel insufficient on its own, though it often becomes essential as a delivery discipline within that broader journey. The ability to visualise and manage flow doesn’t become less important once you’ve reorganised around products. It becomes more important.
If you are an organisation wondering whether Kanban ‘counts’ as agile, or whether it’s just a board tool, the answer is that the board is the least interesting part. The discipline underneath it is where the value lives.
The Australian Democrats may no longer exist as a political party. Their legacy, however, is woven into the fabric of Australian legislative history in ways that rarely get acknowledged. Kanban risks a similar fate, its ideas absorbed into every tool and methodology without credit, its depth largely undiscovered.
Like a good Democrats senator, Kanban won’t promise you a revolution. But it will make the system you already have work considerably better. If you are attempting to reduce waste, bottlenecks and the invisible work quietly choking your organisation then Kanban might be just what you need in keeping the bastards honest.
Please note: This is the fourth article in a series that explores mapping agile certifications to what Daniel Luschwitz and I have coined the Agile Political Spectrum. The previous blogs in the series are available here:
A note on our political comparisons: These political comparisons are playful metaphors designed to illustrate philosophical positions on the agile spectrum. No certification body was harmed in the making of this analysis.
Every political spectrum needs its bridge-builders. Movements that refuse to fit neatly into traditional categories, that challenge established divides, and that prioritise outcomes over ideological purity. In the agile certification world, that’s DevOps.
DevOps emerged in the late 2000s from frustration with the fundamental divide between software development and IT operations. Developers wanted speed and change; operations wanted stability and control. The result was organisational silos, blame cultures, and slow, unreliable software delivery. In 2009, Patrick Debois organised the first DevOpsDays conference in Belgium, crystallising a movement that had been brewing in organisations struggling with this dysfunction.
The core insight of DevOps was never primarily technical, it was cultural. Yes, automation, continuous integration, and infrastructure as code became associated practices, but the fundamental shift was breaking down the wall between Dev and Ops: shared responsibility, collaborative problem-solving, and optimising for the whole system rather than individual silos. You can’t buy DevOps in a box. You must become it.
There is no single definition of DevOps as it became a set of practices and principles defined by the community. A number of bodies and vendors emerged offering certifications, including those focussed on culture and principles (DevOps Institute, ICAgile, and SAFe), and those on technical implementation (AWS, Microsoft, Google, and others). Like the Teal Independents, these certifications are themselves independent. There is no single governing authority, no party platform, only a shared set of principles. This is part of what makes DevOps sometimes misunderstood. And like the Independents movement itself, the ecosystem continues to grow, with DevSecOps, GitOps, and MLOps extending the same philosophy into new domains.
So who is DevOps’s political counterpart? As our left-progressive but pragmatic certification movement, DevOps maps to the Teal Independents.
The Teals emerged in 2022, winning traditionally Liberal seats by offering something that didn’t fit conventional party lines. They are progressive on social and environmental issues, yet centre-right on economic policy, focused on fiscal responsibility and business effectiveness. They rejected the false choice between environmental action and economic pragmatism.
DevOps certifications mirror this exactly. Progressive on culture by breaking down silos, challenging hierarchies, emphasising collaboration; but pragmatic on delivery through efficiency, automation, reliable systems, measurable outcomes. Just as the Teals blended blue economics with green values, DevOps blends cultural progressiveness with operational pragmatism. Both movements emerged from rejecting a false dichotomy that had paralysed their respective fields.
This positioning explains where DevOps sits on the agile political spectrum. It sits firmly on the left-progressive side because it enables something fundamental – continuous delivery. The technical foundation that makes product operating models possible.
Think of it this way. An organisation might reorganise around product teams, leadership might embrace product thinking, but if it still takes weeks to get a change into production with manual testing, change approval boards, scheduled release windows and the like, then the organisation chart has changed but the operating model hasn’t. DevOps is what closes that gap. Without it, the transition to product-led ways of working stalls at the delivery pipeline.
For practitioners, DevOps certifications provide essential frameworks for understanding software delivery as a sociotechnical system. It speaks to developers who need to care about operational concerns, and to operations professionals who need to embrace change and automation. For organisations, DevOps practices aren’t optional extras to bolt on after establishing product teams. The capability to deliver continuously must be built deliberately, and that requires both cultural change and significant technical investment.
Like a good independent MP, DevOps certifications won’t hand you a four-phase implementation plan. But they will help you understand what genuinely needs to change (culturally and technically) to make continuous delivery real.
You must be logged in to post a comment.