Though already passingly familiar with Kanban, an innovative scheduling system for lean and just-in-time (JIT) software production, I gained a deeper appreciation for the history and theory behind the practices after reading David J. Anderson’s book. I became convinced that adopting Kanban’s practical, simple, and accessible methods would be the ideal, lightweight approach to improving our development processes.
Many of Kanban’s ideas addressed firsthand pain points in our existing culture — starting too much work, switching context too often, and low transparency. However, as I quickly learned, changing an entrenched culture takes time, diligence, open minds, and the support of experienced practitioners.
Before we began implementing Kanban at DEG, we were tracking outstanding work items through basic burndowns on spreadsheets. Kanban involves mapping current processes into a value stream, creating work items as cards on a board, pulling these items through the value stream like an assembly line, and limiting the amount of concurrent work (WIP) done in any one lane.
With this rudimentary understanding of the Kanban mechanics, the development team began setting up card walls and mapping our existing workflows into lanes. The practices, however, had been explained with only a cursory introduction to their history and evolution. And, when these practices were in turn introduced to the client service and project management teams, even less time was spent giving context. This lack of context gave less credence to the practices. The card walls were deemed experiments with relatively little participation by team members outside of the development team. This slowed our overall rate of adoption and buy-in from the whole team.
Despite the limited participation and application, visualizing our work proved beneficial within weeks. For one of our projects, we learned that what was long believed to be a bottleneck at the development level was actually a hang up at the client service level. Each day we saw cards stack up at the internal review step. Features were not being presented to the client in a timely manner, and as a result, feedback was delayed. When revisions finally rolled in near the end of the project, they strained the development team, resulting in the perception that developers were the scarce resource.
As we continued adopting Kanban practices, we realized another unexpected benefit. It became easier to predict when to schedule shared resources. Our UI developers were used intermittently as features were completed upstream. They typically took a fraction of the coding time used. Seeing the work items on a board made it obvious when the UI team’s time was necessary and what particular features were ready for them to work on.
We experienced some quick wins with the initial adoption of Kanban-based practices, but broader implementation was not a seamless transition. The teams experimented and revised. Cards were not always uniform and it was difficult to know how fine-grained to get or what activities and non-functional requirements should be represented and how. Sometimes we built out boards with too many lanes, which were often skipped and perpetually empty. We got ahead of ourselves by drafting value streams that represented the process we aspired to rather than simply modeling the reality of our current process. In each iteration, however, we learned something and left the process flexible and open for change by the team.
Along the way there has been a continual stream of questions from curious team members who are trying to understand what Kanban is and where the value is. Will this help us estimate a project? How will we know when a particular feature will be complete? How will Kanban ensure that we can meet a fixed delivery date? Can we apply Kanban to other areas of the business outside of development? While Kanban practitioners and leaders provide guidance regarding these questions, this is not Kanban’s greatest strength. Through the use of cumulative flow diagrams, cycle time calculations, and other metrics gathered during execution, Kanban does offer a means to plan and predict. However, the real appeal is that it gives self-organizing teams the flexibility to learn, adapt, and change through the transparency and conversation it facilitates.
What I’ve learned from the Kanban experiment is that, while somewhat simple to understand and explain, there is a tremendous amount of theory, research, and depth behind it. This coupled with the constant introduction of new staff, projects, and teams means that perpetual education is a must. At DEG, this has included inviting speakers to present, formal training, lunch-and-learns, and hosting the local Limited WIP Society user group. There is a wealth of fascinating books, talks, blog posts, and other reference materials focusing on the broader application of lean thinking from which Kanban stems. We continue to learn from these references and evolve. Kanban has more traction and momentum than ever at DEG, and seeing our potential realized through its implementation is particularly thrilling.