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:

http://bit.ly/SimResources

Earlier in my journey as a coach / delivery consultant, I thought that agility can be achieved through a “high performing team”. Many agile coaches, scrum masters, delivery leads / managers etc have tried to achieve this kind of thing through making a great team. This might work really well in a small organisation, but once you get to medium to large size organisations, this is not necessarily where the key problem is.

In more recent years, I’ve observed how critical it is to bring various groups together to achieve an outcome. The solutions to some problems are larger than just one or two teams and create interdependencies for delivery. Often, the points of waiting and even friction occur where these interactions are necessary.

Problems with “High Performing” teams

A high performing team works great when all of the dependencies are contained within the group. This could be a single team or a “Service Team” which I see as a larger group or “team of teams” providing a service (eg five 10 person teams working together). Often this team have optimised the interactions within the group and have a fairly well known way of working.

Where this group needs to interact with others in the organisation, it can run into problems. Other groups may have their own way of working which may be similar but is often times different. Relationships between members of the different groups may not be very deep or perhaps non-existent.

Additionally, I’ve seen in the past where teams are “high performing” this can increase the silo mentality and start to create a blame culture. That is, they don’t want to be seen as a non high-performer and become insular and in some cases arrogant. They can call blockers out up and downstream, but don’t want to spend their time being “unproductive” by relieving the blockers. If it goes unmanaged, you can see them pull in more WiP in this circumstance while they wait , which creates further problems.

It may be that they don’t have the skills to go upstream / downstream to help relieve the overall system. Thus they continue on with solving “their part of the problem”, but the overall tends to suffer.

Take, for example, a mobile development service team. They may make regular (eg monthly) improvements to the mobile application / device for your organisation which they can do entirely by themselves. Then at some point your organisation wants to launch a whole new feature not previously seen. You want to showcase this at an upcoming trade fair to generate the largest possible market interest in a short amount of time. Your mobile team will need to work with the marketing team and sales teams to ensure you can maximise the revenue opportunity at the trade fair. They may have rarely done this before, thus the interaction is unusual but critical for the overall business success.

Nature of work in large organisations

Your organisation is a network of interdependent services that act together to serve your customers. This is really an adapting, changing, organic ecosystem if it’s running effectively. External stimuli (customers, markets, competitors) will place new demands on the ecosystem and it’s long term success is based on it’s ability to adapt to that stimuli.

In larger organisations, there may be some interactions between groups that are consistent / regular (work together on many / most initiatives), others may be occasional (eg once or twice a year) and others may be a “one off”. For those that are consistent or occasional, you may be able to predict this to a certain extent. Even if you can predict the frequency of the interactions, the nature of the individual interactions may be quite different.

Oftentimes, the really high value work will mean that this kind of work likely doesn’t have much / any connection to previous work so you’ll need to establish some relationships from scratch.

Possible Solutions

Understand the network

Sometimes to get this understanding you may need to visualise the work and “how work works” as it traverses the organisation.

Where it is at all possible, it would be worth gathering some data about the network to understand the interactions. You can see where the common links are that you want to strengthen and how you may wish to make changes. You may also wish to gather data on where wait states and blockers are in the overall workflow. You may wish to introduce a cadence like Kanban’s “Operation’s Review” to continually monitor and adjust.

Protocols

The internet is a classic example of a network that grows and changes over time, but the fundamentals of how nodes communicate with one another is governed by some simple protocols. You can set this up as basic systemic policies to allow for simpler communication and coordination around the network.

Cadences

Sometimes cadences can work to help with synchronising groups. However, beware of this becomes sometime they can be a source of waiting / waste. For example, if you have a quarterly planning cycle, you may not want to wait that long for a new, urgent piece of work.

Reorganise teams

This really isn’t really viable in the short term – with different work coming from different sources it often doesn’t make sense to continually reorganise. Furthermore, there are costs associated with doing so – there will be a period of inactivity, plus you’ll lose the benefit of previous metrics for that team as it establishes it’s new identity / way of working. If in the longer term you see a continuing pattern of teams working together, you may want to take action at that point – just wait until the reason is compelling enough to justify the cost.

Remove dependencies

This is something that you should always consider, however in larger more complicated work, this is not always practical or possible. You may achieve this by slicing work into more narrow / succinct areas of scope to avoid the immediate need for a dependency. This can also be achieved by changing a technical need for the dependency.

Coordination specialists

Some people are natural connectors in organisations, knowing who to contact / bring together to help solve problems. You can use these folks to help guide work through the network, facilitating the creation and maintenance of connections where required.

Team Member Swap / injection

While complete reorganisation of teams may be too disruptive, you may wish to consider injecting a member from one service team to another to act as a bridge for a particular initiative. This could also take form of a swap where team members are exchanged from each group. This will help build a deeper understanding of the other groups context which will make this and future interactions smoother.

Stimulating the organisational network

There are a couple of spins to this from my perspective – one is the effect you get from large group events where there is lots of interaction. Meeting new people and understanding who is who can help to start to bridge the gaps of connectedness – this can often occur as part of a regular planning or other similar cadence. The other way is a deeper understanding is through other techniques like Cognitive Edge’s Social network stimulation.

Conclusion

As your organisation grows, the complexity of how it solves problems will likely also change. When you get to a certain size, having a “high performing team” will not necessarily be enough – you will need to tune the entire network of services to be able to adapt appropriately.

This is not a simple problem to solve, so it’s best that you don’t act too simplistically. Furthermore, as the organisation and environment continually evolves you will never be “done” with this – you’ll always need to monitor and make continuing adjustments.

As I mentioned in my recent post on Kanban books, I would recommend Klaus Leopold’s book on this topic: “Rethinking Agile: Why agile teams have nothing to do with business agility”.

RETURN TO BLOG

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.

RETURN TO BLOG

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.

RETURN TO BLOG

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.

RETURN TO BLOG

Everyone has probably seen a job ad for a “rockstar” team member, or perhaps it’s come under a different name like “ninja”, or you may just know them as “heroes”. How would you define something like this? Usually people are looking for the expert / saviour that will help get things over the line even when things are tough.

In reality, what this often manifests in are individuals who are working for their own purpose, rather than that of the organisation. Oftentimes, these individuals tend not to share knowledge and often work alone since the sharing of knowledge would threaten their position as the “rockstar”.

The effect that this kind of behaviour can have includes sub-optimising the system and creating a bottleneck – since only one person can solve all of the tough problems they quickly get overwhelmed with work. Since they won’t reach out for help it becomes an escalating problem as more and more work get’s backed up in front of the bottleneck.

It can also have problems on team morale – when team members see people acting as individuals, then they will start to either resent those people pushing them further from the group and / or give others permission to act for their personal interest rather than the organisation’s interest.

You can start to see how one policy of hiring “rockstars” can have multiple impacts on the overall system of work. Is it really the rockstar who is to blame here, or is it the system of work and the leaders that allow this behaviour to continue?

In discussion at our local lean coffee group, one of the members used the example of a football (soccer) team. In which, he said he wants those superstars on his team because they convert those rare opportunities into goals that win matches. However, they often have rules in place to ensure that the star players don’t get ahead of the team – with systemic solutions such as dropping a player for a week if they act in their personal interest rather than the team / clubs interest (for example by not passing the ball in certain situations).

I think therein lies the solution – you can have great people in your teams so long as the system is set up so they continue to work in the organisation / team’s best interest, rather than their own. Set up the system so that great people can work together to achieve great outcomes and put in place measure that allow this to happen and prevent the need for heroes.

The origin of this statement for me goes back nearly 20 years ago when I attended a technical leadership training event whilst I was working at Hewlett-Packard. At the time I remember thinking that I learned more worthwhile lessons in a week of that course than in entire subjects at university. The title of this post is one of the key lessons that I took away and am still using today.

So, a little explanation is in order as the statement sounds a bit crazy taken out of context. During this training session, we were taken through a series of simulations – with a explanation and discussion of relevant points after each simulation.

The simulation behind this statement was a simple problem solving situation. The idea was that there was multiple rounds and each round there was a “minimum” score that you had to get (I think it was around 20 points). After each round, you presented your solution to the facilitator who would then calculate your score based on the answer you gave. Highest scoring team wins. There was a fairly simple and repeatable way to get 25 points which was over the minimum – it didn’t take a lot of brainpower to figure out. Now, you could try different combinations and there is a distinct possibility that you could fail and get zero points.

Different teams tried different strategies and I remember our team after getting the simple answer started to get bored. So, we decided to experiment. We failed a few times, but it gave us insight to try new things. After a few rounds our scored had dramatically increased (I can’t remember exactly how much, but I think it was in the order of 100-200 points). Within a couple of rounds we had made up any lost scores of the experimentation and we were the winning team.

During the debrief I remember the facilitator saying that he’s seen all sorts of permutations for this exercise. One that he remembers most was a sales team who repeatedly answered with the basic scenario getting 25 points a round. He said at the end he asked them why they did that, to which they replied “We made quota”. This in contrast to our teams approach was very different – we got bored as there was no growth / interest in maintaining the status quo so we experimented.

During our debrief the facilitator was going through how to solve problems – in particular with people working in technical domains. Obviously, when one of our experiments failed, we would try something else. It makes me think of the quote / cliche “Insanity is doing the same thing over and over and expecting a different results” (to which I would add, unless, as cynefin has shown me, you’re in the complex domain and you may well get different results). Anyway, continually repeating a failing practice tends not to be a good idea. Which brought us to the first part of his statement “If something’s not working do something different”.

The next part, relates to how we felt during the simulation. We figured out the basics and were getting bored. This is often the case with technical teams, and I’d also say knowledge workers more generally. They like to solve problems – a solved problem repeated over and over will not keep their interest for long. It also means that you plateau in terms of capability. You need to look for new ways of doing things, for example the evolution of land transport from horse to railroad to car. There’s a ceiling to breeding horses, they can only go as fast as their able – but different means may allow something superior to emerge. Getting around on horse is still viable for basic transport, but we may want something better. This relates to the second part of the statement – “If something is working, do something different”.

Therein lies one of the key lessons I’ve learned in my professional career: “If something’s not working, do something different. If something is working, do something different”.

RETURN TO BLOG

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.

RETURN TO BLOG

I’ve heard this being said a number of times with teams and it often reminds me of the story the Jeff Patton told in his book “User Story Mapping” when he was talking about requirements. In that story, when he was trying to get a better understanding of the underlying need being requested he was told “They’re requirements” – to which he likened to being told to “shut up”.

When I hear the term “It’s on the backlog” I think that’s another way some agilists are telling others to “shut up”, or at the very least “go away”. Often it’s not followed up with more honesty like “we don’t intend to build that”, or at the very least “it’s not likely to be built in the near future”. Sometimes this is a way of saying “No” or “Not yet” where it can be difficult to say this flat out, but is it the most respectful way to treat people?

Again, this is the problem with using the term “Backlog” instead of “Options”.

How about instead try something along the lines of “we can add a ticket to our pool of options, but it’s not likely to be implemented anytime soon, if at all”. You might find that this change in terminology gives your stakeholders greater respect and builds on the trust and transparency that you need to build a more stable foundation for a longer lasting relationship. Also, you’re starting lean towards the use of language that supports probability / likelihood rather than absolute certainty. This incremental step can be built upon later with greater use forecasting.

RETURN TO BLOG