The first thing you hear, in situations like this, is usually a version of: "We tried agile. It didn't work here." This company — a targeted advertising start-up that had recently been acquired and was doubling its headcount — had tried Scrum for two years. They had the ceremonies, the roles, and the tickets in Jira. What they didn't have was any of the benefits. So they'd stopped.

By the time outside help arrived, the organisation had a firmly closed door when it came to anything that sounded like a new way of working. Which meant that introducing something needed to be done carefully.

Starting without announcing it

The approach used was what I think of as "Kanban by stealth" — introducing Kanban practices without leading with the name or the theory. This is not deception. It is pragmatism. When an organisation has a strong anti-agile reflex, the fastest way to neutralise it is to stop using the vocabulary that triggers it. The focus stays on the actual problem: the work is taking too long, people can't see what's happening, nobody can predict when anything will be finished.

The first activities were diagnostic. Interviews with team members, managers, and stakeholders revealed a consistent picture: too many things active at once, unclear priorities, knowledge concentrated in a small number of people, and a growing sense of frustration with a constant stream of unplanned work disrupting anything planned.

Visualisation first

The organisation had been relying entirely on Jira to track work. Jira is a powerful tool, but it is easy to hide inside — to have a technically complete picture of work in progress that nobody actually uses to have the conversations that matter.

The first structural change was moving to physical and digital visual boards that made the actual flow of work tangible. Stand-ups shifted to walking the board from right to left — starting with work closest to completion, discussing anything blocked or changed. This simple reversal focuses attention on finishing rather than starting, which turns out to be the more important discipline.

Tickets were redesigned to distinguish different types of work: planned features, unplanned requests, technical work, and operational issues. This sounds administrative, but it has an immediate practical effect: teams can see whether unplanned work is a minor annoyance or systematically overwhelming everything else. In this case, it was the latter.

Limiting work in progress

As visibility improved and trust built, WIP limits were introduced — first informally as a shared discipline, later more explicitly. The principle is straightforward: the system cannot absorb unlimited work simultaneously without everything slowing down. Limits force the team to finish before starting. They surface bottlenecks. They make the cost of overloading visible.

Engaging stakeholders in this process was critical. When customers and internal stakeholders could see the flow of work in real time, they stopped sending anxious status requests. Transparency reduced the overhead of managing expectations — because expectations were now grounded in reality rather than optimism.

What improved

Within months, several things had changed measurably. Predictability of delivery improved significantly. The number of items simultaneously in progress dropped, which had the paradoxical effect of increasing throughput — fewer things active, more things actually finished. Technical bottlenecks that had been chronic became manageable as knowledge sharing improved.

The CTO's reflection on the process was instructive: the "start with what you do now" principle of Kanban had been the key. It bypassed the resistance that comes with telling people to work differently. Instead, it helped people see their current work more clearly — and from that clarity, improvement followed naturally.

Nobody needed to change their job title. Nobody needed to attend a two-day framework training. They just needed to be able to see what was happening, and to be trusted to do something about it.