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:

1. What if Agile Certifications were a Political Party?
2. The Agile Political Landscape Series: PRINCE2 Agile and One Nation
3. The Agile Political Landscape Series: LeSS and The Greens
4. The Agile Political Landscape Series: DSDM and Katter’s Australian PartyDSDM and Katter’s Australian Party
5. The Agile Political Landscape Series: DSDM and Katter’s Australian PartyDevOps and Teal Independents

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.

This article was originally published on LinkedIn by Daniel Luschwitz. The next article in the series is ICAgile and the Left-Leaning Independents.

So far we have covered the Leadership Cell pattern and the Mitosis pattern.

In this blog I will cover my personal sentiments on managing, refining and decomposing pipelines when delivering using Agile across multiple teams.

Generally I use the word pipeline management instead of terms like Program or Portfolio Kanban, mostly because the term is simpler to understand and the usage of Kanban implies a solution that there may not be a problem for.

I have seen three patterns used for pipeline management at scale:

1. Dual Track with separate ownership
2. Dual Track with team ownership
3. Just in time team flow pull

Let’s take a look at the pro’s and cons of these in some more detail.

To Dual Track or Not, that is the question

Dual Tracking is a concept that originated as part of Dual Track Scrum – where teams were often seen doing some backlog preparation or actual initial thinking of work one Sprint in advance:

When doing this technique the reality is that it creates context switching for individuals across two sprints – the current and the next planned Sprint.

My main issue with Dual Track Scrum has always been that it has been dressing Agile up in Waterfall clothing. It creates and encourages the idea that Discovery occurs in one Sprint, Delivery in the next Sprint and, dare I say it, scarily some people end up doing testing in the following Sprint.

Well, imagine that at an even bigger scale. This is what it tends to look like:

From top to bottom this is the context switching breakdown (worst case scenario). Firstly, delivery teams may be supporting any production issues that arise from the previous increment that they have delivered (note I use the term increment to indicate a number of Sprints that has resulted in a release).

Secondly the team is working on the current increment, delivering user stories. If they are unlucky they are dual tracking here too – ie working across two Sprints (2nd and third rows).

Thirdly they may be involved in the shaping of the work coming up for the next Program Increment. In the three pipeline management options I gave at the start of this blog this equates to the second pattern “Dual Track with team ownership” as the initial discovery isn’t done by a different team or subset of non team individuals.

In the advent of a really massive piece of work then there may be even further upstream work, breaking massive boulders of work down to feature like rocks. Think of this as a rock crushing machine. In my experience, at scale teams rarely get involved in this activity.

And lastly we have all the other stuff that teams end up having to do – <insert bureaucracy activity here>. If they are super lucky they get to have time to think and reflect on themselves as individuals and seek opportunities to improve their own capabilities.

It shouldn’t be a surprise to anyone that teams barely deliver when put under these constraints and expectations, and yet I do find that often it is very unclear to leaders of such teams that such extensive context switching is occurring.

The first pipeline management option, “Dual Track with separate ownership” reduces the amount of context switching down by having either a different team or key individuals like a designer and an architect look at bigger work coming down the pipeline in order to assess its customer and business desirability and viability and whether it is feasible given constraints, value earned over cost, etc. More commonly than not, these people aren’t or haven’t for quite some time been involved in actual feature delivery. Whilst they can provide a buffer to the team having to do some of this activity, it is at a high risk that the solutions that they are coming up with are unimplementable, over designed, or are based on poor assumptions. Additionally they create a need for a handover, which is often poorly executed.

Whilst you could certainly put in process to reduce these risks, why over engineer the process?

As a core principle for Scaling Agile, my number one rule is “Remove handovers and dependencies”. Which brings us to…

Just in time team flow pull

Each option has it’s pros and cons. The Just in time pattern means that the backlog for the set of teams is very lightweight in fidelity and knowledge. Think of these backlog items as initiatives (I am trying deliberately to avoid words like Epic, Capability and Feature as the hierarchy varies based on which scaling model you use). In my mind, an initiative is the sort of thing you might put on the release notes to customers when you do a new app store release, or something big enough to do a sequence for customer onboarding. Initiatives can take as little as three weeks or be as big as six months of work for a single team.

Initiatives are de-coupled from the other teams delivering in the same product through good shaping of scope and good team design (which we will cover in a future blog post). As a team finishes delivering an initiative they will pick up (pull) a new one and begin the discovery process on it. It tends to look like this:

At the tail of this approach the team is likely to prioritise first and foremost the release and support activities. Their next priority is doing Discovery/Inception on the next initiative. In the learning period where they may be waiting for customer feedback they can fill the gaps with technical debt.

You can see visually the difference between the reduced context switching of this picture and the previous one is quite significant. It does come at a cost – the cost of ensuring that the team is as independent as it can possibly be from the other teams delivering on the same platform. It requires not only good work prioritisation from a backlog perspective to limit two teams working in the same area, but also great technical practices to limit integration risks and be able to release at any point in time.

I really love this approach because it empowers the team to release when they are ready and empowers them to know when they are ready to begin coding. One risk is that they may spend too much time in Discovery, but even Dual Track has this risk. Another risk is that they may begin Discovery and then determine that the initiative isn’t viable. This could also occur in the Dual Track scenario, but a new backlog item would then need to be picked up and potentially those stakeholders may not be prepared to spend time in Discovery. The core of the issue is that there is no buffer time if the stakeholder(s) are unavailable, whereas buffer time exists in the Dual Track approach.

The reality? Out of about forty-five initiatives I have seen an initiative be cancelled once, so why design a process solution for such a small occurrence rate? Where you work may be different and more work may be cancelled in Discovery, so choosing which approach to take may be dependent on the failure rate of Discovery.

As a coach I try to move organisations towards Just in Time team pull but it takes time to remove the dependencies and handoffs first.

Source: Opinion: What 2017 Has in Store for Culture & Methods

Source: Vale Agile Collaborator and Leader Jean Tabaka