Limiting WIP? Or Containing the Work?

I’ve thought for some time now that WIP limits are a special form of explicit policy – one that is called out specifically because it is a core concept behind kanban systems. That has made be uncomfortable with the third Kanban Thinking heuristic; “Limit (with Policies)”. Limits and policies are a means to an end. What is that end (other than the over-arching goal of making in impact)? Further, all the other fuller versions of the heuristics are of the form “<verb> the <noun>”.

  • Study the Context
  • Share the Understanding
  • Limit with Policies
  • Sense the Capability
  • Explore the Potential

We define WIP limits and explicit policies in order to create a boundary within which the system can evolve, and which allows self-organisation to happen. Thus they create a container for the system. That leads to the heuristic “Contain the Work”, which covers both WIP limits and explicit policies.

I also like the notion of containing rather that limiting for another more subtle reason. Limiting, to me, implies applying an external pressure in order to reduce WIP. I used to think this was a good thing, but now consider WIP limits to be an economic choice – too little WIP can have a negative impact if it leads to throughput becoming too low, or a portfolio with not enough variety. Containing, on the other hand, implies a different dynamic where we are trying to resist internal pressure in order to avoid WIP getting out of control.

This all might be semantics! I’d love to get feedback on this alternative to talking about limits. What does “contain the work” suggest to you? What other alternatives would you suggest?

Three Kanban Reminders

I seem to have had a number of conversations recently which have all had some common themes. The general pattern has been that someone wants to talk about Kanban and let me know how its not working for them in some way. When I enquire further, and dig into the background some more, I’ve found that there are generally 3 things missing or misunderstood.

  1. You still need discipline. I hear of teams who find traditional agile practices difficult, for various reasons, some which may be valid, and some which may not. They decide to drop those practices, which may or may not be due to a lack of discipline. Dropping those practices, and just keeping the board, does not mean they have a Kanban System. In fact, if the board doesn’t have WIP limits, its not really even a Kanban Board! Whether or not teams have the discipline to follow their original process, they do need to have the discipline to define their own process by creating explicit policies.
  2. You still need cadence. The most common instance of a dropped practice that I hear is that of the time-box. The complaint is then that the team loses their rhythm, and that they have nothing to give them short term focus. They lose their sense of capability. What they have done is gone from a tightly coupled metronomic cadence, to an asynchronous, random and imperceivable cadence. There is a middle ground of a loosely coupled, poly-rhythmic cadence which is more resilient to the nature of their work, yet provides an ability to sense. As described above, it takes discipline to define this cadence.
  3. You still need people. The last misconception is that a Kanban-based approach is removing people from the equation again by trying to simply optimise the current process. Personally, this is why I talk about increasing Potential as one of the impacts we want a Kanban System to have. The potential of a system – its ability to improve over time – is grounded in the human potential of the people who are a fundamental part of the system. Its the people, and their connections and collaborations, who are best placed to know how to change the system for the better now, and be able to continue to change the system as the landscape changes.

I believe that attendees at the recent Kanban Leadership Retreat in San Diego were having similar experiences and I saw on twitter that the phrase “there’s a lot of sh*t out there” was used! This is partly why I came up with the Kanban Thinking model. As I alluded to when I talked about Cargo Cult Kanban, the Kanban community is not copying Toyota’s Kanban implementation tool, but the thinking behind it. If you trying a Kanban-based approach and its not working, think about why, identify something to change, and run an experiment. See, its not really that different to Agile!

 

From Capability to Potential

At Lean Agile Scotland last weekend I was chatting with Gojko Adzic over dinner, and one of the many topics we covered was whether capability was the right word for one of the three impacts I describe as desirable with Kanban Thinking. Earlier this year I described what I meant by capability, but more recently I’ve realised capability is more commonly referenced as a property of the whole system, rather than one specific impact. In other words, if we improve a system’s flow, we have improved the system’s overall capability. Thus I needed to find a new word.

