Revisiting the Principles and General Practices of the Kanban Method
Going back to my blog post in December 2010 I articulated the core principles of the Kanban Method which still hold true today.
The Kanban Method defines my approach to incremental, evolutionary change for technology development/operations organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to improve the system. One example of such a pull system, is a kanban system, and it is after this popular form of WIP limited pull system that the method is named.
In my book, Kanban – Successful Evolutionary Change for your Technology Business, I identified what I called the “5 core properties” that I’d observed to be present in each successful implementation of Kanban.
Since the book was published, we’ve expanded this list and they are now known as the Principles and General Practices of Kanban.
Principles of the Kanban Method
- Change Management Principles
These Change Management Principles are common to all Kanban implementations:
- Start with what you do now
- Agree to pursue improvement through evolutionary change
- Encourage acts of leadership at all levels
Kanban is not a big bang transformation going from a current state to some future state. We know from history that those rarely work. Instead, Kanban uses an evolutionary change approach, building on the way of working already in place, seeking to improve it using many forms of feedback and collaboration. The Kanban Method engenders evolutionary change through insights gained by the people working with the Kanban board and taking acts of leadership to continuously improve their way of working. These acts of leadership may not be what is thought of as traditional leadership. They may be small observations and suggestions for improvement by individuals without organizational leadership roles.
Start with what you do now
The Kanban Method does not ask you to change your process. It is based on the concept that you evolve your current process. There is no sweeping, engineered change to a new process definition or style of working. There is no such thing as the Kanban Software Development Process or the Kanban Project Management Method.
Respect the current process, roles, responsibilities and job titles
It is likely that, what the organization currently does, has some elements that work acceptably and are worth preserving. We must also seek to drive out fear to facilitate future change. By agreeing to respect current roles, responsibilities, and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities, and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
Agree to pursue improvement through evolutionary change
The organization (or team) must agree that their current circumstances warrant a gentle, evolutionary approach to improvement. Perhaps a sweeping engineered change has recently failed due to resistance from team members, or perhaps the politics of the organization make it too risky for managers to propose and implement sweeping changes? Without an agreement that a slow, gentle, evolutionary, incremental approach is the right way forward then there won’t be the right environment or management support for a Kanban initiative.
Encourage acts of leadership at all levels
Without leadership to catalyze change things will not improve. Information about where improvements are possible can appear at any level in an organization and most often at the individual contributor level. If changes are to be made quickly and effectively individuals who believe improvement is possible must feel empowered to enact it. A culture of safety must exist, to take action without fear of retribution providing changes can be defended based on logical explanation using models and data.
- Service Delivery Principles
Kanban encourages you to take a service-oriented approach to understand your organization and how work flows through it. This service-oriented organizational paradigm is based on the idea that your organization is an organic entity consisting of a network of services, each of them living and breathing, and evolving. Customer requests flow through this network of services. If we are to improve service delivery, improvements should be guided by a set of principles. These principles may not be utilized early on by organizations as they may not have developed or evolved a service-oriented or customer service mindset as part of their culture.
The service-oriented principles are:
- Understand and focus on customer needs and expectations
- Manage the work; let people self-organize around it
- Regularly review the network of services and its policies in order to improve outcomes
Understand and focus on customer needs and expectations
The customers are at the heart of our process. They bring requests, which we fulfill through the set of service delivery activities until the service or products are considered as completed and satisfying customer needs.
Hence, it is important to not lose the track of the customer requirements for our service and keep communication and open dialogue. Delivery teams but also discovery teams shouldn’t be just order takers. They need to look proactively for understanding the customer’s purpose and satisfying it.
Manage the work; let people self-organize around it
It may be sometimes just a change of wording used, but it is important to focus in work and discussion on the process itself and not on the people doing it. E.g., when a defect was detected, you do not look for an individual to blame. Rather you ask the questions:
- Why did it happen?
- What did really happen?
- What was the impact?
- What can we do to avoid it in a future?
Although Kanban may seem very dehumanized by focusing on the process and not people, this principle makes it even more human-centric: in Kanban, we give people space by removing the burden of constant focus on their actions, sometimes the burden of micromanagement and finger-pointing.
Self-organization requires some level of taking initiative or even acts of leadership and in that sense, it is very closely related to the Change Management Principle: Encourage acts of leadership at all levels.
Regularly review the network of services and its policies in order to improve outcomes
We are not isolated islands. In most of the cases we work with other people, and we are dependent on them – or they are dependent on us. There is a network (a web) of correlations between different services, which can be managed by establishing feedback mechanisms in the form of regular cadences.
This network of services in your organization requires regular review altogether with accompanying policies to make sure they reflect reality.
General Practices of the Kanban Method
1. Visualize (the work, workflow and business risks)
2. Limit WIP
3. Manage Flow
4. Make Policies Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally (using models & the scientific method)
Visualize (the work, the workflow, and the business risks)
As a general rule, seek to make that which is invisible, visible. Once invisible work, workflows, and business risks can be seen, it is possible to manage them better and to do so collaboratively and with consensus. Understand how to define and capture requests for work. Visualize each request with a card on a kanban board. Visualize the sequence of knowledge discovery activities performed from when the request is first received until it is completed and ready for delivery to the customer. We call this sequence of knowledge discovery activities, the workflow. Capture significant business risks associated with a piece of work such as cost of delay, the importance of the requesting customer, confidence in the definition of the requirements, the likelihood of requirements changing or the request being obviated before it is delivered, and visualize those perhaps using color of the tickets, or decorators on the ticket such as shapes, tags or icons.
Limit WIP
Limiting WIP implies that we implement a pull system on part or all of the workflow. The pull system can be a kanban system, a CONWIP system, a DBR system, or some other variant. Specifically with Kanban we are typically using a kanban system, though other pull systems do appear in some real-world examples. The choice of pull system isn’t important, the critical elements are that work-in-progress at each state in the workflow is limited and that new work in “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.
Manage Flow
The flow of work items through each stage in the workflow should be monitored and reported – often referred to as Measuring Flow. By flow we mean movement. We are interested in the speed of movement and the smoothness of that movement. Ideally, we want a fast, smooth flow. Fast smooth flow means our system is both creating value quickly, which is minimizing risk and avoiding (opportunity) cost of delay, and is also doing so in a predictable fashion.
Make Policies Explicit
Until the rules for how we perform a creative knowledge work activity such as software development or IT services are made explicit, it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.
Implement Feedback Loops
An evolutionary process cannot work without feedback loops. When implemented at a service delivery level in organizations, Kanban, uses four specific practices for feedback: the stand-up meeting; the service delivery review; the operations review; and the risk review. The purpose of feedback loops is to be able to compare expected outcomes with actual outcomes and make adjustments. Specifically, we want to make process and policy adjustments as a result of the feedback and understanding the current outcomes in comparison with our expectations or desires.
Improve Collaboratively, Evolve Experimentally (using models/scientific method)
It is the WIP limit that ultimately stimulates conversations about process problems. Things which impede flow or introduce perturbations that mean flow is inconsistent or ragged, often result in a challenge to the WIP limit. The team has the option to break the limit, ignore the problem and carry on, or to face up to the issue, discuss it and suggest a change.
When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions that can be agreed by consensus. In my book, I suggested three models which are useful: The Theory of Constraints (the study of bottlenecks); The Theory of Profound Knowledge (a study of variation and how it affects processes); and the Lean Economic Model (based on the concepts of “waste” (or muda, muri and mura)). Other models are possible such as Real Option Theory.
The use of models allows a team to predict the effect of a change (or intervention). After the change is implemented the outcome can be observed by measuring the flow and examining the data. The outcome can be compared to the prediction expected from the model and the change can be assessed as an improvement, or not. This process of evaluating an empirical observation with a model, suggesting an intervention and predicting the outcome based on the model, then observing what really happens and comparing with the prediction, is use of the scientific method in its fundamental sense. This scientific approach is I believe, more likely to lead to learning at both the individual and organizational level. Hence the use of the scientific approach in Kanban will lead directly to the emergence of learning organizations.
Complex Environments and Adaptive Capability
The principles and general practices of the Kanban Method are designed to lay the foundation for an adaptive capability with an organization. Adaptive capability is how organizations cope with and respond to complex environments. Adaptive capability is required for resilience in complex environments. The improvements to workflow processes represent emergent behavior. The outcome cannot be predicted far in advance or several steps in advance. The future processes of the organization emerge rather than being designed.
