Kanban is a technique that was elaborated in the manufacturing industry for years. But it also works nicely for knowledge work such as project development. Especially evolutionary change management in IT organizations lends itself perfectly to the Kanban field.
David J. Anderson speaking about Kanban at the LAS Conference 2011 in Zurich.
What is Lean Software Development anyway?
The foundational pillars of Lean are debated by different authors:
– Value stream
– Continuous improvement
– Respect for people
– Holistic process approach (aka. systems thinking)
Western Lean thinking has focused on waste elimination in comparison with the Japanese «Toyota Way» that has a broader definition of muda, muri and mura and the cultural aspect Kaizen.
Knowledge work, though, is different, waste can’t be identified as easily.
Western Lean literature and consulting tended to focus on waste elimination. This was both easy to do and useful in manufacturing but has proven problematic in knowledge work.
The concept of Lean Software Development has been around since 1993, and yet by 2008 you didn’t meet anyone doing it.
‹Agile Management for Software Engineering› by David Anderson is about eliminating bottlenecks in business processes.
David has been talking managing flow for 6 years, but despite support for cumulative flow diagrams in many agile tools (almost) no one was doing it! Growing Lean adoption in the IT industry seems to be hard.
Agile methods are not creating Lean organizations. Extreme Programming is evidently a very Lean method. XP has very little waste. The Toyota Production System TPS divides waste into 3 types
– Muda: non-value added tasks
– Muri: unevenness (or variability) in flow
– Mura: overburdening
XP avoids Mura through use of tests and a tight definition of done. XP avoids Muri with skilled craftsmanship that can flow a story without hand-offs and a strict WIP (Work-in-Progress) limit policy of 1 story per pair. XP has little Muda as planning, coordination and delivery are lightweight and partly automated. Some XP practitioners have sought to reduce waste in XP with techniques such as Naked Planning.
The motivation for these changes that involved introduction of Kanban style techniques was further elimination of waste. However, Extreme Programming hasn’t been for everyone!
At his former shop David was asked to apply feature driven development to other departments than his own successful unit. Adoption was not great despite running on the same development environment. If not every organization is ready to adopt an Agile method, how can we encourage them to become more Lean? In comes the Kanban method.
Kanban is the enabler of a Kaizen culture & emergence of a Lean organization. Everybody suggests improvements, i.e. causes a Kaizen event. Toyota implements one improvement per employee per year. At General Electric improvements are implemented much more slowly via Six Sigma black belt projects.
Kanban systems are pull systems that limit work-in-progress and have been part of the Lean toolkit for 50+ years after WWII.
The goal is to prevent mura (overburdening) and control muri (unevenness) and encourage an evolutionary approach to change. Checking on software bugs is a disruption in the flow (muri). In developing the Kanban method, a change management approach that uses Kanban systems to provoke change, we are enabling organizations to do exactly that.
Kanban is based on 3 principles
– Start with what you do now (that’s not threatening…)
– Agree to pursue incremental evolutionary change
– Initially, respect current processes, roles, responsibilities and job titles as well as current processes
Nobody’s job is changing right from the beginning. The self image of the people is maintained as is, e.g. business analysts should not feel threatened.
Then… adopt the 5 core practices that are typical in successful Kanban implementations:
- Visualize workflow
- Limit work-in-progress
- Manage flow
- Make process policies explicit
- Improve collaboratively (using models and scientific methods
When … all 5 core practices are adopted, they form the seed condition for Kanban as a complex system where the items vary from shallow to deep complexity depth.
Silver Catalyst is a software tool for Kanban processes visualization.
Analysis often times suffers from non-instant availability of subject matter experts / business owners.
Leadership is the magic ingredient that focuses the communication around Kanban issues such as work in progress limitations. Bottlenecks have to be addressed or the flow is interrupted.
Kanban & Emergence
Emergent behavior is seen in nature when systems adapt to unfolding events. The simple rules of Kanban such as WIP limits, cadence, pull criteria, classes of service, are adaptable over time. Hence, Kanban creates a Complex Adaptive System within an organization, where process emergence is uniquely tailored to each project.
In Kanban there is no enterprise process definition, no shrink to fit nor stretch to fit. Kanban will evolve to fit for each project.
Iteration-less flow is a common motivation for adopting the use of a Kanban system. However, it is not core to the Kanban method for change management, e.g. you can add a Kanban system to Scrum and provoke evolutionary change.
A WIP limit on the input queue focuses attention on what to start next. It provokes focus on value, i.e. market adoption.
Limiting work in progress can catalyze incremental change.
WIP can provoke communication
Leadership is a key factor despite democratic processes.
Arm the team with transparency of the process.
Use models for understanding problem and improvements will occur.
What emerges is an organization that lives all the pillars of Lean. Pool systems, not waste elimination is key.
Eine gute Übersetzung auf Deutsch des Artikels von Jeff Patton Kanban leicht gemacht gibt es von Matthias Bohlen.
Kanban-Tool: Google Keep
Google hat ihr neues Notiz-Werkzeug Google Keep vorgestellt. Es eignet sich nicht nur, um Notizen zu erfassen, man kann es sogar als Kanban-Board einsetzen: