Cumulative Flow diagrams can contain quite a lot of information for observations. However, they can also be a little daunting for those who are not familiar with them. In this blog post I’ll share with you some tips and information for how to start to use cumulative flow diagrams.
Here’s an example of a CFD:
Each line is a count of the number of tickets moving through that part of the process – stacked on top of one another, hence the name “cumulative”.
- Light Blue – Done items
- Yellow – Deploying
- Grey – Testing
- Orange – Developing
- Dark Blue – Analysing
Along the x-axis are the days – it’s quite common for CFDs to use days as the point of measurement.
Along the y-axis is the count of the tickets. For example, on day 0 there were no tickets in the Done area, whereas on day 1 there were now 3.
That’s actually one key part of being able to read these kinds of graphs. The distance in height between the two lines represents the number of tickets. Thus the larger the gap between the lines, the more tickets that are in that part of the process. Therefore, the further apart the lines the greater the Work in Process (WiP).
If you get lines that are continuing to grow apart, the you have a WiP growth problem and this is going to slow down your overall throughput. This is particularly useful if you use the top and bottom lines when viewing WiP growth because these represent the input and output of your overall system. If you’re not getting growth in you system, but lines within it a growing, it means that there’s likely a bottleneck inside the system.
Additionally, where these lines start to converge, it means you have decreasing WiP and may lead to starvation of a part / all of the system. This might not be a problem in the immediate short term, but left unchecked it may lead to an unnecessary spend / costs.
Using these observations, you can start to adjust WiP limits and control the point of input to either prevent extra work coming into the system / parts of the system, or alternatively allowing more work to flow through. Effectively, this is what managing flow is about – trying to match variations in demand and capability to achieve a balance.
Another key observation about CFDs is that the average lead time is denoted by the width of the graph. For example, if you look at the above graph at the dark blue mark on day 1 – this is when item 11 entered the system. If you track horizontally across the chart, you’ll see that this item left the system (the light blue line) on day 7. To determine the system lead time, you can deduct the entry time from the exit time giving you a lead time of 6 days.
Of course, this time will vary as things change in the system. If you look further up the chart to day 7 and the analysis count there and then track across to done, you’ll notice the lead time is down to approximately 4 days. That’s about a 30% reduction in lead time and can often be attributed to actions such as limiting WiP in the system (as Little’s law tells us that decreasing WiP can also lead to decreased lead time) or other improvements to the system.
The third key attribute of this is the angle of the bottom line of the graph. This is known as the delivery rate or throughput of the Kanban system (as an average). The flatter the angle, the less the throughput. The greater the angle (moving towards vertical), the greater the delivery rate / throughput.
You can see these three key attributes in this chart:
You don’t need to always have electronic tools – if you have physical boards you can maintain a physical chart with this data. Alternatively, you can capture this in a spreadsheet. There are also other tools out there such as SwiftKanban, Kanbanize and LeanKit that do these things for you as well.
You can now start to use cumulative flow diagrams to help make more informed decisions about your system of work. You can see bottlenecks that you can action, you can start to limit or increase input to balance flow and you can limit work through the process to help smooth the flow. You can also start to make plans around how to reduce lead time or increase throughput which will have positive impact to your customers and your financial bottom line.
The cumulative flow diagram is an essential tool for managing flow and improving the outcomes of your service delivery. If you aren’t using one, you now have the basic knowledge to get started.
Lead time scatterplots are an important tool for a team working with Kanban. Sometimes these are referred to as a “Control Chart” which is often the case in manufacturing. However, in knowledge work I think it’s less about the “control” mechanism and more about using it to improve the capability of the term providing the services. Thus I usually just refer to these as “scatterplots” and if you look at the example below you can see why.
There’s quite a bit going on here, so lets look at each part in turn.
X-Axis – This contains a series dates, you can see they progress over about an 8-9 month period moving from left to right chronologically.
Y-Axis – Time in calendar days. This is the amount of time a work item took when it was completed. This is calendar days, so it includes weekends and public holidays.
Orange dots – These represent Standard class of service items. Each time an item is completed, an orange dot is added at the date of completion and the total lead time for the item.
Grey triangles – These represent Fixed date class of service items. Similarly to the orange dots, they represent when an item is completed and the lead time to completion.
Orange dotted horizontal line – This represents the 95th percentile mark for Standard class of service items. That is, 95% of the work items fall under the line and 5% above. This line is optional, plus you can add lines at different percentile’s as per your needs (eg 85%).
Grey dotted horizontal line – This represents the 95th percentile mark for Fixed date class of service items.
You may notice a few things:
- Lead times are not necessarily uniform. This is often the case in knowledge work – thinking everything is exactly the same is a common misconception
- Sometimes there are gaps – there may be holiday periods where there is less work going on. You should understand this as being part of the normal cycle / capability of your team.
- Some items take a large amount of time – Often items that are blocked or have external dependencies cause work items to have their lead time blow out.
- There are much fewer Fixed date items than standard.
- Fixed date items have a much lower lead time
Things to look out for
- Growing lead times – this would tend to indicate an underlying problem in the system that you need to attend to
- Where batches are completed together – there may be some bottleneck in the process preventing things from getting done, or the items might not be independent – look at how you slice for independence.
- In progress items – this only shows you the “Done” items, it doesn’t show you the ageing of currently open items. You can use a separate chart for this – it’s important to action problems early before it’s too late!
You don’t need a whole lot of data for this to get started. All you need is the start date and end date of each of your work items. A few years ago I did a lightnight talk at Agile Australia 2017 that talks about this. If you’re looking for a tool to help you do this, you should check out Troy Magennis’ “Throughput and Cycle Time Calculator” excel sheet in his Focused Objectives repository.
It’s good to understand the basics about how these scatterplots work. I’ve touched on some of the ways they can be used, but there’s more detail to it than that and it requires a few other charts, so I’ll save this for a future blog post.
One word that I continually think of when I think of WiP limits is “Focus”. Essentially, WiP limits create a focus for working on the right things at the right time. The absence of WiP limits means that there is often a lack of focus in the organisation.
Often when teams are doing many of different things, they tend to start lots of work, but tend not to finish anything. It really doesn’t help drive them towards their key goals and purpose. Having WiP limits in place will help focus a team on what’s key to be doing right now.
Sometimes there may be a mix of work types or priorities / classes of service for work. Using WiP limits more explicitly can help you ensure that your efforts are balanced appropriately across the different types. This helps people focus on the different things to the right level and see them through to completion. It can help ensure the right balance of work.
If teams are resistant to the use of explicit WiP limits, I would say something along the lines of “What’s our focus for this week / month” at their daily stand-up / kanban meeting. That invariably leads to a conversation around, “well we don’t have to start this yet, as it’s not our focus” or “this is critical for hitting <key focal point> for the month”. Teams tend to collaborate towards this shared goal and deliberately avoid the “noise” from other activities.
I often hear of / see things in organisations along the lines of “We have 100 people delivering projects, and 120 projects currently underway”. Clearly, in this kind of scenario there is a lack of focus for the organisation. What really needs to occur is to limit the number of projects in progress so you can focus your group efforts on achieving key outcomes.
In this kind of scenario, trying limiting the number of projects to, say, 20-30 and put a policy in place that says, you can only start a new project when an old one is completed. You start to create a bias towards delivery and completion of work to reap benefits sooner.
A Listing of Kanban Related Books
Over time, I’ve accumulated a number of Kanban books, however I don’t think I’ve seen a posting with all of the details of what they are so I thought I’d share my own personal collection and my thoughts about the various books to help people decide what they would like to choose. I probably have left out some really good books – not because they’re aren’t worth mentioning, it’s just because I don’t have a copy of them yet. If you find one that I should have, please contact me.
Essential Kanban Condensed
David Anderson & Andy Carmichael
Level: Beginner
https://www.amazon.com/Essential-Kanban-Condensed-David-Anderson/dp/0984521429
This guide summarises the basics of kanban. It talks about the values, practices and principles. It is quite simple and for anyone looking for a quick introduction to kanban then this is your go-to book. It has a very comprehensive glossary at the back describing many of the elements of Kanban systems.
Kanban – Successful evolutionary change for your technology business
David Anderson
Level: Beginner -> Intermediate
This is really one of the foundation books for Kanban, it will explain the Kanban method with case study information about STATIK (Systems Thinking Approach to Introducing Kanban) and many of the very basics. This is very common amongst kanban practitioners and is often referred to as “the blue book”.
Kanban Maturity Model – Evolving fit-for-purpose organisations
David Anderson & Teodora Bozheva
Level: Intermediate -> Expert
https://www.amazon.com/Kanban-Maturity-Model-Fit-Purpose/dp/0985305150
This book is useful for coaches and change agents looking to use Kanban to help organisations become more fit for purpose. This book comes from a large body of knowledge of applying Kanban in different contexts across the globe. What is interesting here is understanding what current level of maturity a team / organisation is at and then applying appropriate next steps for that context. Essentially, given Kanban’s evolutionary nature you will need to crawl before you walk before you run and this book takes you through the steps in the evolution to prevent you from falling down in the process.
Lessons in Agile Management – On the road to Kanban
David Anderson
Level: Intermediate
This book is a select collection of blog posts that come from Davids early work prior to release “the blue book”. Although this book was published subsequently, they tell the thinking journey that led to the emergence of his later work in Kanban. I found particularly interesting the sections on tribal behaviour and how it relates to the change management of Kanban.
Personal Kanban – Mapping work | Navigating life
Jim Benson & Tonianne DeMaria Barry
Level: Beginner
Personal Kanban is a really powerful tool for organising things in your own personal life. As someone who can attest to attempting to cram too much into life, these simple tips can help you achieve some balance.
Kanban from the Inside
Mike Burrows
Level: Beginner -> Intermediate
This book introduces the concepts of the Kanban values and goes over more detail about STATIK (Systems Thinking Approach to Introducing Kanban)
Making Work Visible – Exposing time theft to optimise work and flow
Dominica DeGrandis
Level: Beginner -> Intermediate
I really like Dominica’s subtitle – “Time theft”. Time is the one thing we can’t reproduce, so it’s highly valuable and Dominica helps us understand “The five thieves of time”. Although some of Dominica’s examples are quite simple with images to follow, she gets into more detail about metrics and feedback mechanisms that will help take your Kanban system to a much deeper level (thus I gave this a Beginner to Intermediate rating)
Kanban for Lawyers
John E. Grant
Level: Beginner
https://leanpub.com/kanbanforlawyers
This book is only partially complete, but I thought I’d include it here because it’s interesting to see others take the concept of Kanban and apply it to different domains. It’s fairly simplistic – written to get lawyers started.
Kanban Change Leadership
Klaus Leopold & Siegfried Kaltenecker
Level: Intermediate -> Expert
I think this book is really suitable for Kanban coaches and consultants out there helping organisations to improve. Although this book does recap on the basic practices of Kanban, its focus on the change and the leadership required around that change to support it is really more advanced. Be ready to tackle issues such as emotional responses to change and creating a learning culture.
Practical Kanban
Klaus Leopold
Level: Beginner -> Intermediate
I really like this book from Klaus. Like so many other Kanban books, it’s written from the experience of the practitioner applying Kanban in a number of situations. The first couple of parts of this are really focused at beginners – learning why kanban and how to use and improve kanban systems. He then gets into more advanced and interesting topics in the sections of Large-scale Kanban, Forecasting and Risk Assessment that are really aimed at the intermediate levels (or perhaps even expert).
Rethinking Agile – why agile teams have nothing to do with business agility
Klaus Leopold
Level: Intermediate
I really like the message in this book – plus the simplicity of the message. The cover really says it all – time to focus on the biggest organisational challenges towards agility, rather than an individual team level. At first the concepts seem simple – particularly so because they are portrayed through illustration as much as words. However, tackling the underlying issues that Klaus talks about at the larger organisational level can be challenging, thus I’ve marked this book at the intermediate level.
The Scrumban [R]Evolution
Ajay Reddy
Level: Intermediate
People have been using Scrumban for some time now, however not many people have given a lot of thought to how Kanban can be overlaid on an existing scrum system of work. Ajay has provided a basic overview of scrum & kanban and then gets into many detailed recommendations as to how to combine the two. I’ve given this an intermediate rating because I think one should attempt to read one of the basic books first to get more detailed understanding of Kanban (eg “the blue book” or “Kanban from the Inside”) – oh and if you haven’t read the scrum guide then you should also do that too.
Stop Starting, Start Finishing!
Arne Roock
Level: Beginner
https://www.amazon.com/Stop-Starting-Start-Finishing-Roock/dp/0985305169
This is a very short (approx 30 pages) book that really sums up the very basics of kanban using few words and some visual aids. If you have a manager or leader who doesn’t understand Kanban yet and you’re trying to get started, hand them this book and check back with them the next day or week and have a follow up conversation.
Real-World Kanban – Do less, accomplish more with Lean Thinking
Mattias Skarin
Level: Beginner
This book describes kanban using real world examples. Throughout the book, you’ll see where things started, what they learned along the way and the improvements they made as a result. This is a relatively easy read with some basic examples – for me I particularly like the sections on “Using Kanban to save a Derailing Project” and “Using Kanban in the Back Office: Outside IT” – I think these two scenarios are more common use cases than what you might think.
Essential Upstream Kanban
Patrick Steyaert
Level: Intermediate
https://www.amazon.com/Essential-Upstream-Kanban-Patrick-Steyaert/dp/098452147X
This book, although relatively small, packs a great deal of information in about how upstream kanban works. Often teams start at the level of the team and don’t deal with how work comes to the team. Upstream kanban looks at how you can balance demand and capacity for a smoother flow overall. It’s probably best that you get to know Kanban basics through one of the beginner level books, as this book builds on a base level of knowledge.
Actionable Agile Metrics for Predictability – An Introduction
Daniel Vacanti
Level: Intermediate
Dan’s book on metrics is the go-to for many a kanban practitioner. He goes into many details about the different types of metrics and introduces a number of concepts such as “flow debt”. I’ve marked this as intermediate as you really do need to have a base understanding of Kanban before you venture into this book.
Related to Kanban
Although these books are not explicitly about Kanban, you’ll find a lot of Kanban related thinking in these.
Fit for Purpose – How modern businesses find, satisfy and keep customers
David Anderson & Alexei Zheglov
Level: Beginner -> Intermediate
This is really related to Kanban because Kanban systems when they become more mature are focusing on fit for purpose services for customers. The book includes simple to understand case study / examples that looks more deeply at the purpose of services and how to produce better outcomes.
A Practical Approach to Large-Scale Agile Development – How HP Transformed LaserJet FutureSmart Firmware
Gary Gruver, Mike Young, Pat Fulghum
Level: Intermediate
I really like this book – although it’s not explicitly taking about Kanban, many of the parts of the story are relatable to Kanban values, principles and practices. It describes the journey of a how multi-site HP team (approx 400 people) chose to transform the way they work for greater responsiveness to market. There is a lot of pragmatic context sensitive advice given – with reasons as to why those choices were made in their context and considerations given.
96 Visualization Examples
Jimmy Janlen
Level: Beginner
https://www.amazon.com/Visualization-Examples-Jimmy-Janl%C3%A9n/dp/9188063011
Although it doesn’t specifically talk about Kanban, many of these visualization examples are useful and relevant for those who are on a Kanban journey. No doubt you will select a number of these to help improve your current system of work. It’s well illustrated with examples that make it easy to understand and get started.
The Principles of Product Development Flow: Second Generation Lean Product Development
Donald Reinertsen
Level: Intermediate -> Expert
Although not explicitly Kanban, there is a lot here that relates to the way Kanban systems work (Donald also wrote the foreward for the “Blue book”). This is a really dense book – so much wonderful information, I’m glad Donald wrote it all down because it’s a lot to keep together in one’s mind. It’s a book you’ll keep coming back to – there’s always another nugget of wisdom buried in there that you’ll find that you can apply to your Kanban implementation.
I’ve recently been thinking about a number of experiences in my career where organisations who have a bias for delivery have uncovered options that were not previously available to them. I’ve also seen others who had a tendency to delay delivery (or at least deployment) to when their customers are “fully ready” for it.
This predominantly happens in organisations that have traditionally had long lead times for delivery. Often the transaction costs for delivery are quite high, but other times it may be that the process and thinking over time has solidified such that the delivery managers don’t consider other options.
Some of the arguments I’ve heard include the following (along with my counter arguments):
“That’s the way we’ve always done it” – That’s a Kodak moment waiting to happen. You can bet you’re bottom dollar that if you’re not looking to improve, then your competitors are. How long do you think that will last?
“It will cost too much” – This is often in the context of the cost of deploying without delivering – there is a run cost to have the hardware / systems there earlier. However, I would counter this by saying the hidden costs you’re not considering are:
- Lifecycle vs Project costs – if you deploy regularly during the project, you can test the deployment automation mechanism and be confident that it works at the push of a button. Delaying this often means costs are pushed into BAU where later releases are still manual and are longer, costlier and riskier
- Opportunity cost – by sticking to long cycle times, you are cutting yourself off to potential other opportunities that you’re not aware of yet
- Transaction costs are high – well, if we don’t do something about it earlier they will always be high. Maybe there are some ways that you can start to reduce these transaction costs that you haven’t thought of – perhaps start here.
- Have you fully considered the overall cost of delay if you get into a “large batch death spiral“? This is quite likely if you stick to this.
“Our users are not ready for it yet” – Perhaps, but have you considered all of your user groups? I’ve seen opportunities where you can do early releases to your staff / operations team often referred to as “Eating your own dog food” (a common practice at Microsoft). This is a great way to reduce overall delivery risk – particularly if you have a large delivery footprint.
What are some of the results we’re likely to see?
Some of what I’ve seen before are a combination of things, the key one is:
New opportunities – This is often not thought of and the value here can be enormous. I’ve seen organisations try to release a new product and it doesn’t go exactly as expected. However, by getting something out earlier, it’s given them a new capability / offering that has allowed for exaptation / transforming into other products or parts of products. By getting something out early they have created a new foundation for future revenue.
Other reasons for taking a bias to delivery include:
- Reduced delivery risk – particularly around timeline. Getting things out early and regularly so at least someone can use it helps validate if you’re really on track (even if it’s not your final target user group).
- Reduced costs – In some instances I’ve seen clients say “This often takes 12 months and can often fail – let’s see if we can get something out in 3 months”. It gets really hard to spend a lot of money in a smaller timespan.
- Stopping – There’s often an OPEX / CAPEX problem if you haven’t actually produced a usable asset. Some organisations, are reluctant to stop the large batches because it will switch spend to date to OPEX from CAPEX which will have deeper ramifications for the organisation and their customers.
- CAPEX depreciation – If you can start depreciating an asset in 3 months rather than 12, there are potential financial benefits to this that you otherwise wouldn’t have
How do we get started?
In a word – Leadership. By this, I mean someone has to have the vision and courage to see what is possible and make a change. This does not necessarily have to be done at the top level – I would encourage all Delivery Managers, Project Managers etc to consider this on their project.
If you’re working in a space and see this happen, try arguing with some of the reasons above and probe to understand why people might not wish to try it. It may just be “too different” to what they’re used to. You may need to break through any fear there in some way – you might want to create a greater fear in maintaining the status quo with the reasons above to create that movement.
Dealing with Resistance to WiP Limits
Sometimes teams will understand the concept of WiP limits and be reasonably open to them, but perhaps their process is still emergent or they don’t yet understand what WiP limits they should put on the parts of their flow.
One possible solution to this scenario is the Constant WiP limit – also known as CONWIP. The idea is that you don’t put the WiP limit on each part of the process, but rather have a WiP limit on the overall flow. See the example below.
This is a basic pull system, but often the underlying process is not well understood or managed, thus it is a lower maturity implementation. You can use this to buy enough slack for you to be able to better understand and elaborate on the underlying system and start to implement some of the deeper kanban practices.
Dealing with Resistance to WiP Limits
Another technique for dealing with resistance to explicit WiP limits is to try limiting WiP per person. This can be useful for a team who is not used to working coherently together yet or might not want to go straight to WiP limits.
This technique has the advantage of being easy to adopt – it can be explained by how it can be beneficial to individuals to stop them getting overburdened with too much work. I often start with a deliberate provocation like “Is it reasonable for someone to work on 1000 things at once?”. To which practically everyone answers “NO!”. The discussion usually continues along the lines of “Well then, why don’t we restrict the number of things someone can work on concurrently to something much lower, say 3 items”.
This can be represented simply on the board by limiting the number of tokens or avatars of each person to, say, 3:
In the example above, there are 3 people working together. Two people are using each of their 3 tokens. One person still has a spare token in the backlog area where they park spare token, enabling them to work on one more item.
This in itself can be difficult for some people. Often, you might get some “hero” types that might like to be the centre of getting everyone out of trouble all the time. However, often these folks are actually the source of many of the problems because they become bottlenecks. You might find challenges with these folks just getting transparency into what they’re doing in the first place, even before you limit WiP.
Assuming you do have a level of trust and transparency, there are a number of drawbacks to this approach. For example, are 3 items actually practical in preventing time wasted context switching? Perhaps / perhaps not – it just depends on the nature of the work and your context.
Also, as you may notice, this limits the work done concurrently by individuals, it doesn’t actually limit the amount of work in the system. You can see the last ticket in the development column isn’t being actively worked on because someone’s token got moved somewhere else. In this case, because systemic WiP is not limited, you’ll notice longer wait and lead times, plus it will make the system less predictable.
If you are having trouble getting a team started with WiP limits, this might help. Ideally, you should try and get to explicit systemic WiP limits, so treat this as an evolutionary step, not an endpoint.
Dealing with Resistance to WiP Limits
This is one of what will become a series of blog posts that discuss and give options on how to deal with resistance to WiP limits.
Having WiP limits for the first time can be confronting for many teams and organisations. For those who have been utilisation or specialisation focused, the concept of flow and WiP limits may take time to get used to. It may involve unlearning what could be years of habit with another process – it’s not something that’s done overnight and it needs continual adjustment, encouragement and monitoring. Until teams have gotten into the discipline of following explicit WiP limits, there may be other ways to help enforce the WiP limits.
The catch-cry of many a Kanban team is “Stop starting, start finishing”. This often sounds simpler than what it means in practice. So, to help out I often suggest to teams that they use the “walk the board” from “right to left” during their daily stand-up / Kanban meeting. What does this mean? Consider this example board for a software team:
Get the team to start the stand up by looking at the right hand side of the board first. We have 2 items in Deployment – if anyone is free, ask if they can help with the deployment activities.
Then move to the next column to the left – Testing. If there are any defects then get any free engineers to focus on fixing the defect. Alternatively, you could have the engineers help testers with automation, data setup or any other activities that could help get the testing done.
Next, move onto development. Are there any free engineers to help with code reviews, build pipelines or any other development activities? If so focus on getting the development done for these tickets.
If there is nothing downstream for an idle engineer, then and only then can they pick up a new card from the To Do column.
Even without explicit WiP limits, you will find that just using this practice will assist your teams in limiting their work in process. By more explicitly focusing on moving the downstream tickets before starting new ones you will have “Stopped starting and started finishing”.
Once the team is used to this habit you can have deeper conversations with the team about what the explicit WiP limits should be.
I’ve seen a number of common patterns over the years in relation to assumptions. Sometimes using assumptions can be useful, you can proceed with an initiative and begin to make progress and check in on points as they are discovered, since we can’t know everything up front. Other times, assumptions can be downright dangerous and many of those times it’s because we haven’t realised that they are assumptions that need to be validated or invalidated. By validating assumptions, we have a solid information on which to base decisions – without such a foundation our initiatives are destined to crumble and fall.
One of the common patterns I’ve seen is the use of a “Business Requirements Document”. This kind of pattern has other manifestations, but essentially it comes at the outset of the imitative and the underlying assumption is that all this work will achieve the outcome. Often there is a lot of complexity in the underlying initiative and it’s too hard to predict exactly what will occur. Indeed, perhaps this is a good general rule – there’s no way to predict with absolute certainty exactly how your customers / users will react to a change. Thus, our path becomes set with a series of assumptions.
I’d rather see the word “Requirements” replaced with assumptions that will need to be validated somewhere along the lifecycle. Which leads me to my next point – the lifecycle or the knowledge discovery steps don’t take into account validating those assumptions in the real world. Often, I see Kanban boards like this:
When really, if the team were to add an additional knowledge discovery step along the lines of the following, the team would be prompted that they’re working with assumptions and they have to think about how they’re going to validate them:
What often results is that people focus on purely “getting stuff done” rather than ensuring “someone’s need was fulfilled” (I like this “Definition of Done” from Mike Burrows) – and by that, I mean we know through validation that the need was actually fulfilled. That’s being fit for your customers purpose. That’s really what we need to be focusing on.
Instead what results is that either we don’t validate that we’ve solved the problem and move on to the next shiny thing, or we have to go back for one or more swings at it. If you’ve got stakeholders that are counting on your promises that you’ll solve their problem the first-time round, then you’ve got a fairly serious stakeholder management issue. Also, what was the opportunity cost of learning this so late? What could we have been doing with the time and money that we’ve spent to invalidate this assumption?
Wouldn’t it be simpler to plan this from the start? In areas of uncertainty and complexity, we really shouldn’t be blind to our assumptions, rather we should be acknowledging we don’t know everything, but we plan to learn as soon as possible. Even if we’re using leading indicators to show we’re heading in the wrong direction this can be better than relying on the assumption to hold.
Don’t be blind to assumptions, they can be useful when they need to be, but often they are not catered for in many systems of work. It’s not a difficult thing to add the validate step to a board, but changing the behaviours to ensure you really are meeting that customer / user need can take more time. If you’re not validating your assumptions, you’re likely falling behind your competitors who are.
Recently, I ran a session of “The ship game” that was created by @klausleopold (read up more about it in my earlier blog from LAST conference). During that session, a couple of the attendees looked to me disbelievingly as they saw lead times halved. The look they gave me was “what kind of trick is this” as if I waved some kind of magic wand and magically sped everything up. The answer in the end was that there was no special magic, just the use of Work in Process limits.
Some teams experience lead times halving, some experience even greater improvements. What this group also found that they also had slack in the system when they introduced WiP limits – they were actually not working as hard and they were achieving better results compared to when they didn’t have WiP limits. To me this really highlights one of the key parts of Kanban is really the WiP limit.
Many people have the misconception that “the Kanban” is just the board. So many times, I’ve heard “we’ve got a board so we’re doing Kanban”. Although a board can be useful, you’re really not getting the full benefits out of Kanban – you really need to start limiting WiP to get the benefits. So much so, that I distinguish between the two – now I refer to “the Kanban” as the slot created by the WiP limit that allows you to pull new work in. I refer to the Board as simply the “Visual Management Board”. I really don’t consider it “Kanban” for knowledge work without the use of WiP limits (see https://www.kanbanmaturitymodel.com/ for more details on different kinds of WiP limit implementations).
The WiP limit is important because it:
- Allows you to see the capacity available
- Creates focus to avoid task switching overheads
- Prevents you from overburdening teams by pushing too much work into the system
- Stabilises the system such that you can get meaningful lead time metrics
- Catalyses change by stressing the system (as opposed to the people in the system)
- Creates slack to allow improvement opportunities to take place
Sometimes it can be hard to introduce this and it certainly may seem counterintuitive when you start, but if you can stick to it, you will get many benefits like those mentioned above. So, please help your team, your customers and ultimately your organisation become more successful by implementing this small change.
If you want to find out more about how to implement a real Kanban system, please check out the upcoming Kanban System Design courses.
I often find the answer to this question misunderstood. Often people see Kanban as just the “board”, but there is a lot more to it than that. When answering the why would someone want to use Kanban, I often point to the Kanban Agendas. The three agendas each answer problems that many organisations experience and they each feed into and support each other to allow a more fit for purpose organisation to emerge.
Sustainability
I often find teams that are struggling with too much work to do. There always seems to be an endless “To-do” list and teams can hardly keep their heads above water with all the incoming demand. Some teams that I’ve started working with are working nights and weekends just to try and get everything done. It’s really not a long-term strategy because it kills morale and people leave – which leads to more strain on those who are left. Using Kanban, you can start to limit the work in your system to allow teams to focus on what’s important. You can also start to shape demand so that you can get control of that monstrous “To-do” list.
Service (Customer) Orientation
Once your team get some space to breathe, often you want to the focus on what’s important to your customers. It’s now time to start to evolve your system to better service their needs. You may have different customers with different needs and trying to service all of the competing needs can be difficult. With Kanban, you can start to modify your system to suit not just one type of customer need but being able to serve multiple concurrently. It can help you deal with the seeming different demand and help solve the varying problems your customers have.
Survivability
Now that your able to keep your team to a sustainable pace and serve your current customers, it’s time to look to the future. What are the changes in the market that are occurring? How do you get ahead of the curve? What strategies are you going to employ to get there and how do you balance that with current customer needs? These kinds of questions are all very important to be able to answer to ensure that in the long term your business not only survives but thrives. Kanban can help here as well, helping to form the new strategy, alignment throughout your organisation and then through execution with the required feedback to make sure you keep on track and adapt to changing conditions.
Getting to this point isn’t an overnight change. You will need to make many small adjustments to the way that you’re working to get to this point. Essentially, this is evolutionary, but you can start now to make things better for your teams, your customers and your organisation.
Another major cause for long lead times are blockers. Blockers are things that prevent the flow of value / work from being done. Often these blockers are caused by things outside the system that we often have little or no control over. As these are a major cause of “tail lead time” issues, you should identify blockers and come up with countermeasures to prevent the key problems from affected your customer delivery.
Some examples of blockers include:
- Waiting for a particular specialist to perform work
- Waiting on another team / group to provide a something such as:
- Waiting on procurement for setting up agreements
- Waiting for security / compliance to provide a review
- Waiting on legal for advice
- Defects / quality issues (although often we separate these out as a specific kind of blocker)
Often times, I see boards that take blockers and place them in a separate column or waiting area. For example:
You should avoid this kind of mechanism for a number of reasons:
- These areas are out of sight / out of mind. They often get forgotten and don’t get solved in a timely manner
- They are (usually) not WiP limited – this will cause unpredictability in your system of work
- They don’t become the focus for improvement
- When they become unblocked, often you forget where in the flow they were up to before they became blocked and it becomes hard to place them back on the board
You should try, instead, to block the ticket in place and record it with a blocker stickie such as the example below:
The blocker stickie should also contain enough information that you can use it for analysis at a later date to combat commonly occurring blockages that are having the largest effect on your lead time or other fitness criteria (I’ll cover blocker clustering in another post). Here’s an example blocker stickie:
Key things to capture:
- The work item that was blocked
- A blocker description (what is blocking the ticket)
- The date the item became blocked
- The date the item became unblocked
Along with this, you should also work with your leadership team to let them know what these mean. Leadership should be on the lookout for blocker stickies and actively engage the team asking questions like “how can I help”, “what can I do to remove this blocker”. Keeping your blocked item in the flow will ensure that eventually your WiP limit will be reached which will force you to deal with the blocker.
Blockers are a commonly occurring event in Kanban systems (particularly new ones) and they should be identified in the right way with the right data. The Kanban system should be set up with feedback loops and policies that force you to deal with the problems that cause blockages to ensure that you maintain a healthy flow. If you don’t deal with blockers in this kind of way, your system of work will continue to be unpredictable and experience much longer lead times than it should.