Kanban, which literally means “billboard” or “sign” in Japanese, was developed over seventy years ago at Toyota as a way to improve manufacturing. Since its inception, the concept has been adapted by many methodologies and frameworks and includes many variations of the original kanban card and cart.
Here, we will discuss how it can be applied to complex projects such as hardware product development.
In kanban’s first iteration, cards were used by Toyota to better manage inventory flow between machines in manufacturing. In traditional manufacturing (which is a “push” system), machines would produce their output in large batches so that each machine was “efficient” when you measured its output over a given period of time. This has a lot of drawbacks, and too much inventory and slow detection of defects were the main two.
With kanban, instead of every machine making parts as fast as it can, two carts are put between every machine in a production line. On one side of the machine are two incoming carts, and on the other side are two outgoing carts. Every cart has a card in it (hence the name kanban), which says how many parts it is allowed to hold. Once an outgoing cart is full, it gets sent to the next station. And after an incoming cart is empty, it gets sent back to the previous machine to be filled again.
Obviously, if your incoming cart is empty, you can't keep working. But just as important, if your outgoing cart is full and hasn't been replaced by the returning empty one, you also have to stop working—even if you have a full incoming cart.
This simple approach has several immediate benefits. First of all, it greatly reduces work in progress (WIP) and, therefore, inventory. It automatically adjusts the pace of work to match the slowest step in the process. And it also ensures that any mistakes or errors are caught before they have been repeated too many times in an upstream process.
In other words, this simple process—two carts with cards in them—makes the factory run much more effectively.
Kanban project management is an Agile methodology that helps teams visualize their work, improve efficiency, and achieve smooth workflow—very similar goals to manufacturing. Rather than carts and cards, a large board is divided into columns that depict different stages of the workflow (e.g., To Do, In Progress, Done), and all of the work items are represented as cards (or sticky notes) and placed on the board. The team members move these cards across the board as the work items move through the different stages.
There are three primary rules for using a kanban board for project management.
In software development, kanban was introduced to better manage Iterations (or sprints depending on the Agile framework you are using). The problem developers were finding with iterative development was they suddenly had many tasks to get done at the beginning of a sprint, but no way to manage the tasks. So they ended up multitasking and working on many things at the same time.
With the use of a kanban board, sprints or iterations became more manageable. Developers could see where the work was piling up, and if it was due to a specific resource type they knew what kind of help they needed. Every team member could easily identify what needed to be done next without having to ask or guess. And everyone was naturally prevented from multitasking.
The simple kanban system works well for tasks that always go through the same process steps, such as software development. However, it falls short in more complex environments such as hardware development where the work items go through a wide variety of process steps.
In fact, hardware projects differ from software projects in many other ways:
Because of these differences, it is necessary to combine the beneficial features of a kanban system with the traditional Gantt chart.
Of all the items listed above, the primary need is the ability to show the dependencies between the work items. Without a way to visualize these dependencies, it is impossible to know what order to work on the tasks in the backlog, and when each work item can be started.
The second most important item is the ability to show the duration of each work item. Without these two abilities, it is impossible to estimate the end date with a useful amount of accuracy.
The Gantt chart does both of these very well (but it has many drawbacks when used alone). Once the work items are linked together with their functional dependencies, and the duration of each item is estimated, you have an approximate completion date for the milestone at the end.
In addition to the end date, you have a new and very valuable feature—the critical path. It’s called the “critical” path for a reason and merits its own writeup, but the main summary is we can use it to generate relative priorities for every task in the project.
Every task on the critical path will move the end date of the milestone by the same number of days that the task is delayed. This is because it has “zero slack”. Every other task in the project can get delayed by the amount of slack it has without moving the completion date of the milestone.
So the critical path gives us a great way to establish relative priorities for every task, and the dependencies in the Gantt chart give us an additional way to sort within those priorities.
When you combine these two methods, you have every benefit of the kanban system (pull, reduced WIP, single-tasking) and every benefit of the Gantt chart (relative priorities and predictable end dates), and none of the drawbacks either of them had for complex projects.
Watch our demo to learn more.
True. Creating a long-term detailed plan for a process that has high levels of uncertainty doesn’t work very well. Fortunately, it’s not necessary either.
We recommend a Decentralized and Rolling Wave Planning process that closely mimics the scrum sprints.
Decentralized planning begins with outlining the overall project at a high level and then having the team members fill in the necessary details in the near-term phases of the project. Rather than pick an arbitrary two-week time frame, the team normally plans to the next significant milestone. Then, once the project is going, the team utilizes Rolling Wave Planning to update the plan on a weekly or bi-weekly cadence and continue to add detail as necessary.
This has many benefits:
Once the team has a plan with enough detail to have an accurate critical path they can use that information and combine it with the tasks on the kanban board to derive a lot of additional benefits.
The kanban board discussed above is normally used as part of the scrum process in standup meetings. As mentioned, it limits WIP, prevents multitasking, and shows what everyone is working on. But it has some drawbacks—it does not show when the work item will be done, or what they will do next (or how long they’ve been working on it).
When the tasks on a kanban board are combined with the information available in the plan (relative priority, assigned resource, work/effort, planned duration, and predecessor status) the information on the board can be much more useful.
The traditional scrum meeting has each team member share three bits of information:
This is good information, but it takes a bit of time for everyone to share and is not very important to a lot of people in the meeting. By making all that information visible on the kanban board, everyone can see it at a glance and they can start the meeting with the two most important questions:
Is the critical path blocked?
If not, are the near-critical tasks blocked?
By sorting the board so the team members with critical and near-critical tasks are at the top, the team can quickly answer these two questions first. Then they can proceed with whatever discussions are necessary for the remainder of the active tasks.
It’s fairly easy to have a standup meeting with twenty people take less than ten minutes.
Besides a more efficient standup meeting and all of the other benefits mentioned above, there’s one more benefit to the way Playbook combines the Gantt chart with the kanban board, and it outweighs all of the rest.
It ensures every team member has correct priorities, every day, for all their projects.
Why is that important?
We’ve discovered that the biggest cause of delay for most projects is the daily slips that occur when people are working on incorrect priorities. Daily slips are small (only one day!) but they accumulate without anyone knowing and can easily add up to double the duration of your project.
Seriously. By ensuring everyone has correct priorities 100% of the time, timelines can often be reduced by 20%-40% due to this benefit alone.
Kanban is a fairly simple concept that has a lot of benefits and has been applied in a lot of ways.
Gantt charts have also been around for a long time and are very useful when the work has a lot of dependencies.
They both have their benefits and drawbacks, but when they’re combined correctly, you not only eliminate the drawbacks, you get additional benefits that were not previously apparent—predictable end dates.
If you want to win at the game of hardware product development, combining the benefits of kanban with a Gantt chart is the winning combination for hardware teams.
If you would like to see Playbook’s kanban board in action, register to watch this demo, or schedule a call to discuss how Playbook could improve your team’s daily workflow and help them achieve predictable end dates.