Just to make it bit more challenging, this year my contribution is not an experience report but something more high-level and moreover not directly Kanban (I wonder why I even bother...). Anyway. lately I have been involved in helping projects succeed by making them working iteratively. Being of course currently very heavily inspired by Kanban thinking and by User Story Mapping, I simply combined these two into a process/method for 'iteratizing' a project (cutting it into small parts). Basically, creating an iterative and incremental way-of-working. So far, I am pretty pleased with the results.
Of course, by now everyone knows that working iteratively and incrementaly is the way to succeed. It has become so self evident that we kind of take it for granted. Though - to my knowledge - there hasn't been a concrete, effective and consistent method to do that. That is the focus of my abstract for this year's Lean Kanban Central Europe 2012.
Consistently building the right solution: Revisiting IID with Kanban Thinking
You have an idea for a perfect solution to your customer’s problems/needs and plan to use your kanban team to deliver it sooner. Will the solution live up to your customer’s expectations? Agile has a way to handle this issue: to develop your solution iteratively and incrementally based on your customer´s feedback. Though Iterative and Incremental Development (IID) is one of the oldest agile method, not much help is available to consistently produce the “right” increments - or minimal viable product (MVP) - that help you quickly develop the “right thing” for your customers.
Kanban Thinking has helped us to predictably and consistently deliver value sooner while getting better doing it. Could we use the same thinking to get the most out of IID?
Based on concrete examples, we apply Kanban Thinking to the venerable IID. We discover that a solution also has a flow and that it can be visualized. Based on this visualization we can break-down the solution into small valuable batches - increments or MVP - to limit WIP. We also discover that there are constraints to the development of the solution - call them “key value factors”, that are a function of the development constraints, risks and the customer’s intent - that can be used to cut the solution in “the right way” (e.g. optimizing for learning or value building).
The result is a method - heavily influenced by Jeff Patton’s User Story Mapping - that helps you consistently cut your solution ideas (hypothesis) into small batches of valuable product increments. Practically, it produces a roadmap over how to delight your customers, roadmap which should be regularly revisited with the feedback of each done increment. Interestingly, the method can be used at all development levels from creating MVPs to creating epics, stories and tasks.