When I referred to capability as an impact, my goal was to ensure as much emphasis was placed on the people who are doing the work, as was on the work itself and its process. This emphasis is what enables a system’s performance to be sustainable over the long term, and even to improve over time. I had been toying with sustainability, but Gojko suggested the word potential and the more I think about it, the more I like it. Potential can be defined as the “possible, as opposed to the actual”, and what is “capable of being or becoming”. This clearly describes that improving a system’s potential is improving the long term future of that system.

Another way of looking at it is the metaphor of a pipe, again inspired by Gojko. If value is what comes out of the pipe, and flow is the progress through the pipe, potential is what can go into the pipe. A system which has a positive impact on potential is one which opens the tap to allow more to be done.

IMG_0031

Then there is also the notion of human potential. Bob Marshall referred to this, and specifically to the waste of human potential, in his Lean Agile Scotland session on Rightshifting, further reinforcing the notion. I also noticed that Matt Wynne has referred to the same waste in his blog post following the conference. This has a nice synergy and helps reinforce the idea that increasing a system’s potential is not about cracking the whip harder. Rather it is about investing in people, unleashing their creativity, and making work fun.

As a result, the latest Kanban Thinking model now looks likes this.

IMG_0032

Portfolio Kanban

I recently wrote an article for GOTO Magazine which has just been published its latest issue.

Given that it is embedded within the magazine, I thought I’d reproduce it here.

Steering the Agile Enterprise with Kanban Thinking

Introduction

Large scale, enterprise organisations consist of many initiatives, programs, projects and development teams. While it is well understood how each individual team can achieve the benefits of agility, it is more difficult for the enterprise as a whole to achieve those same benefits. This article will look at how Kanban Thinking can inform the design of a Portfolio Kanban System, with a view to steering the Agile Enterprise to attain those benefits in order to respond to today’s competitive environments and unpredictable change.

Kanban Thinking

Kanban Thinking is the framework I use when approaching the design of a Kanban System within a given context. The central concept is that the design approach is based on principles of Systems Thinking.

On the right side are the leverage activities for evolving the system design; study, share, limit, sense and learn. Studying the current system helps understanding of the existing context. Sharing that understanding gives everyone knowledge about what is happening. Putting limits in place bounds the system to help stabilise it. Sensing how the system is performing gives an understanding of current capability. Finally, learning from the systems performance allows its capability to be continually improved.

On the right side are the anticipated impacts the system design should have; flow, value and capability. Achieving flow involves a smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste. Delivering value involves focussing on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost. Building capability involves developing people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

 

The Portfolio as a System

As a system, a portfolio is more than the sum of its parts – that is the initiatives, projects, features, teams and people – but is a product of the interactions of those parts with a particular tendency. Managing a portfolio, and as a result steering the enterprise, is the job of designing and guiding the portfolio such that its tendency is to have a positive impact.

First I will describe how the levers can be used to discover a Portfolio Kanban System design, and then show how to understand the impact of that design.

Portfolio Levers

Studying

When studying an existing portfolio, it is useful to begin by identifying all the work that is currently known about, from early ideation, to already in production and being maintained. That work can then be clustered and arranged into themes based on similarity or relatedness. Common patterns which emerge are often based around investment and work item types, hierarchies and their governance workflow.

Examples of investment types might be areas such as architecture, urgent customer requests, current market segments, expanding market segments or future opportunities. Those investment types could be made up of initiatives, which are progressed through the development of features, which are iterated on by breaking down into stories.

Sharing

Sharing a portfolio involves creating a model of the work which everyone can easily access and understand. Visual kanban boards provide a powerful mechanism for achieving this.

The most common approach is to create columns for the various stages of workflow that work items go through. For example, initiatives might begin as options, then have some discovery work done, then be assessed for suitability, then built and released before the results are reviewed for learning.

An important question to ask when designing the mechanism to share the portfolio is what you want to understand in order to learn. The TIP (Token, Inscription, Placement) heuristic is one I find useful to think about how to amplify the important signals, and dampen any noise.

Limiting

Limiting a portfolio is the means by which it can be effectively steered. By limiting the number of initiatives or features being worked on, they can be completed sooner, and with greater predictability, allowing organisations to get earlier feedback and respond better to new information and changing market conditions.

Work can be limited at a number of levels. Investment allocation can help keep the portfolio focussed on the right mix of work.  The number of initiatives and features can be limited to focus on finishing work before new work is started. Flowing work through stable teams can be used to balance demand against the capacity and capability of those teams.

As well as just limiting work in process through a Portfolio Kanban System, another form of limit is explicit policies. Creating transparency of the boundaries of the system design mean that the system can be stable within those constraints and the policies can be evolved to allow the system to evolve. A simple approach to policies is to add a checklist of exit criteria to each stage of the workflow.

Sensing

Sensing the performance of the portfolio is what tells us how well it is being steered, so that direction can be adjusted effectively. There are generally two elements to sensing; establishing a cadence and measuring outcomes.

Establishing a cadence creates a sense of rhythm, and helps lessen the co-ordination cost of getting people together. Setting up a regular meeting to plan and review the portfolio enables a forum for gathering new information and feedback. A Portfolio Council is then able to respond by scheduling and re-prioritizing work in a timely manner and ensure focus is on the most important work.

Establishing appropriate measures generates insights which can aid decision making about what can be done to enable better outcomes.  For a Portfolio Kanban System, financial measure seems to be appropriate. An economic model, which uses high level estimates of the costs and benefits of initiative or features, along with an understanding of the run-rate of teams, allows effective trade-off to be made between portfolio items. A timeline of planned and actual progress, for example, provides the basis for a rolling forecast as an alternative to annual plans.

Learning

Whatever choices you make, the design of your Portfolio Kanban System, and the work within it, it will be wrong! Learning, the detection and correction of those errors, is key to evolving the portfolio to have a greater impact.

Steering a portfolio is about updating the portfolio to match the reality of the current situation, rather than managing the portfolio towards a future situation. By sensing current performance with a regular cadence, work can be advanced, delayed or even killed to keep focus on the most important work.

Evolving a Portfolio Kanban System is about running deliberate experiments, with prediction and validation of how changes to the system design will affect its impact. Again, by sensing current performance with a regular cadence, visualisations, WIP limits and other explicit policies can be adjusted as knowledge is gained about what a better design should be.

Portfolio Impact

Flow

Achieving flow across a Portfolio Kanban System means that the initiatives, programs, projects or features in the system progress with as few delays as possible. As a result the enterprise will be more responsive to the competitive landscape, so that when new information surfaces it can be reacted to effectively. Further, when flow is smooth across a portfolio, the work delivered by the system becomes more reliable as variability of lead times is reduced to within understood ranges.

Value

Delivering value from a Portfolio Kanban System means the initiatives, programs, projects or features in the system are the most important things that could be worked on at that time. As a result stakeholder satisfaction will increase as customers get their needs met. Maintaining stakeholder satisfaction sustainably means that quality will also increase.

Capability

Building capability with a Portfolio Kanban System means that the right initiatives, programs, projects or features can be effectively delivered over the long term, and not just the short term. As a result employee satisfaction will increase, leading to greater retention of people and their knowledge. This long term building of people, teams and their skills will also lead to an increase in overall productivity.

The Value Impact

The impact of value is difficult to quantify, and putting a currency number is not as simple as it is with cost. The challenge is even greater for organisations which are not selling products, such as governments or charities. However, there are a number of approaches which can be used to help understand the value that is being delivered such that we can maximise across the whole system. Some of these I have already covered when I wrote about the science of kanban from an economic point of view, but it is worth including them again.

Customer Delight

Steve Denning suggests that ultimately value is in delighting customers. I agree with this, using a broad definition of customer which is not limited to the end user, but can be anyone with an interest in the outcome. That could include people interested in the user experience, architecture or operational aspects, for example. Having said that, the end user is generally the customer who ultimately determines success.

Value Horizons

In his recent book Escape Velocity, Geoffrey Moore draws heavily on the The Horizons Model developed at McKinsey and published in The Alchemy of Growth. Using this model, Horizon 1 features are intended to have an immediate impact in the current financial year. Horizon 2 features are considered to be investments which are intended to have an impact in the medium term, probably the next financial year. Horizon 3 features are options which have the potential to have an impact in the long term, and not until subsequent financial years. It is very easy to be drawn into focussing on Horizon 1 features due to the anticipated immediate return. However, when that wave peaks and crashes, it is important to be ready for the next wave. Therefore, explicitly spreading the allocation of investment in features across the horizons can mitigate this short term thinking and lead to longer term success.
IMG_0019

Life Cycle Profits

Looking at value over the longer term is a form of considering total life cycle profits. Investing in Horizon 2 and Horizon 3 features is a way of looking at overall life cycle of a product, and of prolonging the profit period.
IMG_0020

Revenue and Expenditure

Another way of looking at value is something I picked up off Chris Matts. He suggests that there are 4 types of value based on revenue and expenditure. The first is in increasing revenue, for example by adding functionality which attract more customers. The second is in protecting revenue, for example by adding functionality which keeps existing customers. The third is in reducing expenditure, for example by adding functionality which improves development efficiencies. Finally, the fourth is in avoiding expenditure, for example by adding functionality which is required to avoid regulatory fines.

Competitive Landscape

The perspective of the competitive landscape is also a way of classifying features, this time as either MVP (Minimal Viable Product), neutralising, differentiating or optimising. MVP features are those which have to be completed to even enter the market. Neutralising features are those which attack a competitors dominance by eliminating any advantage they have with unique capability.  Differentiating features are those which create market dominance by providing new unique capability which the market demands and no competitor can provide. Finally, optimising features are those which don’t add any new capability, but improve the performance if existing functionality in some way. While MVP features are clearly essential, only working on those can be a high risk strategy, and a portfolio of features which includes a mix of all four types can be lower risk.

Cost of Delay

The value of a feature is often dependant on when it is delivered. Using cost of delay as a model can help understand when to schedule features in order to maximise value. Four common patterns are Expedite, Standard, Fixed Date and Intangible. Expedited features are ones where the cost of delay is high and immediate. These items are genuinely urgent and should be scheduled immediately. Standard features are ones where the cost of delay rises linearly. Examples are items with an opportunity cost, where the later the delivery, the more opportunity for gain is lost. Fixed Date features are ones where the cost of delay rises sharply at a specific date. Examples are regulatory dates at which fines may be imposed, or seasonal dates such as Christmas or trade-shows. Delivering these features early creates little or no extra value. Intangible features are ones where the cost of delay is likely to happen in future, but the exact nature is unpredictable. Examples are technical debt or infrastructure work.

Scheduling

Cost of Delay helps with making effective scheduling decisions by prioritising features against each other. Don Reinertsen describes a number of algorithms in his book Principles of Product Development Flow. Principles F15, F16, and F17, can be summarised as follows. When two features have an equivalent cost of delay, schedule the shortest one first. When two features require equivalent time, schedule the one with the highest cost of delay first. When two features require different times and have different costs of delay, then schedule the one with the weighted shortest time first, where the weighting is calculated by dividing the cost of delay by the time. Dean Leffingwell has a great blog post about prioritising features describing this in more detail.

Feature Injection

Having these models is all very well, but how do we know what to actually build? Feature Injection can provide some guidance. With Feature Injection, we start with a vision, decide what goals meet that vision, what capabilities enable those goals, what features deliver those capabilities, what scenarios exemplify those features and finally, what stories make up those scenarios. Thus by starting with the vision, the details can be ‘injected’ just-in-time, incrementing and iterating based on feedback. Liz Keogh describes this well in a recent blog post about BDD in the large.

Experimentation

Feature Injection is designed to deal with the fact that even when we have some idea of the capabilities we want to create, we still have little idea about the precise functionality to build. In these cases experimentation is important. Lean Startup, with its Build, Measure, Learn cycle is a great means of achieving this. It is also a good example of running safe-to-fail probes within the probe-sense-respond approach the Cynefin recommends in the complex domain. I’m also curious about how the software community can apply set-based design ideas such as trade-off curves to better learn and create knowledge about what to build. When running these sorts of experiments, the value is more in the information generated, and the learning experienced, than in any financial return or saving.

And More

There are many more ideas which can be used to help us understand value. These are the ones I use most. For example, I know Tom Gilb has done a lot of thinking on the subject, which I have yet to explore. Eli Goldratt’s work with theory of constraints is another area of potential, which Bob Marshall explored recently in a post asking what is value.

What else is missing? Let me know in the comments.

The Kanban Thinking Picture

I’ve recently settled on a visual representation of Kanban Thinking which has been working well. The structure took shape when I realised that Flow, Value and Capability were system impacts. Those are the arrows coming out of the right hand side of the central System. The arrows going into the left hand side are the levers we have to influence the system behaviour; Study, Share, Limit, Sense and Learn. The primary lever is limiting. Studying and sharing provide the transparency and visibility to enable the limits. Sensing and learning give the feedback to evolve the limits.

IMG_0008

Feel free to use this picture. I hope it proves useful.

What is Capability?

I recently gave talk at the London Scrum User Group (LSUG) describing Kanban Thinking and had a very interesting conversation about what I mean by the impact on capability. I realised I needed to think it through in a bit more detail, and this is an attempt to articulate it better.

Defining Capability

In his book Rethink: A Business Manifesto for Cutting Costs and Boosting Innovation, Ric Merrifield used the term capability to define the outcomes which drive business performance. One of the dictionary.com definitions is that a capability is a quality, ability or feature which can be used or developed. Additionally, to be capable of something is to be predisposed to, or inclined to, which ties in with the idea that complex systems have disposition. Putting all these together, we can say that a systems capability is its degree of disposition, which can be used and developed, towards create a business outcome.

Doing the Right Thing and Doing the Thing Right

We can think of capability in two ways – that of the business, and that of the people. The business’s capability is its ability to do the right thing, while its people’s capability is their ability to do the thing right. This can be visualised in a 2×2 matrix, where ideally we want to be in the top right quadrant where we are aligning business capability with human capability.

Capability

Developing Capability

When I first described Kanban Thinking, I said that “to build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems”. Capability is more than just how good the flow of value is. It is also how well the flow and value can be sustained and improved over time. Simply swapping in and out different people to an existing process (flow) with existing requirements (value) will not work. Businesses are social and cognitive systems where people have tacit knowledge, and they share and use that tacit knowledge to deliver the work. That is why teams are such as core part of making an agile approach work.

Capability Teams

Feature teams are a great example of how to build capability, collaborating to delivering customer value directly. A more debatable approach, however, is the use of component teams, and the idea of capability can provide guidance on when this may be appropriate.  Where a component or architectural layer provides some direct impact on organisational capability, then it may be worth having its own team. The decision on team structure becomes one of whether the team is a Capability Team. Taking a cue from “Rethink”, a Capability Team as one whose outcomes have a resultant improvement on the business performance, as opposed to one whose activities are needed to achieve a business outcome.

An Example

A financial services organisation had a team dedicated to developing an SOA capability which would be used by a variety customer facing applications to access a common data repository. The ability to effectively manage customer data was a key capability for the organisation, and development of the data repository was a business outcome which enabled a better customer experience by providing cross-application consistency. The same organisation also had a QA team. This is not a capability because on its own it does not deliver a business outcome. Rather, it is an skill or activity required to deliver quality, and which should be built into the work performed by capability teams delivering business outcomes.

Even with the notion of Capability Teams, its not necessarily a simple black or white decision, hence the interesting conversation at LSUG. When unsure about what team structure to go with, I think the more interesting question is “how will I know if the structure is having a positive impact?” As I mentioned at the end of the post on Impact, Outcome and Output, I believe Geoffrey Moore’s hierarchy of powers offers some insights here, which I hope to expand on in a future post.  I’d also be interested in hearing of any other interesting examples of Capability Teams. Please leave a comment if you have one!

