Kanban Boards for Constraint Removal

Using Kanban Boards for Constraint Management in Last Planner’s^® lookahead
An alternative to constraint logs

By Luca Cotta Ramusino (Florence, Italy), Lean Construction Coach, Scrum Product Owner (https://www.linkedin.com/in/lucacr/) Peer-Reviewed.

SUMMARY: Constraint logs get buried in details. Agile Kanban boards are Highly Visual, Better Early Warning, Keep Team Focused

In my experience, work is rarely “not done” because the crew doesn’t know how to do the work. Rather, it’s because the crew is often shut down due to outside constraints, obstacles and impediments.

The Last Planner System^® of Production Control (LPS^®) attempts to address the issue by focusing on what you CAN do, as opposed to what you SHOULD DO. Consequently, it constantly works towards identifying and removing obstacles collaboratively.

A constraint is anything that might prevent an activity from starting or, more importantly, from finishing. During the lookahead phase of LPS, as soon as constraints are identified they are written down in a special table called a “constraint log”. Typically, a constraint log has a column for the constraint description, i.e. the what is blocking a certain activity, and columns for who needs to resolve the constraint by when, to avoid delays in the activity.

PART 1

Agile Kanban for constraint management

My experience with the Last Planner constraint log has been somewhat mixed. My biggest gripe is that as the log grows, it becomes more and more difficult to answer the fundamental question for each constraint, i.e. “will we fix this in time?”.

And yes, you can add more columns to the log, such as when the issue was first raised, to monitor aging, and some sort of status or progress, but the more columns you add, and the more issues are raised, the more confusing it all becomes.

I think I have found a better solution, a highly visual method that offers fast insights into what issues are blocking work and how good the team is at removing them.

The method is called Kanban (capital K) and is borrowed from software engineering, specifically from the framework of Agile software development.

I am calling this method “Agile Kanban” on purpose, to distinguish it from the “original” kanban (lower case k) as developed in the Toyota Production System. Agile Kanban is in fact inspired by Toyota’s kanban. It’s a method to streamline software development by making the process visible and limiting “stuff we have started but not completed”.

The Agile Kanban method for work management focuses on finishing quality work, fast by visualising work and limiting Work in Progress.

I think Kanban, used in conjunction with the Last Planner System, is a better method to take care of constraints, impediments, roadblocks etc. i.e. all that stuff that is preventing work from starting or finishing.

How the Agile Kanban Method Works

1. Make work visible. Make sure everyone knows what work items need to be completed by putting kanban cards on a board. The Kanban board is divided into columns, with each column representing the state the work is in. The simplest kanban board has three columns i.e. “TO DO”, for items ready to begin, “DOING” for items being worked on, and “DONE” for completed items. More complex boards may have more columns, i.e. “REVIEW”, “APPROVAL” etc.
2. Limit Work in Progress. Work is advanced through the columns by pulling, if and only if there is space for it in the adjoining column. This is a key concept, if you’re not pulling, you’re not doing Kanban. The purpose of limiting WIP is to reduce activities and work items that are started but never completed.
3. Establish process policies. Process policies are simple rules that people on your team can apply whenever new work items come up, in the form of “if this happens, do this”. For instance, who can add new work items to the board? What should we do when an “urgent” item comes up? How do we know when this work item is done? Policies must be simple, transparent and enforceable. Anyone on your team should be able to decide quickly what to do when something new comes up.

Actual Constraint Kanban in use on a project. Courtesy: Pankow Construction.

That’s it. These three simple rules are all you need to get started. You don’t need permission from anyone. In fact, Kanban can be implemented 100% internally. From the outside, it just looks like you are taking care of roadblocks much, much faster! Once you are underway, you can start measuring your efficiency, as shown below.

Success Ingredients

These four principles will help you succeed in your Kanban journey.

1. Start with what you do now. Kanban is evolutionary and incremental, consistent with the lean approach of continuous improvement.
2. Agree to pursue incremental change. Yup, that continuous improvement thing again, the kaizen spirit underlying all lean methods.
3. Respect current roles and processes. If you are still in business, you must be doing something right, so relax. You will get there, one improvement at a time. Evolution, not revolution, is key.
4. Encourage leadership at all levels. If you want to be fast, you need to empower people to step in and take charge. You want your team members to be self-starters and exercise initiative, i.e. taking action in absence of explicit instructions. Rather than asking “Whose job is this?” they should be thinking “Is there anything I can do about it?”

Kanban and Constraint Management

To apply Kanban within LPS during the lookahead phase, here’s what you should do as soon as you identify a constraint.

• First of all, fill in a Kanban card, in the form of a post-it stickie. Write down what you believe is valuable information about the issue. At a minimum, write down the date the issue was first raised/identified, the WHAT needs to be resolved, by WHEN and by WHOM.
• Next, put the card in your TO DO column. The card moves to the right into the DOING column only if/when there is space for it. So, for example, if your process policy says that your DOING WIP limit is four cards, with max one “urgent” card (I just made up these limits for the sake of example) and you already have four items in your DOING column, the issue stays in TO DO until one card moves from DOING to DONE, thereby “pulling” that card from TO DO into DOING.
• Kanban is all about completing work fast by limiting the amount of items you are focusing on at any one time. Of course you will be tempted to work around your self-imposed WIP limits. Don’t.
  Basic queuing theory states that if new requests arrive at random intervals, and service time is variable, then if you increase your queue spaces linearly, your waiting times will increase exponentially. In other words, every time you catch yourself saying “I can take this one too” you are exponentially slowing down every other job in the pipeline.

There you have it. This is the most basic version of Kanban. You now have a highly visual system for expediting and removing roadblocks, that you can use together with your Last Planner System.

PART 2

Classes of Service

For a more advanced version, you can introduce different classes of service if you wish. We acknowledge that not every delay affects your project with the same severity. Some activities we can “let be” for a while, without too many negative effects, while other constraints need to be resolved quickly. So, we may associate to every constraint a corresponding Cost of Delay. Typically, we identify three kinds of CoD.

The first kind is the “urgent” or “expedite” item, i.e. failure to act swiftly to resolve the issue results in ever increasing costs to the project. You need to act, now, or continue paying an increasing price until the problem goes away.

The second kind is the “fIxed date” or “deadline” item. You can safely ignore the item up to a certain date, after which the costs increase very fast.

And finally there are “standard” issues. You obviously cannot ignore these items, but their cost of delay goes up slowly.

If you decide to implement classes of service for your constraints, then your process policies, i.e. how you move work items through your board, should reflect this. For example, you may want to assign WIP limits to each class, such as “there will be at most one expedite class constraint in the DOING column, one deadline and two standard constraints”.

On paper or Online?

The beauty and efficacy of Kanban is that it is highly visual. Put that board right where everyone can see it! That’s why I prefer paper stickies over apps. They convey a much more powerful, “in your face” message.

Unfortunately, there are limits to the offline, analog solution. For instance, what if not everyone in your team is co-located? Or, what if you have too many stickies?

In this case, there are many online apps that offer collaborative Kanban planning, either for free, to get you started right away, or for a reasonable cost per seat. The most famous is Trello, which is available for iOS, Android and as a web app. Most of the required features for tracking LPS lookahead constraints are included with the free version, with the option of upgrading to a more powerful version for US$5 per user per month.

How are we doing? Measuring team efficiency

Here’s where an app really helps, compared to an all-manual system. There are two important metrics in Kanban, and they are readily available if you use online Kanban.

The first metric is cycle time, i.e. how long a task spends “in progress”, i.e. average days from DOING to DONE. Only tasks that are started contribute to cycle time, which is different from lead time, i.e. the time elapsed between when you first identify a constraint and the time when you resolve it. If your cycle time is low it means you are delivering value by removing constraints, whereas if your cycle time is increasing it indicates there’s something in the process that is stalling progress. By keeping track of your cycle time you are predicting a) whether you are improving, because your CT accelerates and b) what your customers should expect in the future in terms of time to completion.

The second metric is throughput, which is defined as number of tasks completed per time unit, i.e. constraints/week. A steady throughput is good, a rising one is better, obviously, and a falling throughput might signal that something is preventing you from delivering value.

Finally, the last fundamental metric of the Kanban method is the Cumulative Flow Diagram (CFD), which shows how many work items are in each stage of the pipeline at any one time.

This chart quickly gives you a high-level view of your process. If the slope on the DONE curve is increasing, you are delivering value faster, whereas if the DOING/IN PROGRESS slope is increasing, it means you have a bottleneck in your process. By the same reasoning, an increase in the TO DO slope means your team is nearing capacity because issues are coming in faster than you can look at them.

Conclusions

I now use Kanban almost exclusively for constraint management instead of constraint logs. In my opinion, its main advantages are:

• Highly visual system. The nature of the Kanban board is such that it conveys a much richer message on where we are, quickly and intuitively. If you see the DOING column full of stickies, you can guess there’s a problem from 5 metres away, even if you can’t read the text on the individual cards.
• Better early warning. It’s a lot easier to spot aging tasks, stuff that’s been sitting there for too long and is about to become a big headache. To make this even more obvious, I recommend marking cards with a dot or cross every day they sit in the DOING column, to emphasise the fact that we’re not delivering on that issue.
• Keeps team more focused. By limiting work in progress we are forced to concentrate on whatever is already in the DOING column, instead of trying to cram more tasks into it. Violating your own WIP limits simply increases the number of non-completed tasks.

One final recommendation from me: iterate, iterate, iterate. Try Kanban as you understand it now for some agreed time and don’t stress too much over the fine details. Just do it for a while and when you’re done, reflect on it. What worked and what didn’t? What should we continue doing? What should we stop doing? What should we be doing more often? Kanban is evolutionary, not prescriptive. There is no “Kanban practice” as such. It’s up to you to deliver increasingly efficient versions of your Kanban, so go for it.