Implementing Kanban when there is no "what you do now"

Posted on August 01, 2014 by mikeburrows

David's recent post Kanban Litmus Test prompted an interesting question on kanbandev: How does Kanban apply if you don't have an existing process to change?

My first experience of Kanban was with a team that was still coming together. It was less start with what you do now, more start with a rough understanding.

We had a board on the wall supporting a very generic process within the first week. We evolved from there over a period of about 18 months:

  • WIP limits for certain columns (eg development) came very easily. Limiting WIP further downstream took longer for reasons both internal and external (no fundamental objections, but we faced some real challenges in getting stuff out of the door).

  • We soon found that we needed to visualize and organize the pipeline of upcoming work.

  • Later, we added a post-live customer validation phase. This was probably the single most important change we ever made in terms of the impact that it had on our relationship with the rest of the business.

  • Policies were maintained and observed by the team with some enthusiasm, to the extent that I - the IT Director - would be challenged if I took shortcuts! These policies evolved hand-in-hand with improved tooling, technical practices etc.

  • We added horizontal swimlanes and classes of service as the team grew and the work diversified.

  • After a reorganization, we had two kanban systems, running mostly in parallel (for different product sets) but with some overlaps and dependencies to manage.

Change-wise, I see no fundamental difference between this early experience and later ones. We started cautiously with barely enough kanban for us to get a handle on things (this is not how I would start now, but it's common enough), and like countless other implementations, we appreciated the clarity that the visualization and the limits brought and we evolved from there. However, it is only fair that I acknowledge some of the advantages inherent in our situation that went beyond our determination to evolve: there was little attachment to what was there already, there was no question that change would be necessary, and there were the expectations that naturally accompany the arrival of the new guy (ie me).

To be clear, the one thing we didn't do was to try to design a perfect "kanban process" up front, and I'm pretty sure that it would have hindered more than it would have helped had we done so. It was better that we always acknowledged how much we still had to learn.

Was this a serious implementation of Kanban? Clearly yes. To the three questions of David's litmus test:

  1. Did the customer interface change? Yes. Implicitly in the early days, just by focusing on some key deliverables. Later we addressed this explicitly, with customer validation, classes of service, scheduling policies etc.

  2. Did the customer contract change? Yes it did (for the reasons just given) but were I to do this again, I would have paid more attention to this aspect much sooner. My public emphasis on the agreement value that underpins the principle "agree to pursue evolutionary change" is significantly influenced by this experience.

  3. Did our service delivery model change? Yes, hugely. We knew our capability, made it visible and strove hard to improve it, all based on a thorough understanding of the dynamics of our process. Internal customer behaviour changed significantly in response too.

My forthcoming book Kanban from the Inside will provide some more insights into this story. It's due out in September; you can download for free the first three chapters of an earlier draft meanwhile, and you can follow @KanbanInside for progress updates.

Mike Burrows (Twitter:@asplake) is UK Director and Principal Consultant at David J Anderson & Associates.