We have come a long way since the early days of software development, or have we? I honestly am not too sure about that anymore. As we “advance” in some aspects I can’t help myself as to feeling a funny feeling of deja vu. So it comes to no surprise that the same is true with management. Although many managers are beginning to grasp the concept that managing a software projects in not the same as managing a manufacturing plants the majority are still stuck on the other site of 1890.
In the beginning our managers tortured us with the waterfall methodology. And we all hated it!! Then in the year 1995 a new star was born. SCRUM made its first baby steps and all was good. It was a quantum leap into the right direction and it looked extremely nice on paper. Developers could do more work and managers had less to do because the almighty scrum board would do most of their work. The methodology has gathered a cult following which is only matched by apple fan-boys in number and ferocity. And still the projects went overboard. To the ScrumBoys this was of course not the fault of SCRUM but the team that used it wrong. In hindsight I wish the bloody thing would have come with a users manual. With waterfall you had the almighty Gantt chart that clearly showed the way the project will fail. But with SCRUM that was not so easy anymore.
SCRUM has many problems when faced with the day-to-day reality of making unique stuff. So as it looks now we are getting a new contender that has proven itself in the auto industry. SCRUM is dead long live Kanban I hear the people crying while I still pickup the broken shards of my last project. And after my personal experience with SCRUM I am willing to give it a try.
So what is kanban? According to Wikipedia it is the following:
Kanban (or kamban in Hepburn romanization—kanji 看板, katakana カンバン, meaning “signboard” or “billboard“) is a concept related to lean and just-in-time (JIT) production. According to Taiichi Ohno, the man credited with developing JIT, kanban is a means through which JIT is achieved.
Kanban is a signaling system to trigger action. As its name suggests, kanban historically uses cards to signal the need for an item. However, other devices such as plastic markers (kanban squares), balls (often golf balls), an empty part transport trolley, or simply a floor location can also be used to trigger the movement, production, or supply of a unit in a factory.
The need to maintain a high rate of improvements led Toyota to devise the kanban system. Kanban became an effective tool to support the running of the production system as a whole. In addition, it proved to be an excellent way for promoting improvements because reducing the number of kanban in circulation highlighted problem areas
Nice little description and I must admit that my hopes are high again. But (there is always a but). After reading some articles of what Toyota is doing and what Kanban is doing I fail to see the direct correlation. In my world there is a big difference between creating a Toyota Prius door for the millionth time or creating moduleA for application Z for the first and only time. At Toyota there are dedicated workers that create doors when they are needed, I doubt that you company has a developer there that only does moduleA. So there goes reality! Well I still think that it will fair better than SCRUM. If for nothing else then because it gives the gun back to the development team. This gives the developers the power to shoot themselves at their own leisure.
But back to the world of normal. Kanban makes a major overhaul on the SCRUM Kanban board. The notion of a sprint is drooped in favor of the release cycle. All in all some cleaver “innovations” that could actually make sense. Before I run out of stuff to write about I would like to go through the 6 points that Toyota set up for Kanban:
- Do not send defective products to the subsequent process
I guess this is the zero defects myth again. Even Toyota failed at that. So this is a valiant point that every sensible developer wants to reach. So nothing new here.
- The subsequent process comes to withdraw only what is needed
In software we only code once and then reproduce until doomsday. So the subsequent process will take everything from the previous process. So not much sense there eighter.
- Produce only the exact quantity withdrawn by the subsequent process
We need only one and we produce only one. So make a big fat green tick on our TODO list.
- Equalize production
Create 1 consume 1.
- Kanban is a means to fine tuning
This makes sense. Nothing to say here.
- Stabilize and rationalize the process
Interesting point. But again the process does not repeat itself so there is no rationalization in something that only happens once.
I know that this is only true for one-off software. But then again most of software is.
In the end Kanban will bear the same risks as SCRUM and a few addition for free. It is up to the development team to make software effective. If you still think that Kanban will save you company or make your developers into super efficient coders that spit out code faster than the speed of light then you are beyond help. The only think that could help you is the Poepleware book, go and buy it.
All in all I hope that the history will not repeat itself.