Kanban and Agile Software Development — Part 3


Where we left off

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.

The key tradeoffs between Kanban and other approaches

When comparing Kanban to other software development approaches, there are some potential gains and tradeoffs:

  • The just-in-time, pull concepts behind Kanban could allow you to gain the ability to have continuous flow, instead of a series of iterations with distinct starting and ending points.
  • With a continuous flow, you could also gain the ability to take on larger projects over longer periods of time, without being constrained by sprint/release timeboxes.
  • With Kanban, you can make changes to the backlog anytime.
  • While you lose some of the constraints of sprints and release timeboxes, you may also lose some of the protection they offer in keeping things on track, and you could end up in a more topsy turvy environment..
  • If you use specialist teams, you might lose cross-functionality advantages (clash of perspective, etc) offered by other methods. I’ve seen conflicting perspectives result in a better product in the end.

Conclusion/Takeaways

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?

Some good places to get more information

Here are some additional resources, some of which were used in researching this 3-part Kanban feature.

Leave a Reply