Kiss-ee, kiss-ee Kanban
Kanban is one of the latest emerging trends in Agile and Lean software development. I don't claim to be an expert in it... I am learning about it myself. Many are writing about it right now and only a few have direct experience of it... but based on my accumulated experience in iterative development... well, it just feels right.
"Kanban," in Japanese means, loosely translated, 'card or sign'. In a Lean production system, Kanban is a method which uses standard units or lot sizes with a single card attached to each. A new card is "pulled" into the system only when the work represented by an "in progress" card is completed.
Some may say that it's no different to what they've been doing already... and indeed, I've worked on many teams where there are certainly parallels between how we managed cards on our boards and the Kanban approach. But, there is so much more to it than that...
Kenji's subsequent article Kanban Applied to Software Development: from Agile to Lean also provides an in depth discussion on the properties and dimensions of Kanban that I found thoroughly useful in deepening my own understanding of the approach.
Also referenced in the article is an evolution of Kanban applied to software development called the Kanban System for Sustaining Engineering (KSSE - pronounced Kiss-ee). In particular this example vocabulary and collection of 'ground rules' for such a system was especially useful.
There are numerous other writings and presentation materials on the subject available... I'll let you google KSSE for yourself.
What my reading on the subject and reflection on my own experiences has done is make me question the concept of iterations.
KSSE doesn't have fixed-length iterations. Instead, iterations are of variable length and can run in parallel. KSSE takes a 'minimum marketable feature' (in the form of a User Story) and focuses on delivering that, transitioning it through a number of states. The team maximises the flow of each item or "thing" by pulling that thing through each state, signalling that there is now capacity for another "thing" to be added to the queue.
In a way, you can think of several overlapping iterations occurring in parallel in order to maintain constant flow. The cycle time on each User Story will vary depending on its size and complexity.
Experience tells me that this requires enormous discipline to ensure that the size of each User Story is genuinely kept to a minimum otherwise, before you know it your product owner or BDUF oriented team-member would have you working on a single story for 3 months... this would be cause for concern.
The KSSE approach just feels right for me for many reasons... One reason is very specific to my specialisation... As a specialist in the testing-space I often find that the skills distribution in a team tends to be somewhat arbitrary - often based on preconceptions of how many testers you should have in relation to the number of developers. Kanban encourages you to visualise the true flow of your team and adjust skills or focus based on bottlenecks in your actual throughput - making the effects of underestimating the number of testers you have much more visible (whether it is interpreted that way is another story).
When would I consider starting to apply KSSE to a project that I was working on? Well, I wouldn't abandon iterations immediately. I would certainly start with what Kenji describes as "Agile Kanban". This brings some of the concepts into play and brings some of the benefits with it. Iterations need not be affected...
Once the team was comfortable with that, then - and only if we found the fixed iterations a limitation rather than a help - I would consider breaking down the traditional iterations into a more KSSE type approach and trial it for a period of time.
Even if that seems to far off for you, I encourage you to find out more about Kanban and KSSE - it has certainly given me some new options on how to manage projects.