If you figure out a way to live without a master, any master, be sure to let the rest of us know, for you would be the first in the history of the world. Lancaster Dodd, “The Master”
Introduction
Kanban is a process theory that has become popular in the software industry, chiefly by those who describe themselves as project managers. Even though its aim is to optimise a current process, it has been seen by many as a replacement for the dominant methodology of Scrum. Kanban doesn’t define any roles, but those who propose it, seem to view the manager as the arbiter of success who sets the developer on the right path.
Scrum
Scrum is Extreme Programming with the valuable technical practices ripped out. Scrum became palatable to management types precisely because it didn’t refer to programming activities such as TDD, CI, refactoring etc, but what was left was an empty shell of a methodology. Because Scrum doesn’t have a project manager role, project managers en masse became “Scrum Masters” by attending expensive Scrum Master certification courses. Mind-sets rarely changed however and “Scrum Masters” still sat comfortably in their master role, micro-managing individuals in “their team”. Command-and-control methods still prevailed and only lip service was given to developer self-organisation. In fact, the developer lot hasn’t improved since the Fordist worker; both highly paid (compared with the average wage-rate) but still tied to the assembly-line/desk. This led to what Bob Martin described as a “hyper-productive mess”.
From Scrum To Kanban
Without software development teams changing too much, they progressed overnight from “doing Scrum” to “doing Kanban” and the “Scrum board” became the “Kanban board”. Even though the essence of Kanban is (1) No fixed iterations, and (2) Limits on work-in-progress, I have seen “Kanban” teams that still have sprint planning and no WiP limits!
The Cult of Kanban
In the book “Kanban”, David J Anderson preaches like the leader of a cult: Here are some of his more extravagant claims:
“The simple act of limiting work-in-progress with kanban encourages higher quality and greater performance”
“Kanban is giving people permission to think for themselves.”
“Once you balance demand against throughput and limit the work in progress within your value stream, magic will happen.”
So Kanban is “magic” and allows people to “think for themselves”. Were we not able to think and consciously create before Kanban? Were we not able to release quality software before we tasted its potion? The above claims are both wild and arrogant and anyone with basic critical capabilities should reject them.
Quality
DJ Anderson seems to think that quality is something a manager bequeaths, he tells us: “Focus on Quality (sic) is first, as it is under the sole control and influence of a manager” and the “Focusing on quality is easiest because it is a technical discipline that can be directed by the function manager.”
Later in the book, he changes tack, and tells managers to insist on how developers should work, enumerating practices and tools that he clearly knows nothing about. In complete self-delusion he makes grand and nonsensical statements like “Domain Specific Languages reduce defects”. Managers are not the sort of people who should be telling developers how they should work. It is only the people who write software who can advise others on how they write software.
Quality in software is something a team of good collaborative developers offer, buttressed by established software engineering techniques. A manager cannot give quality, just as a tester cannot assure it.
What Kanban Doesn’t Say
Kanban doesn’t say quite a lot. Its aim is not to radically transform, but to drive “change by optimising the existing process”. Anderson tells his followers to “resist the temptation to change workflow, job titles, roles and responsibilities, and specific working practices” – that is, not to interfere with all the things that matter.
Kanban offers us very little. Anderson gives us five core properties:
1. Visualize the workflow
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
5. Use Models to Recognize Improvement Opportunities
From the list above there is only limit work in progress that differs from any other Agile methodology. Kanban is something being made out of nothing. Where is the actual substance? This is an ideology marketed to managers to assure them of their value.
The Developer and Thinker
All worthy ideas in software development are derived from developers, managers have usually usurped and corrupted these ideas.
Over the last few decades the only major ideas on the software process are that software creation should be iterative and incremental and that we should use Extreme Programming engineering practices. These and having good software developers are the only realities of good software development.
When quality software is being made by developers who organise and self-manage, Kanban’s interpreters attempt to reassert the validity of managers.
anti-agile 