I finally have a semi-usable version of a Kanban tool running. I built it on the so-called “LAMP” (https://www.til-technology.com/post/fiat-lamp) software stack as a learning exercise in web development. My initial version (https://www.til-technology.com/post/kanban-poc) was essentially a mock-up using HTML / CSS. I could update tasks by editing the actual HTML, so I was able to use it (after a fashion), but there was no database, and no way to directly edit the content.
Building this “real” version, using the PHP programming language, has been a wonderful learning exercise, and I have learned a lot. I have now taken the step of importing all of the content from that earlier HTML “version” into the “real” version, and am able to create issues and do some basic editing. This is far from “production-ready”, even as a learning exercise, so I have been calling it version 0.9.
I have already noted several issues and bugs, and thought of a number of updates and enhancements, but I now have something I can actually use – theory is nice, but actually using a tool can be the best way to find bugs and identify enhancements.
I’ve mentioned Kanban several times while describing this whole process, but wanted to comment on what it actually is, and what all the fuss is about.
Kanban (https://en.wikipedia.org/wiki/Kanban_%28development%29) is a popular project management tool/methodology which was derived from a process developed by an industrial engineer at Toyota. It became part of the Toyota Production System (TPS - https://en.wikipedia.org/wiki/Toyota_Production_System), which revolutionized automotive manufacturing.
Without going into detail, TPS was a precursor of later “lean manufacturing” (https://en.wikipedia.org/wiki/Lean_manufacturing), “just-in-time production”, and similar approaches, which focused on understanding and optimizing workflows.
The word “kanban” means “signboard”, and is based on signalling that a particular item needs to be restocked. The signal can be as simple as the “two bin system”, where you have two bins of a particular supply, and your signal to restock is when one of the bins is empty. The key is to understand the rate of consumption and minimize the buildup of excess inventory.
Traditionally, manufacturing plants would hold large quantities of many different supplies in order to ensure that they always had sufficient raw materials, but this becomes less and less practical when the “raw” materials are actually components which are also manufactured.
Taking a simple automotive example, if you have a plant able to produce 10,000 cars per month, you will need 10,000 steering wheels per month. So, just set up a repeating order of 10,000 steering wheels each month, right? Well, yes, but what if you’re really only producing 9,900 cars each month? Over time, you will build more and more excess stock, which requires more and more space. Also, what if a defect is found? You could end up with an enormous stock of defective inventory.
An example of a simple Kanban system is the “three-bin system”, where there is a bin on the factory floor, one in the factory store, and one at the supplier. Each bin would have a removable card which includes the product details and ordering information – this was the original “kanban” (or “signboard”). When the bin on the factory floor is empty, the card is sent to the factory store, and the factory floor bin is refilled. This empties the bin at the factory store, so they send their card to the supplier, who sends the contents of their bin and then works to refill it.
This is all endlessly adjustable, but the simplest adjustment is simply to adjust the sizes of the bins.
Toyota formulated six rules for the application of kanban (taken from the wikipedia.org article):
Each process issues requests (kanban) to its suppliers when it consumes its supplies.
Each process produces according to the quantity and sequence of incoming requests.
No items are made or transported without a request.
The request associated with an item is always attached to it.
Processes must not send out defective items, to ensure that the finished products will be defect-free.
Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.
Most of this is tracked electronically now, but the underlying philosophy is easiest to think of in physical terms.
Now, on to software development.
This is where it gets interesting. Software development is not the same as manufacturing, but can learn many important lessons from it. The basic principle of kanban is to manage work by balancing supply and demand. In software development, think of it as balancing capacity and demand.
Now consider juggling.
Huh?
No, really. While a lot of people pride themselves on their ability to “multitask”, people are really just switching from one task to another. And, setting aside the question of stress and reduced effectiveness, time is lost on each “switch”, so there is a net loss in productivity.
So, juggling one task is analogous to juggling one ball. It’s simply tossing it from hand to hand, and most people can do this indefinitely.
Most people can easily learn to juggle two balls and, after a bit of practice, can generally do it for quite a long time.
Three balls takes some practice, but there are quite a few people who can juggle three balls for quite a while.
Four or more balls is where it gets progressively harder – harder to learn, harder to do, and you can’t do it as long. (https://en.wikipedia.org/wiki/Juggling_world_records)
If you consider “multitasking”, people generally “max out” at about three tasks at a time. Any more than that, and productivity starts to be significantly (and increasingly) affected.
But what does this have to to with Kanban?
Everything, actually.
Kanban for software development (and really most other things as well) focuses on limiting your work-in-progress (WIP). I would generally recommend limiting WIP to three tasks, though there is some debate about issues being “on hold”, where you are “stuck” for some reason. (If you have too many issues on hold, though, that’s a red flag that something is wrong)
Kanban also focuses on maintaining and prioritizing a to-do list. Don’t try to remember it, and don’t try to do everything. Dump it on the to-do list, and review it regularly – both to prioritize and to remove anything which is no longer relevant.
The idea of using post-it notes as a visual metaphor for Kanban works very well for me – it is reminiscent of the physical nature of the original Kanban, and adapts it to the information age.
As I said, the current version of the tool works (mostly), but I’m not happy with the look of it yet. I have more information packed into the “new” post-it notes, but I’m less happy with the layout and “feel” of them. That said, I have a bunch of ideas and hope to have an updated version soon. (For now, I’ll stay in PHP, I think. Once I have a reasonably “mature” version of the product, I may look to re-build on another platform.)
Cheers!
Comments