Impact, Outcome and Output

As I alluded to in the previous post, one of the changes in thinking, and in particular language, for me recently is the idea of impact. Specifically that impact is different from outcome which is itself different from output. I’ve differentiated outcome from output for some time, as have others, but I believe impact is a further step in understanding how we approach change.

To relate the three ideas to each other, I would say that:

Outputs create outcomes which have impact.

This mapping also ties in nicely to Simon Sinek’s Golden Circle model that I have referenced before.

Outputs (or sometimes activities) are the things that we do in order to achieve something. They provide the details about what gets done, such as specific practices or implementation details. In the Golden Circle, they are the WHAT.

Outcomes are the future state we hope to achieve by completing the outputs. They provide the details about what goals we hope to achieve, such as end results or behaviours. In the Golden Circle, they are the HOW.

Impacts are the tendencies or dispositions of an outcome. They give an indication of whether the future state is a positive or negative one, without limiting the scope of what that future state might be.  In the Golden Circle, they are the WHY.

As Simon Sinek recommends with the Golden Circle, we should always Start with Why, and thus when implementing any process or product it is useful to know what impact we want to have. I have realised that the notions of Flow, Value and Capability that I refer to as part of Kanban Thinking are actually the primary impacts that I hope that a Kanban System will achieve.

  • A positive impact on flow might be one which results in earlier and smoother delivery and might be seen in a reduction in lead time or variability.
  • A positive impact in value might be one which results in a better return on investment or improved margins and might be seen in improved economic outcomes
  • A positive impact in capability might be one which results in better business performance and might be seen in improved quality, throughput, or customer and employee satisfaction.

Another recent and related influence has been Geoffrey Moore’s Escape Velocity, where he talks about a hierarchy of powers.

  • Category Power relates to the relative demand for a class of product.
  • Company Power relates to the organisation’s relative position within a category.
  • Market Power relates to the relative company power within a specific market segment.
  • Offer Power relates to the relative demand for a specific product.
  • Execution Power relates to the relative ability to outperform competition.

This has got me thinking about how impact might be the effect a change has on one or more of these powers. While flow is more aligned with execution power, value and capability are aligned to the other powers.

Thoughts on Kanban Thinking

Some thoughts on what I have been referring to as Kanban Thinking

Why create an other brand?

I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe the context and the solution.

Why another “Kanban” brand?

By using the name Kanban, I am acknowledging the roots of my current approach in hearing David Anderson talk about Kanban at Agile2007 in Washington DC. I consider that to be as important a turning point in my career as when I first read about Extreme Programming in 1999. Further, my response to calls to provide a single, clearer definition of Kanban for software development, is to encourage more definitions of Kanban. The more definitions there are, the less dogma there will be, and the more people will have to think for themselves about what Kanban means to them.

Why the “Thinking”?

As I mentioned when I blogged about Agile Thinking at the start of the year, thinking should be a core part of what we do. Alongside Lean Thinking, A3 Thinking, Systems Thinking, Complexity Complexity Thinking and Design Thinking, I want to make this explicit. Emphasising the thinking is also intended to make it clear that action is also required to succeed. Kanban Thinking is not a silver bullet as the right action is needed for each context.

What is Kanban Thinking?

Kanban Thinking is systemic. It takes a mindset of optimising the whole system, whatever the boundaries of that system are defined to be. Part of the thinking is deciding what those boundaries are. They do not naturally exist but are created by us to help frame a context.

Kanban Thinking strives to achieve flow, deliver value and build capability.

  • To achieve flow is to have smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste.
  • To deliver value is to focus on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost.
  • To build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

Kanban Thinking involves studying, sharing, limiting, sensing and learning.

  • Studying the current system helps understanding of the existing context.
  • Sharing the understanding gives everyone knowledge about what is happening.
  • Putting limits in place bounds the system to help stabilise it.
  • Sensing how the system is performing gives an understanding of current capability.
  • Learning from the systems performance allows for capability to be continually improved.