KANBAN: A POWERFUL LEAN AND PROJECT MANAGEMENT TOOL

Question: What Powerful Lean Tool:

• Is used in Agile Project Management
• Has been applied to manufacturing, programming, accounting, and many other task-oriented areas
• Can be scaled for use at an organizational, team, project, or individual level
• May be quickly and easily implemented
• Fosters collaboration and communication
• Reveals bottlenecks and leads to ongoing continuous improvement
• Works most effectively in a Pull System that Limits WIP

Answer:  Kanban Boards. 

The CSSBB Primer defines Kanban as a method of material control in a factory.  Kanbans were used as a scheduling tool in the Toyota Production System (TPS) to encourage Just-in-Time (JIT) production and eliminate the waste of overproduction.

Today, the Kanban concept is being applied to many business areas including programming, accounting, order processing, and personal productivity. David Anderson is credited with developing a more expansive Kanban Method for knowledge work. Jim Benson and Tonianne DeMaria Barry have developed a Personal Kanban System. Today, users describe Kanbans as visual representations of both a workflow and the work that is currently moving through it. This allows users to see and correct process roadblocks as they occur – which fosters a culture of continuous improvement.

To get started with Kanban, Start with a Board (or wall, or software program) and Map a Workflow

Kanbans are flexible.  How you decide to set up a Kanban is up to you (and your organization). The main rule: Map a workflow.  You might decide to track the flow of work at a high level, a team level, or an individual level.  You can create a Kanban using a physical board (some places even use entire walls), an Excel spreadsheet, or with software that creates Kanbans for you.

When I created my first Kanban, I used a white board to map a product development workflow from Design through In stock. The first column was Team with a row for each team member.  Cards representing their projects were placed under the appropriate workflow.  While the board did a good job of showing workloads it did not show where projects were in the workflow.   I needed more detail; I broke down each stage into key milestones.  The table below shows the design milestones.  I removed the Team column, updated the Kanban cards to include the name of the team member responsible for the product, and added space for noting start and end dates for each product milestone. I added a “Waiting” row to show projects that were stalled.

DESIGN STAGE
Request In	Design Meeting	Design Brief Final	Being Designed	Design Approved	Design Spec Written	Design Complete
Project F Project A	Project E		Project D	Project C Project B		Project E
Waiting	Project G	Project H

Watch the Work Flow – or Not

Once you’ve set up the board, watch the flow of work. Team members should be responsible for updating the board. We scheduled a weekly Kanban review meeting.  For our products, that was enough.  For projects or tasks that move faster, a daily review might be better. That’s one of the beauties of the Kanban: You decide what’s needed and adjust till you find what’s right. Why watch the flow? To make sure items keep moving forward; when they are stalled you identify the reason, resolve it, and keep the project moving forward.

Focus on Project Flow to Foster Collaboration

During the Kanban review team members report and ask questions.  For the design view shown above, we’d ask:

• Why is Project G in waiting mode? Turned out a required meeting participant was ill and the meeting was postponed till she returned. If that continued beyond the next week, the product team would need to meet.
• Why is Project H waiting?The staff member responsible had been busy and unable to write up the brief. Her notes were complete.  Another team member offered to prepare a draft.
• Why has Project Anot moved when the request was received ahead of all the others? The team member responsible reports that the Project A request was received 36 weeks sooner than needed for production. She was focusing her attention on the other projects first.

The reasons for delays with Project G and Project H were project specific.  The reason for the delay in starting Project A revealed a process issue.

Focus on Project Flow to Foster Communication

The Project A development team was complaining. They understood that within 18 weeks of their design request, they would have an approved design. The team member responsible for overseeing the design thought designs should be requested 18 weeks before they were scheduled to move into the production stage.  Since Project A was not scheduled to move into production for 36 weeks, she saw no reason to take immediate action on the request.

Kanban experts have identified a number of practices and principles to guide Kanban development.  One of the practices is to make policies explicit.  In this case, although there were written guidelines on how much time was needed for a design, the meaning of the guideline was not clear.  When the two groups met to discuss Project A, we learned Development was instituting, for high priority projects, focus group testing that required a finished design. That’s why they had asked for the design “early.” With that clarification, the project quickly moved forward.

Focus on Project Flow to Foster a Culture of Continuous Improvement

To avoid a similar problem in the future, the development and design teams came to a simple solution: There was no need to change the design request timeframe, they simply updated the design request form to specify when a design was needed before the in-production milestone.

Kanban Principles and Practices: How My Board Measured Up

Most Kanban experts identify four principles and six Kanban practices to guide Kanban implementations.  Here’s how my system compared:

Principle or Practice	Y/N	Comments
Principle 1: Start with what you are doing.	Y	We had a solid system to work with. Our goal was to work out kinks.
Principle 2: Pursue incremental, evolutionary change	Y	Experts point out this is less threatening for those who fear change.
Principle 3: Initially respect existing roles and responsibilities.	Y	Teams we worked with appreciated the collaborative approach and discussions.
Principle 4: Encourage leadership at all levels.	Y	During conversations around the board, or follow up sessions, all members of the team contributed suggested solutions.
Practice 1: Visualize the flow of work	Y	This alone was a powerful practice. We got to see work, where it was, and where it was blocked.
Practice 2: Limit Work in Progress (WIP)	N	This was most challenging for us.  See the paragraph below for more details.
Practice 3: Manage Flow	Y	The weekly reviews were critical to keeping things moving.
Practice 4: Make Process Policies Explicit	Y	We already had many written processes. But by addressing delays or confirming when a project stage was “done,” we uncovered areas that needed clarification and training.
Practice 5: Implement Feedback Loops	Y	Weekly reviews and reviewing and updating data on the cards kept us focused on getting the work done.  Product metrics were available through another system.
Practice 6 Improve Collaboratively and Experientially	Y	At each of the stages we viewed, we were able to work collaboratively to identify and test ideas for smoothing the workflow out.

Limit Work in Process

A true Kanban system is a pull system – that means team members pull work as they have capacity – rather than have it pushed on them.  This limits their work in process.  Limiting work in process has been shown to lead to greater focus, efficiency, and productivity.  This is easy to see in some situations:  In a call center where each rep picks up the next call as soon as they are done with the current call; in a coding environment, where a programmer picks up the next prioritized feature on the backlog board; or when a freelance contractor limits their WIP by turning down an assignment.

We did not attempt this in our product development cycle directly.  Projects were pushed into the workflow based on when the customer needed the finished product.  We limited individual WIP by assigning excess work to contractors. To create a truer pull system, we would have had to redefine individual team roles and change how projects or tasks were assigned. While we never got that far, our results were still positive.

For More Information

Kanban methodology and systems have come a long way. Want to see how one works for you or your team or organization? Just Google Kanban for a variety of articles.  If you want to learn more on getting started with a personal Kanban, read Personal Kanban: Mapping Work Navigating Life by Jim Benson and Tonianne DeMaria Barry, © 2011 or visit their website at https://www.personalkanban.com/. For more on the very sophisticated work of David Anderson, go to: https://djaa.com/#.

Share Your Experience

Do you use Kanbans? With Knowledge or service workers? How do you handle WIP limits? Share your insights on BPG’s Linked in User Group:   https://www.linkedin.com/groups/6542782/