History
Kanban at its most basic level is a Japanese word that means visual token or instruction card, or yes, there are as many ‘roughly translated …’ definitions out there for ‘kanban’ as there are kanban web sites and product solutions out there on the interweb. :-)
Many years ago and even some sailing vessels today use signal flags. These flags were introduced at some people’s estimates approximately 300 years ago. And they are part of the maritime standards and laws still today; although I would hazard to guess at the percentage of people today with boats that could read them. The point here is not to suggest signal flags are Agile. They are nevertheless ‘instruction cards’. As such, the message below could mean “AGILE” or “I have a diver down and you need to stay clear unless you’re a pilot at which you should approach at low speed while I alter my course to port (the right) because the ship is quarantined so when I said ‘port’ before I actually meant starboard.” You decide. :-)
Eventually Toyota started using the principles of kanban for manufacturing in the 1950s.
And seriously, at none of these times within any of a multitude of this or other examples anywhere across the decades or centuries ago was anyone thinking "Agile" project management. They weren’t even thinking about JIT either for that matter until the 1960s in Japan and the 1980s in North America.
The word, the principles of kanban and signal or instruction cards existed all the same.
Skip forward to the Present
The popularity of Agile gaining as much momentum as there are people abusing it to serve whatever agenda they have, and for that matter people and companies applying it as intended and gaining huge benefits as a result.
There are also an incredible number of people and companies schlocking the next best mouse trap. Intermingled among them are some really awesome products that can support and enhance the effectiveness of teams within companies to achieve results unimaginable until they actually see it for themselves.
So here are some general good practices in no particular order you may just wish to follow if you’re going to use ‘kanban” and “Agile” in the same breath.
- Unless you're a team of 3 or less and the project isn't that complicated or complex, it needs to be so much more than three columns of states of work encompassing To Do, In progress, Done or some variety of those labels. If that describes your team and the project, sure use kanban; you might just love it! Just don’t call it Agile … at least just not right away.
- The principles of Lean and Limited WIP are important. Create distinct rows for features and priority.
- No tool is Agile if neither it nor those using it are adhering to the principles behind Agile. And in the context of this article in particular, the first value statement in the Agile Manifesto itself … “Individuals and interactions over processes and tools”. That leads me to another factor all too many take undue liberties with; the word is ‘over’, not in place of, or instead of … but that’s another article for another day.
- Whatever tool you plan to leverage, a tool with a Personal Kanban and work by person views so you can see who is overloaded (or overloaded themselves) and is blocking or blocked by others will very likely at one time or another be great a feature to have available to you. Some tools address this by creating Done columns in between functional group columns, or colour-code the story cards.
- If you've got multiple cards that someone says they all have together in their own personal kanban you really should be asking yourself why. Seriously, I've seen project teams of about 20 people with 3-month development windows where they've created over a thousand story cards. Now that's an example of where those deconstructing stories should be checked for OCD! :-) In all seriousness, any team that does this has with very high certainty eliminated any scheduling benefits available from taking an Agile approach to what they are doing.
- The point at which some process manager or anyone else over-complicates how a kanban approach is used that is also the point you are no longer following the principles of kanban -- as I believe is described so very well in the video attached to http://whatis.techtarget.com/definition/kanban as a good example.
Conclusion
Kanban can be an incredibly awesome and effective way to manage projects. Kanban is not Agile on its own unless the specific guiding principles also applied to it. For that matter, no tool on its own is Agile.
References
https://www.crisp.se/file-uploads/kanban-kick-start.pdf
https://kanbanery.com/ebook/GettingStartedWithKanban.pdf
http://agilemanifesto.org/principles.html
