In traditional project management approaches, the leader has the tools to see the entire project. Often, a spreadsheet is the tool used. Sometimes, an MS Project Gantt chart is used. Other times, MS PowerPoint slides that report progress show the view.

The common theme on these approaches is that the file is on a computer accessible by the leader only and not the team.

Using Lean visual management can be easily done using Kanban. There are other ways too. Kanban makes the current situation of the team’s progress visible to all.

When the entire team can see who owns each work item that is in process (not in backlog or done), then it becomes easy to see when there are problems.

All drivers can see the traffic jam on the LA freeway. All can start looking for workarounds. Similarly the visual management mechanism you choose, we use Kanban, helps all team members see what is going on. During the daily synchronization meeting, the team looks for bottle necks. Then following Goldratt’s Theory of Constraints, they can address the slowest bottleneck of them all first. When that one is improved, they can move on to the next bottle neck.

Everybody can offer ideas when everyone can see the problem on a visual management system. When the progress is only visible to one person who can access the file format that contains the progress status, then only that person’s head can help solve the situation. If all the team members get this much feedback:

  • See the problem

  • Be involved in the development of an intended solution

  • See the solution experiment (the impact of the attempt to solve it)

  • See the consequences - good if the problem was solved, and the next experiment if not

Then you have both a learning experience development system and a problem-solving training school for all the team members involved. This spreads your problem solving expertise across more people as the data educates them on what works best and what does not work in various real-world circumstances. This learn-by-doing grows the entire team.

The team may see that many Kanban cards have piled up waiting for the 'Test' step, a quality assurance check against a particular checklist of test cases. They may need to stop pulling upstream work item cards and more of them pull cards in the Test step to help those work items cards get completed. You may need to reinforce the Lean one-piece flow principle with the team, and that we get zero credit for incomplete work items. If using earned value, the 0/100 technique applies. As you coach people away from sub optimization at the individual level and towards optimizing for entire-team throughput, your cycle times will increase even if your individual team member utilization is not as high. This is okay in Lean-Agile. You will not end up with slackers because they can pull another work item card. You will end up increasing your cycle time for work items, and you will have more completed, working courseware to show earlier in the timeline than in a comparable waterfall approach.

The Lean-Agile coach may ask why Bhodi pulled 15 work item cards into the WIP lane, showing his ownership when, he as one person, can only realistically work on 1–2 work items at a time. Then you have a team teaching moment for all to realize that Lean pull is different, and that they are expected to leave most work items in the buffer queue until they are actually hands-on working on a particular work item.

The lead may notice that Dave’s cards sit in process step columns longer than expected. He can ask clarifying questions. If it turns out that Dave cannot keep up with the rest of the team, Dave may have to be replaced.


Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview