Part III — The Process
Kanban is cooperative multitasking. It doesn’t survive contact with real workloads.
Why your roadmap is always like the horizon. Always a journey, never a port!
I was brought into a cyber-security organisation of 50+ devs, where Sprints ran for 3 Months. Sprints were effectively quarterly roadmap blocks, and Standup(s) were effectively a Kanban without any WIP limits. They also had a designated “Scrum Master” and a designated “Product Owner” for the whole organisation1. The organisation had all the relevant tools, and had the ceremonial Agile-ish practices but delivery horizon was typically a six months to a year, depending on the complexity of the feature.
A week of observations was enough. I picked a team within the org who had a 3 Sprint Plan. This 9 person team had hour-long stand ups daily2, with commitments made that “this - the assigned ticket” would be done today3, everyday. The team was essentially running marathons camouflaged as Sprints. The problem was deeply structural, i.e, the Org’s PO specified “features” which were more like releases, to be delivered as one stack. The Org’s Scrum Master would just stack the break-up given by the engineers and sequence them out and end up with a nine4 month delivery and adjust the Sprint(s) accordingly. Digging through their Jira boards and the Control Charts it was evident where the problems were. This particular system was running on a 1000ms Tick Time, vs the typical 1ms Tick times. It was time for a Kernel Upgrade.
The team wasn’t slow. The scheduling quantum was too large for the work. I applied a simple two-week-time-boxed delivery plan for the team, with some simple rules: 1. two-weeks now, broken down daily5 and demonstrable 1. six weeks worth of backlog sequenced & estimated coarsely, and 1. a comma-separated list of goals in sequence for every two weeks for the next 6 two-week-time-boxes, essentially a quarter, rolling.
And later re-defined the Sprint to a two week period, much to the discomfort of many.
The first new “Sprint” was a disaster, after all how can you demonstrate work worth months in weeks. The ones who got it were able to demonstrate the Mock-UIs waiting for APIs to serve real data with. It took the backend engineers longer ( than “a Sprint”) but they started to make available the APIs while the Front-End army started to do more mocks ready for integration every sprint on the existing scaffolding( it wasn’t a “new” product ). By the end of Sprint 2 the team started to loop in QA for “instant QA” of the features integrated.
The “Committed vs Delivered” started to show( took 2 Sprints ) balance, then focus on the Speed6. By Sprint 3, the Goals(of the real Sprint ) started to be negotiated within the team, as in, the backend for feature X is closer to reality can we pick the frontend for X instead of Y. This self governance over these micro-milestones were evident, the speed picked up and the direction was clearly towards the end goal. This Velocity ( Speed + Direction ) eventually had the Roadmap Duration sliced by two thirds and a shippable delivery was handed to QA whose original planned goal was supposed to be 2 Quarters away.
Velocity rose. But that was the effect, not the target. #### Batch size
One big piece a month → a few small pieces a sprint. Reducing the quantum. Large batches: long uninterruptible run. late feedback, high cost of being wrong The number that makes it concrete: same nine people, same work, a third of the elapsed time. Not because anyone worked harder — completion, not effort, is what a calendar measures, and small pieces complete.
The usual fashionable migration is Scrum → Kanban7. Kanban = cooperative multitasking. Continuous flow, no timer, tasks yield when they choose.
Elegant, and works under one condition: every task is well-behaved. Sprints = preemptive scheduling. A timer interrupt at a fixed quantum, whether or not the task feels ready. The micro-governance that the team started practicing was the effect of the Scrum’s innate mechanism ( preemption )
Preemption wasn’t invented because it’s prettier — cooperative scheduling doesn’t survive real workloads. One badly-behaved task never yields and starves everything, with no preemption point at which anyone can intervene8.
In reality9 a WIP limit is much closer to admission control / backpressure than preemption. It prevents additional work from entering execution. It doesn’t interrupt a task already executing. Sprints impose a scheduling quantum. WIP limits impose admission control. Both create a point at which the system can reconsider what gets to consume capacity - preemptive scheduling. It was painful to see the worst combination of both Scrum & Kanban being practiced.
A nine-month plan is a working set that exceeds cache for most human brains. It spills to documents nobody reads, and every subsequent decision is a cache miss. Cutting the horizon to two or three sprints for a tactical team executing10 brings the working set back inside cache. It didn’t FEEL lighter for psychological reasons; it was lighter, as a capacity fact11.
To declutter the human brains burdened with planning for months the initial lookahead for
As the Velocity rises, so does the look ahead with practice, binding it early on was a constraint to keep the working set in the Cache, but it wasn’t the target12.
All of this was possible because the Act 1 team’s capacity was its own. Part IV is what it takes to make that true when it isn’t.
Scrum Master & Product Owner as designation is counter intuitive to me. I see both as roles than designations.↩︎
The standup is fifteen minutes. It is always fifteen minutes. It has never once been fifteen minutes.↩︎
It’s proof that god exists and Engineers still make commitments to finish today on the premise of god willing.↩︎
Humans plan nine months ahead — not because we believe it, but because the alternative is admitting we don’t know.↩︎
Their estimation flavour was “Time/Effort”.↩︎
Remember, speed ≠ velocity.↩︎
I want to be clear that I have nothing against Kanban, in the same way I have nothing against trusting people to form an orderly queue. It works beautifully in Tokyo and rather less well at a bar.↩︎
A priority inversion can still happen but repeats here are most likely an HR problem, not an engineering one.↩︎
The team effectively ran Kanban WITHOUT enforced WIP limits — Kanban in name only, a to-do list with columns, with a 3 Month Sprint. Also by-products of a POs & PMs at org level rather than at a team level.↩︎
It is probably the strongest argument for evaluating humans from the lens of tactical vs strategic or in other words, the Policy vs Mechanism.↩︎
Every month of plan beyond your prediction horizon is speculative work against a branch you cannot predict. It gets flushed.↩︎
Humans are the only systems capable of expanding their Cache.↩︎