In the introductory Kanban post, I provided some background on Kanban and in Part 2, I went on to discuss several ways Agile and Kanban have been put into practice together, including examples of some of the several different ‘flavors’ of Kanban being used in software development.
Now I want to discuss some of the key tradeoffs that might occur in using Kanban systems for agile development, leave you with some food for thought and discussion, and provide some resources for digging into the topic further if I’ve stirred your curiosity a bit.
When comparing Kanban to other software development approaches, there are some potential gains and tradeoffs:
Kanban is the new kid on the block in the world of Agile Software Development, but its roots are far from new. Toyota has been using it as a lean principle for some time now.
The continuous nature of Kanban seems to be very interesting and could be a welcome departure from the typical iteration-based approach that many of us are used to. I suspect, however, that this kind of approach would require even more discipline to pull off with success.
I like the idea of Kanban. I think the trickiest part, however, is the ‘linear flow’ that the process assumes. Software development, after all, isn’t exactly the same as an assembly line used to produce cars. I have seen that sometimes the flow is non-linear, or that it’s not always a clean handoff from elaboration to development to testing. Sometimes design and development are happening in parallel, for example.
The hybrid Kanban-Agile systems seem to offer the most promise for enjoying the gains Kanban has to offer without suffering through most of the pain that could occur with a potentially topsy turvy environment and loss of cross-functional collaboration.
I discussed these hybrids in Part 2, including Lean+Agile Kanban, which uses Agile (Task) Kanban synchronously within each process and Sustaining Kanban (for separate and serial process, like development, testing, etc.) asynchronously across the whole value stream of processes; as well as Kanban Nano, which users both a project level Kanban board, on which a card represents a user story and a team level board on which each card represents a task.
It seems to me then, that agile methods and Kanban can be complementary, much as the many variations of agile are complementary to agile itself – contrary to the opinions of some who see them as conflicting. I fully expect there will be additional hybrid Kanban-Agile systems tested in a variety of development environments that we may not have even thought of yet.
What are your thoughts? Do you see a future for further implementation and integration of Kanban in agile software development? What are some of the possibilities you imagine?
Here are some additional resources, some of which were used in researching this 3-part Kanban feature.