Tuesday, December 21, 2010

Kanban and the DoI

In 2004 I was involved with a group of recognized professionals in the field of project management who came together to define what agile project management ought to mean. The outcome of those meetings was a statements of values, published in February 2005, given the name Declaration of Interdependence. While I’m not in love with the name and find it rather pompous, I find the content of the Declaration has stood the test of time over 6 years. While the declaration sought to define a value system by which modern 21st Century project managers should live, it’s secondary purpose to galvanize a community around general application of agile project management failed to materialize. Five years on, it is worth reflecting on my contribution to the DoI and how it aligns with the Kanban work that I am best known for since then.

Declaration of Interdependence

We are a community of project leaders that are highly successful at delivering results. To achieve these results:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

[©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.]

We increase return on investment by making continuous flow of value our focus

As many of my readers are aware kanban systems limit work-in-progress and signal new work to start only when there is capacity to process it. This “pull” mechanism is used to improve the flow of work. So kanban systems are focused on flow. However, the way kanban systems have developed for software development goes well beyond a typical manufacturing implementation, as Don Reinertsen pointed out to me during a visit to my office in 2007. In the Kanban method we use classes of service linked to (opportunity) cost of delay and explicit visualization of handling policies to improve the return on investment made in operating the software development activity. By visualizing the workflow, limiting WIP, managing flow, measuring lead times, and optimizing risk and value delivery with classes of service based on the economics of delay, Kanban explicitly delivers on the first statement of the DoI. It is no surprise that it is this first of the six statements that are so heavily associated with my contribution.

We deliver reliable results by engaging customers in frequent interactions and shared ownership.

Kanban engages customers through visualization, through interaction and escalation when items are blocked, through the regular cadence and collaboration of input queue replenishment meetings and through the regular cadence of delivery and the planning of each delivery. Kanban asks customers to take shared ownership of the system and its effectiveness and to throttle their demand to the rate at which the system can deliver.

We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

Kanban embraces uncertainty and it manages for it through provision of classes of service such as “Expedite.” This demonstrates anticipation of demand. It also manages for it through use of quantitative measurement such as statistical process control and definition of target lead times based on statistical observation of capability. This again shows how the system can anticipate an outcome and manage for variability and uncertainty. Kanban is also design to encourage adaptation by using the WIP limit and the social interaction of standup meetings and operations reviews to reflect upon performance, observed capability and effectiveness and allow for process improvements to be suggested based on a scientific approach that uses models of process flow, variation, uncertainty and complexity to facilitate implementation of successful adaptations. Kanban is specifically design to anticipate and adapt as the method is designed using concepts of both Systems Thinking and Complex Adaptive Systems.

However, depending on how you define “iterations”, Kanban implementations often do not use them! Time-boxed increments (often referred to as “iterations” by agile practitioners) are replaced with cadence. The core activities of accepting new work and delivering finished work are usually still performed regularly but each activity has its own cadence. For example, input queue replenishment may happen once per week - a cadence of weekly - while delivery may happen every second week - a cadence of bi-weekly. Cadence is a more sophisticated tool than time-boxed iterations.

“Iteration” meaning “to rework or refine” is supported by Kanban.  However, it is still relatively unusual to see such implementations. If for example, a team follows an explicitly iterative method such as Barry Boehm’s Spiral Model, then it would be possible to wrap a kanban system over that and to limit WIP at each step on each loop of the spiral. There have even been instances of team’s visualizing such a process with a board that resembles a dart board or archery target rather than the familiar columns and rows typically associated with Kanban.

We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.

Kanban is specifically designed to enhance the power of the people within the system. By limiting WIP, kanban systems both create slack to allow creativity and innovation room to sprout and flourish, and the act of making process policies explicit provides protection for those working within the system, limiting abuses and attempts to exploit individuals and work around limitations. The explicit policies, often visualized on a board, enable individual team members to make high quality decisions about the economics, risks and intangible expectations of all stakeholders. As a result Kanban enables individuals to be creative about their process, to innovate and adapt to improve customer service and value delivery. It gives them the empowerment to make their own decisions and to optimize the economic outcome to the benefit of customers, business owners, value-stream partners and team members.

We boost performance through group accountability for results and shared responsibility for team effectiveness.

Kanban uses a monthly operations review meeting that involves all team members across an organization, plus senior management, and up- and down-stream stakeholders. At operations review quantitative, objective, statistical data on the performance and capability of the system is reviewed openly by all involved and design changes to the system are proposed and assigned to managers for implementation. Through this operations review process Kanban insures that performance is boosted continuously through the wider group of stakeholders taking shared responsibility for the effectiveness of the system and the team of people operating it.

We improve effectiveness and reliability through situationally specific strategies, processes and practices.

