Agile Zone is brought to you in partnership with:

I wrote my first program in Z80A when I was 14 on a ZX Spectrum and ever since I have been hooked. I love writing code of any flavour as well as being passionate about the coding process. I have worked professionally in the software industry for the last 15 years using Microsoft Technologies, and I code at night in PHP, HTML, Javascript and CSS. Chris is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Decompiled: Kanban

  • submit to reddit

Now Kanban is not something I have practiced but for completeness of this series I wanted to write an article on it. So I have spent the last few weeks reading about what is Kanban and is it agile.

So what is this Kanban thing anyway? Kanban is like Scrum in that it can be used as a process to help a development team control and deliver software. Unlike TDD and Pair Programming which are practices within a development process Scrum and Kanban describe the process itself(although this is up for some discussion!).

Kanban was originally part of the the lean manufacturing movement. This is where you keep you stock low and minimise work in progress so that you can keep costs low and push profit margins up. Many years ago when I worked on an assembly line manufacturing electronic goods this is what we used to do. Not that I realised at the time.

So how does this relate to agile development? Well if we look at an introduction to Kanban we see that the main features of the process is the visual element. This leads us to one of the main differences between Scrum and Kanban in that with Kanban delivery is more about flow, than sprints. Use of a Kanban board allows the development team to have a visual representation of where they are in the delivery of features, whereas with Scrum you would look at the work backlog.

Another key feature of Kanban, which some may argue is also present in Scrum is the emphasis on using Kanban to improve the overall process and thereby improve the product. With Kanban this is a built in feature of the Kanban philosophy whereas with Scrum it is not. Since I read the The Timeless Way of Building many years ago I have become a believer of quality being a factor of what you build and how you build it, the way is as important as the what, and this aspect of Kanban has a strong appeal. At least to me.

So is Kanban agile? It is not strictly an agile process, but it is more a way of continuously improving your development process. In fact some authors would argue that Kanban should not be used for software development..

However the visual element of Kanban and the way it fits into the current idea of continuous delivery does make it a very appealing strategy for agile teams. As always with these questions the decision should lie with the team. Whether it is agile or not, Kanban certainly has it’s own benefits to offer.

Published at DZone with permission of Chris Odell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)