That was the title of my presentation last Thursday at Agiles 2009, 2nd Latin-American conference on Agile Development Methodologies. I have designed this presentation trying to summarize what the Kanban community is trying to spread recently as a new way to manage knowledge work.
Download the slides here to follow this post about the presentation
By the way, knowledge work was the first topic of the presentation. The initial discussion was about how software development fits with knowledge work (slide #1) and how such activities can be associated with a huge quantity of variations in scenarios and contexts (slides #3 to #6). Understanding the nature of knowledge work is the key to not get trap in trying to translate manufacturing tools and techniques unappropriately.
Context Matters
Don Reinertsen's quote about best practices and the importance of the right context to consider them as "best" warn us to be carefull when choosing best practices just because thay are supposed to be "the best" (slide #7). Context is relevant, so Kanban allows you to design processes that fit to the context, instead of manipulating the context to fit a specific process (slide #9).
The word "process" generates fear on the agile community. In fact, there is a reason to put this word on the right side of the manifesto. But, there is no reason to think that no process is the goal. Kanban establishes a new balance on the relationship between people and processes, establishing a way to empower people to design their own processes. Hence, Kanban is a collaborative exercise for process design and offers thinking and action tools to empower people to evolve processes by themselves (slide #11). The process is owned by people, which can connect Lean with Agile in a incredible way.
And there is more... Kanban is also a Mindset
So many case studies around the world describe a kind of transformation process emerging once you absorb the "paradigm of flow". A Kanban implementation holds only four essential tools. But there is a whole new mindset out there. The
WipLimitedSociety is agreggating people and content regarding something bigger than the four essential tools. A whole new body of knowledge is emerging right now. The "Yes We Kanban" logo is the symbol of this mindset (slide #13).
It's not so easy to structure this mindset in a way that people can understand. I give my try, anyway. So, my way to describe the Kanban Mindset is by showing patterns, tools and the type of thinking spread by the people who is talking about and applying such ideas. The result was a pyramidal structure like the one that I introduce at slide #14: Thinking Tools, Process Design Patterns, Capability Measurements, Collaboration and Team Model Patterns and A Culture of Continuous Improvement.
Thinking Tools
(#slides 16 a 20)
Thinking tools guide practitioners when they are applying Kanban. System Thinking help coaches and team members to understand why they are doing what they are doing. See your work environment as a system can make you conscious about causality and effects of actions. This type of thinking, despite of being very abstract, is very powerfull. A single intervention can cause a huge influence on the system as whole.
Once System Thinking can be viewed as the starting point, Lean Thinking is the basis. Almost every operational concern is guided by the need to identify value appropriately and make it flows throught the system, improving the process continuously and eliminating waste progressively.
Theory of Constraints is another element on this thinking process. Once you have flow in your process, you are going to start to see bottlenecks that make it slow in certain part of your system. The Theory of Constraints establishes that your system is so strong as its bigger bottleneck. By using knowledge of this theory you can dramatically leverage the throughtput of the system or, at least, you can get understanding about what are the right investments to do in your system to get higher or better results.
Queueing Theory is another key thinking tool in the Kanban mindset. What lies behind knowledge work is the unpredictable nature of arrival times and task durations (slide #19). Queues are always there and the understanding of its behaviour is in the toolbox of every Kanban thinker.
Finally, there is the Real Option theory that has been discussed lately. It establishes the basis for risk analysis by raising the importance of managing choices and defer commitments to generate options.
Process Design Tools and Patterns
The idea that processes can be designed using tools and patterns instead of procedures and documentation forms is mind blowing. In slide #21, I delineate four essential tools and some other patterns for process design using Kanban. This list is just an extract of what I have been listening as solutions to common problems used by practioners and discussed by the community. Here they are:
Essential Tools
Value Stream Mapping
Visual Management
Pull System & Single Piece Flow
Limited WIP
Patterns
Buffers & Queue Limits
Classes of Service
Leveling Work
Two tiered Systems (Expand/Collapse)
Swimlanes/Expediting
Triggers
Priority Filters
Perpetual Multivote
Obviously, this is not the full list of patterns that people are applying to their Kanban implementation. What matters here is the idea that patterns can help a team to solve very specific problems when they are trying to design their processes. You can try to extract the basic meaning of each pattern by looking at the slides #21 to #40. You can also leave a comment on this post if you need more info about one or other.
I just want to leave a few words about the last two (Priority Filters and Perpetual Multivote). They were initially proposed by Corey Ladas as patterns for designing the process of select work to inject into the system. I think the perpetual multivote system can be particularly interesting to select work from a continuous improvement backlog queue.
The description of those can be found here:
Collaboration and Team Model Patterns
(slides #41 to #46)
It's difficult to realize how collaboration patterns emerge on Kanban projects without actually doing Kanban. The first thing to notice is about the ownership of process rules. The best Kanban teams are using all these tools to master the process. They, in fact, own the process usually helped by a coach with a System Thinking or Lean Thinking bias.
What people call "swarming" is the most interesting pattern, in my opinion. Usually happens when people have to look at the process board and decide what to do next. The Kanban limits avoid people from inject more work into the system, so they have to find a way to help pushing the work in progress out. That's the moment when Collaboration patterns start to emerge.
Teamlets, feature teams, and other collaboration structures start to be notice daily.
Capability Measurements
(slides #47 to #53)
I think this quote from John Seddon illustrate why we have to be carefull with measurement in our systems: "Managing with functional measures always causes suboptimization, because parts achieve their ends at the expense of the whole."
Kanban gives to the team the ability to measure capacity and use that measure to bargain or manage its commitments with customers and stakeholders. Capacity can be known using time measurements (lead/cycle time) or volume measurements (throughput). It's common for Kanban teams and coaches to use Cumulative Flow Diagrams to analyze throughput and find bottlenecks and other systemic issues on processes.
A Continuous Improvement Culture
Finally the main goal of a Kanban implementation: establish a Kaizen culture. A culture of continuous evolution of the system. What Kanban team have been reporting so far is the constant appeareance of "kaizen events" as the time goes on. In slide #53, I mention three action tools to establish this culture:
* doing Operations Reviews regularly;
* enabling Continuous Improvement (CI) Actions by reserving capacity in the system to inject CI work items continuously;
* expanding oportunities for improvements removing bottlenecks, eliminating waste and reducing variability.