Why is Gantt and Kanban such a killer combination in hardware development for accelerating projects? Some of you may instantly recoil at the mere mention of a Gantt Chart. So first let’s clarify what a Gantt Chart is, as people’s minds often equate a Gantt Chart with a Waterfall process. Then we'll look at Kanban, and then discuss why the combination of the two is such a killer combination...
Gantt Charts are not Waterfall
Gantt charts are not Waterfall and Waterfall is not a Gantt chart. Activities on a Kanban Board can just as easily be laid out on a Gantt Chart with the added element of time and dependencies.
What is Kanban?
Kanban (which literally means “billboard” or “sign” in Japanese) is a visual work management process that is supported — in some cases — by a visual “Kanban” Board. Since its inception, the concept has been adapted by many methodologies and frameworks, and includes many variations of the original Kanban Board and System.
History of Kanban
In Kanban’s first iteration, Kanban cards were used by Toyota to better manage inventory supply between machines. In traditional manufacturing (which is a “push” system), it’s relatively easy to know when the system is breaking down. Inevitably you see a pile of parts building up somewhere on the factory floor. Kanban was developed to prevent this from happening.
Here's how Kanban worked. Instead of every machine making parts as fast as it could, two carts were put between every machine. On one side were the two incoming carts, and on the other side were the two outgoing carts. Every cart had a "card" in it (hence the name Kanban), which said how many parts it could hold. So once an outgoing cart was full, it got sent to the next station. And once an incoming cart was empty, it got sent back to the previous machine to be filled again.
So obviously, if your incoming cart was empty, you couldn't keep working. But just as important, if your outgoing cart was full (and hadn't been replaced by the returning empty one) you also had to stop working — even if you had a full incoming cart.
This simple approach had several immediate benefits. First of all, it greatly reduced Work in Progress (WIP), and therefore inventory. It automatically adjusted the pace of work to match the slowest step in the process. And it ensured that any mistakes or errors were caught before they had been repeated too many times in an upstream process. In other words, the simple process — two carts with cards in them — made the factory run much more effectively.
Kanban's early application in software development
Software developers that were tired of the flaws in the Waterfall process began to look elsewhere for inspiration. In their search, they discovered Lean manufacturing and its associated principles. In software development, the Lean manufacturing concept of Kanban was adopted and adapted as a way of managing projects that involved knowledge work — to make knowledge work visible. In the case of software development, sticky notes on a Kanban Board replaced Kanban cards in a cart.
How does a basic Kanban Board work?
On a basic Kanban Board, sticky notes are used to signify work and what phase the work is in (e.g., Backlog, Work in Progress, and Completed). There are a number of rules that manage the use of a Kanban Board such as no one person can have more than one (or two if one is blocked) items in WIP at the same time. As another example, once someone completes a task, the sticky note is moved to the right into the next phase and only then can the knowledge worker “pull” another sticky note from a previous step, or the backlog.
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 suddenly they had a number of tasks to get done within an Iteration, but there was no way to manage the tasks, so they ended up working on many tasks at once.
With the use of a Kanban Board, Sprints or Iterations became more manageable. Developers could see where the work was piling up. They could also easily identify what needed to be done next, and only work on one or two tasks at a time vs. multi-tasking across many tasks.
Kanban and other Agile methodologies need to be adapted for hardware development
This simple Kanban system works well for work that always goes through the same steps in a process, such as software development. However, Kanban on its own falls short in more complex processes such as hardware development. Visual work management's early beginning and subsequent evolution in software development was relatively easy because of the unique properties of software development projects. But that’s not the case for hardware.
This previously written series provides more detail on the differences between Software and Hardware development. However in summary, hardware projects differ from software projects in the following ways:
- High variety of project and activity types
- The number and complexity of project dependencies
- Lead times and other forced ‘wait time’ within the processes
- Limited modularity (high impact of change across the design)
- Increased delay and total cost of the average change
- Increased number of development teams and team members working concurrently
- Larger variety of skills and knowledge — more specialists
- The cost of delay of a product launch can be in the millions
So, although implementing traditional Visual Work Management or Kanban (manual or electronic) is usually better than nothing, there is a better way — combining the benefits of Kanban with a Gantt Chart.
The benefits of Kanban and Gantt for Hardware development
As stated above, Gantt Charts are not Waterfall and Waterfall is not a Gantt Chart. Activities on a Kanban Board can just as easily be laid out on a Gantt Chart with the added element of time and dependencies.
In hardware development, being able to visualize these added elements — time and dependencies — makes all the difference. In fact, it's a critical component to managing hardware projects as projects can last years and dependencies are manifold.
For example you can’t test a part until it’s been purchased and received. And if it’s not a standard part, it has to be made by someone. But it can’t be made until it’s been designed, approved, and purchased. The dependencies are almost endless. And many of those steps are done by people with different skills, in different departments.
Hence, we’ve adopted this approach to visual work management in Playbook.
Playbook is Lean and Agile
Playbook combines iterative development, self-organizing teams, and daily meetings (Agile/Scrum) with both long and short-term planning. The benefits to this approach are that it supports principles that are critical to keeping projects moving forward, daily.
- Daily meetings, fast feedback and instant visibility of blockages
- Decentralized planning for self-organizing teams
- Pull vs. Push task management
- Managed capacity loading across teams and projects
- Correct priorities, daily to ensure the project stays on track - or finishes ahead of time
Conclusion
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. It ensures team members are tracking daily, without losing sight of the long term goal — an exceptional product, launched on time, or better yet, ahead of schedule.
----
It’s true. We make some pretty significant claims regarding Playbook’s ability to shorten development cycles using Lean and Agile applied to hardware development. Watch the demo video to understand the two paradigm shifting concepts around what causes late projects and how Playbook solves them.
Related Posts
5 Visual Project Management Software Requirements
Lean Project Management and Kanban
Visual Management Boards
Four Essential Features of a Visual Management Board
2 Essential Features of Visual Management
Visual Management ROI
Guide to Visual Management
Guide to Kanban