The first emergent property of Kanban is that each process is uniquely tailored to its context. For each system, the value creation network will be different; the risk profile will be different; the team and its skills and capabilities will be different; the nature of demand will be different; and the cost of delay in work items will be different. Every context deserves a uniquely tailored process in order to optimize the economic outcome for all stakeholders. The foundational Principles of the Kanban Method are based on the premise that process definition starts with whatever is happening now and evolves it incrementally through a process of small changes each justified economically and based on a scientific approach to improving performance. Situationally specific strategies, process and practices are core to the Kanban Method.

Conclusions

Not only is it easy to see how the Kanban Method relates to the Declaration of Interdependence and to see how my emerging “agile” work at the time was aligned with it, we could go further and say that Kanban is in fact a full implementation of the Declaration of Interdepedence. It is a manifestation of how 21st Century Project Managers ought to be working. The irony of this may be that Kanban encourages a service-delivery rather than a project-centric approach to work.

Meanwhile, for me personally, I look back on the Declaration of Interdependence as a piece of work that I and the other authors can rightly be proud of, 6 years on. I am also happy that this review of the Kanban Method and how my work evolved in those 6 years shows a high level of consistency and that Kanban demonstrates that it lives the values defined in the Declaration.

I’ve been guilty of not publicizing the Declaration of Interdependence enough. I’m not the only author who fails to make enough use out of it. It rightly is something to be proud of and it deserves a higher profile within the Agile and Lean/Kanban communities.

Friday, December 10, 2010

The Principles of the Kanban Method

As time goes by, I learn a lot about articulating my ideas. I’ve recently updated how I communicate the core principles of the Kanban Method and I first shared them via Twitter Core Principles of the Kanban Method.

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 5 core properties that I’d observed to be present in each successful implementation of Kanban. These have become know as the Principles of Kanban - a term I first saw coined by Scott Ambler in his book review.

This new guidance expands on the 5 core properties to incorporate some of the guidance from Chapter 15 of my book where I discuss how to undertake a change initiative using the Kanban Method. So the principles now include 8 elements.

First adopt the foundational principles ...

Start with what you do now
Agree to pursue incremental, evolutionary change
Respect the current process, roles, responsibilities & titles

Then (use the 5 Core Properties) ...

1. Visualize the workflow
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively (using models & the scientific method)

Let’s examine these elements one-by-one

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.

Agree to pursue incremental, 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 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.

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 in order 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.

Visualize the Workflow
Luckily in my book, I chose not to use the Lean term Value Stream. It seems this term carries with it a metaphor that some have objected to in software development. There has been an argument that Value Creation Network is a more appropriate term. Janice Linden-Reed and I in our DZone RefCard used this term. I’ve come to realize, however, that it only adds to the confusion and the complexity. The Value Creation Network is really the interactions of all the people involved in creating software or solving IT Operations problems, whereas, what I am interested in with the Kanban Method is actually the information arrival process related to the work itself.

So typically, we are looking for state changes in the work, that generally reflect changes in the activity used to generate new information about that work, for example, analysis (an activity) generates information, and when it reaches a point of diminishing returns, we tend to refer to the work as “analyzed” and change to a different activity to generate further information such as design or test development. It is this process of punctuated information arrival that we seek to model when I ask us to Visualize the Workflow.

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. 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 state 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 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 Process Policies Explicit
Until the mechanism of software development or IT operations process is 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.

Improve Collaboratively (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 which 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 make a prediction about the affect 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 Adaptive Systems
The Principles of the Kanban Method are designed to lay the foundation for an organization that can improve incrementally by setting out the conditions that will stimulate improvement. The improvements are emergent behavior. The outcome cannot be predicted. All that can reasonably be predicted is that things will change. As such the Kanban Method represents a Complex Adaptive Systems approach to leading change in organizations. Complex Adaptive Systems use simple rules and seed conditions to stimulate emergent behavior. The simple rules are embedded in the 5 Core Properties and the seed conditions are represented in the first principles of starting with the current process, gaining agreement to pursue incremental improvement and respecting current work practices, roles, responsibilities and job titles. What will happen next is emergent change. Beyond that we cannot predict. The system must be monitored and adapted. The simple rules being used such as WIP limits and workflow visualization must be tweaked and changed to steer the emergent behavior to produce a desirable outcome.

The System Designer Role
This ability to steer the simple rules of the system and to make changes to the process implementation to produce a desired outcome, as opposed to an undesired one, is a skill. That skill is unlikely to reside in every member of a team. More likely someone takes on the role of system designer, or facilitator of the system design. This person may be a manager, a process engineer, or an external coach. The system designer must facilitate the implementation of the Kanban initiative and the design of the kanban system. The system design must change as the complex adaptive system adapts over time in response to the emergent behavior and the outcomes it is producing.