This is the third part of our series on Lean project management.
In this post we discuss visual management’s and Kanban's role in Lean and Agile management and why investment in visual management software is critical to your success.The purpose of visual management and Kanban is to make knowledge work visible (just like the parts on the factory floor), so we can see it, react to changes better, and keep the project flowing quickly to completion.
Consider this. If you were to survey the traditional manufacturing floor, how would you know where the system was breaking down? Sometimes there would be flashing lights indicating a fault in the system, but even if there weren't any, you could still tell which machine was having issues by the big pile of parts in front of it.
But when you look around development departments today and a team of knowledge workers, how can you tell where the problems are? Where is the task that is the most critical today? Where is the blockage which is delaying your project today? Where is the one that will delay your project tomorrow? These problems are hidden from view.
Visual management and Kanban was born to solve this problem. Visual management is a practice which has primarily evolved in software development projects (kanban), although forms of it appear in Toyota’s Obeya rooms, and many other forms have appeared in many other places. Its primary goal is to make what people are working on visible to the entire team so it can be better managed.
The most common form of visual management consists of sticky notes (stickies) on a white board or similar. The primary formats include Wall Gantt, Generic Kanban boards, and Process-specific Kanban boards.
A Wall Gantt is characterized by dates or weeks in the columns, resources in the rows, and tasks of any kind on the stickies. A Process-specific Kanban board has steps of a process as columns and the items going through the process on the stickies (e.g., a new software feature undergoing design, coding, unit testing, and integration steps).
In the more advanced cases, there can be any number of different colors, lanes, columns, holding areas, resources, dots, icons, magnets, tag-along stickies, and other aspects that show different information under different conditions. For many reasons, these two formats are used relatively rarely among hardware teams.
More common among hardware teams today is a Generic Kanban board. In this format, tasks of any kind go through a very generic ‘process’ from the backlog to in-process, to done. Sometimes there are planning steps or various other high-level stages, when the process is standard enough for those other steps to be part of it regularly.
Most visual project management software tools available today use Generic Kanban and/or Process-specific Kanban formats.
Before we developed Playbook, we tried each of these different formats of project boards to accelerate projects. Each form was beneficial in some ways and depending on the application, some more beneficial than others. However, each one had significant deficiencies because, simply put, hardware development project management is complicated.
It’s best to use an example to highlight the issues of applying software development methods and tools to hardware development. Let’s start with applying a Process-Specific Kanban board approach to hardware.
Resources in hardware teams typically have a lot of different types of projects to execute simultaneously including new product development, cost reductions, sustaining engineering issues, corrective/preventative actions (CAPAs), and process improvements to name a few. Within each of these, there is a high variety of sub-processes, from mitigating risks, to designing and testing parts, talking to suppliers, etc.
Even if we could put each of these activities through standard a process, it is a different process for each type of item which requires separate boards and makes the work across all of them much more difficult to see.
Also, the 'items' in these processes cannot usually be broken down and processed quickly enough to move them to the next step every couple/few days. To make matters worse, the wait time involved (e.g., procurement time) results in many resources having several in-process tasks at any one time.
As a result, these boards lose the ability to show blockages well, keep daily priorities clear, reduce multi-tasking, and help keep the work flowing.
Ultimately tools and process go hand-in-hand. You need the right tool for the job to support your process. We developed Playbook to support the complex needs of hardware development.
One point of difference is that each task, rather than being square and ‘equal size’ to all of the other tasks, is more of a rectangle - as wide as it is in days that it is expected to be in WIP, and is as tall as the number of hours needed by the resource each day. These two extra dimensions make a world of difference in visual management.
We get all of the benefits of a Kanban board (visibility & limited wip) and a lot more -- expected completion dates, resource utilization- Not to mention live-auto-prioritization of the backlog.
Stay tuned for part 4 where we look deeper into the visibility and manageability of resource queues…
Do you know the number one reason behind project delays? It's not what you think. Watch this 9-minute video to find out.
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Lean project management resource management
Lean project management Pull vs. push
Lean project management task management
Lean project management and shared project buffers
Lean project management and decentralized planning
Daily stand-up meetings
Guide to Kanban
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