Monday, February 04, 2008

KanBan is NOT Iteration-Free!

Regarding my previous posting about Software KanBan, much as I really do like it and have nothing but the utmost respect for the likes of Corey Ladas and David Anderson, there is one major quibble I have with some of the stuff being said ...

I think all the stuff saying it is Iteration-less and Iteration-free is a bunch of hooey! I don't agree at all and I think it is extremely misleading to say that Software KanBan doesn't use or need iterative development.

Don't get me wrong - I think I understand where they are coming from. There is often a great deal of recurring and heated discussion on numerous Agile forums about "Ideal" iteration length. I understand how folks can be sick and tired of that (to be honest, I myself never really paid too much attention to those particular discussion threads about ideal iteration-size).

The idea that is new or revolutionary for some is that release/feature content is decoupled from development! One or more features/requests are being worked in parallel, and every two weeks (or however long) some combination of newly developed functionality from those that are ready is selected to be released (rather than before development is underway).

But it seems to me that this is just an application of Agile-style development iterations applied to multi-project management. It is Releases that are decoupled from iterations (and hence iteration-free). But as I see it, the iterations are still present: they are where the development is, on the various feature "projects" that are being developed in an incremental and iterative manner, each at their own rhythm (some might be every two weeks, others might be less frequent, but they all find their pace).

I don't believe for one second that each of those features/requests are specifying and elaborating 100% of their requirements before they start coding anything. Looks to me like, for all but the smallest of requests, they may flesh out a certain amount of requirements up-front (be it lightweight use-cases, or even something a bit more formal), but only to a high-level or medium-level of detail. And from that point on through, the detailed requirements, implementation, and feature-level testing and integration-testing they are proceeding in a VERY MUCH iterative fashion.

It may not be a strict fixed length, in that the rhythm may fluctuate and readjust from time-to-time, but it definitely does have a regular rhythm! The length of any given "iteration" is fixed to the cadence of the feature-team (even if it is a team of 1 or 2). Not all iterations may be the same length, but any given iteration is working to a fixed due-date rather than letting that cycle stretch out until the "scope" is complete.

So don't let anyone tell you that Agile development need not require working in an iterative manner. It most definitely does (and at multiple levels of scale). Just don't assume it means that iterations must always be a property of a "release" as opposed to some other related chunk of work (possibly multiple ones proceeding in parallel).

It is not the releasing that needs to be iterative, it is the development. And if the releases are decoupled form development (which I think is a GREAT idea), then the development of any non-trivial sized feature or request still will need to proceed in an iterative manner according to some regular cadence that gets established.

No comments: