Escalations, whilst seemingly useful for creating a timely response, are actually a sign that there may be some underlying problem with the system of work. This can lead to a reinforcing loop of behaviour that will continually create longer wait times for your customers. You might not notice this at first, but some organisations get into a position where you have to escalate just to get anything done.
Escalations occur where teams run into issues and they need to bring it to the attention of various levels of management to get something done. There may be an urgent need that the service providing group in your organisation is not aware of or not aligned to.
Lets take an example where a team are running at their current capacity, as per normal, and a new request comes along. Although it may be more urgent, this team is already at it’s WiP limit and can’t take on anything more. They may not have different classes of service, or if they do, often these class of service items have already reached their WiP limit. An escalation occurs from the new requester. The team are asked to ignore their WiP limit “just this once” and fast track this item.
The result of this is that the team now have more WiP in their system. The lead times for every other work item are going to start to increase as the team fast track the escalated item. Lead times are getting longer and other teams waiting on work start to see their service level expectations slide past. So what do they do – they escalate. Now there are multiple escalations going on for the one team. Hopefully, sanity might prevail, but in many cases, this often leads to context switching by the team as they now try to service the other requests.
All of a sudden the team are now starting to struggle with all of the escalations and new requests. So, in an effort to try and get things under control, their manager attempts to reduce requests coming into the system. However, requesting groups also have obligations to meet, so guess what, they escalate.
What’s happening here is a self re-enforcing loop that see’s the level of service spiral out of control. Here’s a small diagram depicting what’s going on:
Urgent work, if handled correctly with WiP limits and classes of services can be manageable. When you get escalations for urgent work which ignore WiP constraints, you will likely fall into this kind of problem.
This is one of the things I learned from my Okaloa Flowlab training – if you’ve ever played the game you’ll get these kinds of insights and more (it’s a great experience). I’ll be including it in my upcoming Kanban System Design courses for those who want to experience it.
Try and break the loop by changing expectations to avoid further escalations, preventing urgent work coming into the system, or re-examining your capacity and policies around urgent work. They may also be hiding a larger problem in the organisation – around KPIs or lack of alignment more generally. Once you get the immediate problem under control, you may need to consider tackling the larger underlying issue.
Lead time distribution charts are very useful for making improvements to your system of work. Understanding what to target and when will ensure that you get the best “bang for your buck” in improvements. Making these improvement will help you stablise your system of work and improve predictability which will open the door for the next level of possibilities for your organisation.
Here’s an example of a lead time distribution chart:
To recap what your looking at here (for more info, please refer to https://evogility.com.au/lead-time-distribution-charts/):
- X-axis: Number of days from when something was committed to, to when it was completed (ie the Lead Time). Note that in the above they are recorded at 5 day increments. So, the value for 10, represents the number of items greater than the last measure (5) and 10.
- Y-Axis: Count of the number of items that fall within that range. The number at the top of each column represents the total count for that item.
Lets look at how you can use these to make improvements.
Long Tail
You can see there are a number of items coming through at the 70-85 day mark. We need to be genuinely curious about what is going on here. There may be a couple of things going on here:
Different class of service – Perhaps these are items with a low cost of delay that are continually getting pushed back. Perhaps it’s worth capturing this in a different lead time chart so that you understand the lead times for each class of service independently.
Different work item type – Similar to class of service, maybe this is the lead time for a certain work item type – it may be naturally longer than the others. Again, you might want to separate those out into their own chart and create different lead time expectations and control WiP for them.
Refutable demand – Looking at these items, is there a way that they can be identified and not accepted in your system? Is their cost of delay valuable enough or is there some other organisational imperative that is pushing this into your system needlessly. Keeping out undesirable work and not “auto-commiting” to every piece gives you better ability to manage your system.
External dependencies – This is often one of the most common causes for delays – a dependency external to your control blocks these work items. Is there a way you can remove the dependency (perhaps you can upskill one or more of your team to do this work)? If you can’t do this, then is there a better way to identify the dependency early and coordinate with that group to avoid the delays?
Once you get rid of that outside tail element, the end of the tail shifts, and we’re now looking at the 30-50 day range. All of the above are still applicable. With a larger volume of items, you might want to also try:
Blocker Clustering – There might be multiple different causes for blockers that you want to explore and prioritise for removal / reduction. See this article by Klaus Leopold and Troy Magennis to learn more on blocker clustering.
Once you’ve gotten through these things, congratulations, you’ve now “trimmed the tail”, let’s look at what else you can do.
Simple Requests
Look at the left hand side of the chart. The bulk of the requests are in the 10 day or less mark. There may be something you can do here:
Automation – There are lots of these items and they are fast, perhaps they don’t necessarily need a lot of brain power to actually get done. A subset of these you may be able to remove from your request queue through automating the process. Try to categorise these requests and look at what your automation options are for these.
Avoidance – Avoidance of these requests might also be possible. A great example of that is an IT service desk that put together a process for people to automatically, or through their manager, reset their own password. This reduces a great deal of calls to the service desk and frees up time for more important requests.
Work Item Type – As we saw in the XIT case study in our Kanban System Design course, you can often identify a particular work item type and negotiate it out of the system.
All of the options above free up capacity for your team to do more “knowledge work”. That is, the kind of work that is human intensive and valuable to customers. These improvements will help you “trim the tail” and make it more predictable.
If you want to learn more, become a Kanban Management Professional (KMP) by completing these courses:
On Thursday 9th July 2020 the Melbourne Kanban meetup, the Sydney and Wellington Limited WiP Society meetup groups got together to conduct a Kanban Unconference.
In conjunction with my co-facilitators Ben Hogan and Silke Noll, we undertook to do a virtual unconference on Kanban with our meetup groups. An unconference is quite simple, we make up the topics on the day and there’s a few basic rules to it:
1. Whoever shows up are the right people.
2. Whatever happens is the only thing that could have.
3. Whenever it starts is the right time.
4. It’s over when it’s over.
Remembering the “Law of two (virtual) Feet” which means if you’re not getting or giving value in some way, you’re free to continue to move around.
Here’s the schedule we came up with:
Here’s a great shot of Ben facilitating the session:
We’ve done this before in person in the Melbourne Kanban meetup, but never done it virtually. We used VideoFacilitator and Mural for the tools and they were perfect for this kind of setup. If you’re thinking of doing an virtual unconference yourself, you should check these out.
I really enjoyed the session and I think my co-hosts also got equal enjoyment from it. Our attendees also responded positively to this. It’s more personal than a regular conference, and with everything being remote lately, we’ve been doing a lot of presentations in the meetup, so small conversations were a welcome change. It was so good, we’re thinking of doing this on a slightly larger scale in the future.
Here is a link to the output from the session:
Work item ageing charts are particularly useful for solving issues that are currently impacting your teams. Whilst other charts such as Lead Time Distributions and Scatterplots can be useful for coming up with countermeasures for issues that you experience in the past, Work Item Ageing charts are useful for the present issues.
Lets look at an example below:
To break it down:
- X-Axis – This is the date that the item was started
- Y-Axis – This is how old the ticket is (how many days since it was committed to)
Each dot represents a work item that is currently in progress.
For the purpose of this post, lets assume that our lead time expectation with customers is 90% within 50 days. We can see one work item approaching 80 days! This is something that should have been actioned earlier, but without a chart like this we may not see those things. This will likely need some customer alerts if that hasn’t already happened and some work to regain our customers trust. Although it falls within our 10%, it has far exceeded the expectation and needs rapid action.
The two items approaching 40 days also need action as our lead time is fast approaching. This case is not as dire as we are still within expectations, but as a leader you will need to offer support to remove blockers, plus you might also want to think about other ways to get this done. For example, you might need to increase their class of service to get the team swarming on these to make the date.
The item that’s at 25 days is not necessarily a problem yet, but may be a problem in the not too distant future. Keep an eye on this, but no need for anything drastic yet.
The Work Item Ageing chart is really useful for helping you see issues that are in your system right now. You may need to create policies to ensure that your lead time and other customer expectations are being met. It can also be useful for ensuring that you have a stable and more predictable system to benefit your customers.
Backlogs often become a dumping ground for ideas. Some of those ideas are good, others might need some exploration before we understand if they’re worth it or not, but many of them are often not worth pursuing. After some time, it can be cumbersome to start to trawl through an ever increasing backlog to find the right value item that you should start to explore.
If you’re using a backlog and not thinking of them as options, please refer to an earlier blog post that talks about using options instead of a backlog (from here on, I’ll refer to them as options):
https://evogility.com.au/use-options-instead-of-backlogs/
Options have a value at a point in time. Generally they have a cost of delay. There’s also a cost of retaining options for too long – think about a options list that has a thousand items in it, how long is it going to take for you to find the top 10? You need to regularly trim your options list to make sure it’s lean and gives you insight into what are real options you need to spend your time on.
Put it another way, if you’ve had an option in your list for a year and haven’t taken it up, how likely is it that you’re going to take it up in the next year? For that matter, if you’ve had an option in your list for six months and not proceeded, how likely is it that you’ll take it up in the next six months? Or three months? If you’re thinking to one / all of these that it’s not very likely, then you’ve really just hit on your option expiry date. After a certain amount of time those ideas have expired.
Think about your answers to those questions. The one that’s the shortest to which you answered “unlikely” is your option expiry timeframe. Record the date that an option enters your pool of options. After the amount of time you discovered above (say it’s six months), that becomes your option expiry date.
Periodically remove those options that have exceeded that timeframe. Just throw them away. Even better, if you have an electronic system, set a rule to do it for you. Don’t worry, if it’s really important it will come back and you can create another ticket.
Doing this will save you time and help keep you focused on things that are important right now.
These are not very widely used, but are one of my favourite charts for helping to manage flow. I find it quite simple as well, which once you finish this article I hope you also find it equally simple and useful.
When managing flow you often want to make sure you team are not taking in more work they can handle, plus you also want to make sure they don’t “starve” for work. Continually looking for balance can often seem difficult, but using this chart you can help achieve the balance your looking for.
Here’s a look at a net flow chart:
Essentially, the green points above the line mean that for that week you’ve gotten more items done that what you’ve started. The red points below the line represent weeks that you’ve started more items than you’ve completed. Those weeks that don’t have a line in them (with a zero) are weeks where you’ve balanced input and output (well done!).
Where you see build ups of several weeks of the one colour, that’s usually a warning sign that you’re flow is out of balance.
You can see in the early part of this chart there is a lot of red. That indicates that WiP is increasing and is often an indicator that you need to start to choke the input to your system or it will be overwhelmed. However, there is often an exception to this where teams are bootstrapping / starting out – you want to start to pull work into the system and it will take some time before the first item flows out.
Alternatively, if you get a number of weeks of all green it means that you’re team are finishing a more work than they started. This is an indicator that you need to get out and start some more work. In the event that you have an upstream, you may have a lead time before that work comes to your system. It’s important to see these signals early and can respond to it.
In first diagram above, you can see in the middle there were a period of time where it was back and forth. Then towards the end you can see balance starting to be achieved. This is an important part of how you use this chart – often with a large board and different work items types / classes of service, it’s hard to see important details of this without the data representation. I hope that you can now you can see the value in this chart and can try and use it.
It’s freely available here if you wanted to download it:
One of the really useful charts that I commonly use with Kanban implementations are lead time distribution charts. Given that lead time is one of the key metrics, at least from a customers perspective, understanding the nature of lead times for your Kanban system is a must for ensuring a more fit-for-purpose and customer focused approach. Understanding how to read these charts and take action to achieve that kind of outcome is an essential skill for any kanban practitioner.
One of the key points about lead time is hinted at in the above title – it’s a distribution, not a single number. If you take nothing else away from this article except this point, it will put you in good stead to start to make improvements. Too often, I hear about people talking about “when it will be done” and referring to a single number, like an average. This is inherently disadvantageous, because it denies the real nature of lead times, especially in knowledge work.
No doubt, you’ve seen before a lot of variation in the knowledge work you’re involved with. Items are not all the same size or complexity, plus you have to wait for others which causes delays which are often unpredictable. These kinds of things lead me to prefer to acknowledge the variation in lead times we see, rather than ignore them.
Here’s an example of a lead distribution chart (also known as a histogram):
Here is an explanation of what you’re seeing:
- X-axis: Number of days from when something was committed to, to when it was completed (ie the Lead Time). Not that in the above they are recorded at 5 day increments. So, the value for 10, represents the number of items greater than the last measure (5) and 10.
- Y-Axis: Count of the number of items that fall within that range. The number at the top of each column represents the total count for that item.
You can see from the above chart that a significant number of the overall items fall within the 5 & 10 day counts. 43 out of the 78 items (over half) fall within this range. Clearly the majority of work falls within this range, but would you feel confident giving a commitment based on just a 55% hit rate? Of course not, because as we can see, a large number of items are still counted up to 25 days. A little over 80% of items (for the purpose of this, we’ll round up to 85%) take up to 25 days. This is a little better, and you may feel comfortable in giving a commitment based on this, but keep in mind that its up to 2.5 times longer than our earlier sample. Had we given a commitment based on what we thought was more commonly occurring lead time (which is often where our biases may take us) we might be facing considerable customer disappointment and the consequences that go with that.
There’s also a section between 30-50 days, not a great deal of items, but you can see that there is a not insignificant chance that we might land an item this late (about 10% of items). Again, this is 5 times what our first sample told us. In other words, 1 in 10 customers would have to wait 50 days instead of the 10 days if we had promised that. How would you feel as that customer?
Lastly, there are our outliers from 70-85 days. Outliers are a normal part of your system – you shouldn’t dismiss them out of hand. In our case, they’re about 5% of the total, or 1 in 20 requests.
When I look at the actual data behind this chart, the average lead time is approximately 16 days. Perhaps instead of jumping straight to commitments of 10 days, or even 16 days, we might like to take the full distribution into account. Instead, how when discussing time commitments, perhaps acknowledge the distribution with something along the lines of:
“Over half our requests are finished in 10 days or less, the average being 16 days, with 95% of all requests being completed in 50 days.”
This is a better discussion and uncovers the real nature of the work and will lead you to start to make better commitments that are more reliable.
Future posts will cover how to use the Lead Time Distribution Chart for making improvements.
The lead time chart was produced by the freely available FocusedObjective spreadsheets downloadable from: http://bit.ly/SimResources
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.