What is Kanban? (and why should a PM Care?)

Kanban (literally signboard or signal card in Japanese) is a  rapidly growing approach for managing IT activities as well as business/ operational processes.  Originally developed for Toyota in support of just-in-time/Lean manufacturing, Kanban has been repurposed by the IT industry where it is being closely linked with Agile/Scrum to create a hybrid that is sometimes called Scrumban (we will see if it becomes a generally accepted term).

For me, a simple way of thinking about what Kanban is and where it fits into the PM-world is to consider Kanban more as a mechanism for managing and improving the flow of work through a process and less as a defined set of steps for executing the work.  Agile methodologies like Scrum or XP are more robust in specifying how the work should be executed.  When combined together, Kanban can “supplement” the workflow element of Agile.

Kanban = Workflow  and  Scrum = Approach

 

So What is Kanban?

Kanban is a “pull” and work-in-progress (WIP) limited system – this means that you “grab” the next unit of work rather than having the next unit assigned to you and you stop pulling when you reach your defined capacity.  As work is completed, it becomes available to the next step in the process. It is a deceptively simple tool that is very flexible and can be used for managing virtually any process – from IT application development to marketing campaign management to quarterly accounting close to helping your kid’s stay on top of their homework!

The Board

At the core of Kanban is the “Board”.  There are three key features to a Kanban Board:

• Work Steps/Value Streams are identified at the top. Work moves from left to right – in this case from a “backlog” of features through to “done”.  The nature of the work that needs to be performed defines the number and nature of the steps. We can also add or change value creation steps as needed.  In this example, we would likely want to add in User Acceptance Testing after Development to assure that the expected business value of the card was delivered.

• Work Capacity is the amount of work that a given value creation step can support – typically driven by the resources available.  In this case we have 4 units of work in Backlog, 2 in Design, etc.  These numbers cannot be exceeded without impacting efficiency and productivity in the process – and this situation is visually apparent when 4 cards are suddenly in the Design Phase.

• Kanban Cards describe the work that needs to be done by the overall process. These cards also indicate priority – the top card is highest priority.  In some environments, the cards can be in different colors that can indicate things like:
  • Class-of-Service.  Examples:  emergency, as time permits, etc.
  • Business Functional Area. Examples: Accounting, Marketing, Sales, etc.
  • Nature of the Work.  Examples: New report, bug fix, etc.

Four Key Practices.

Depending on who you talk to, Kanban encompasses four to six key practices that were initially defined by David Anderson in 2003.  I prefer to keep it simple and use just four:

1. Visualize
2. Limit Work
3. Measure and Optimize
4. Explicit Policies

In addition to these four practices, some people include “Feedback Loops” and “Improve Collaboratively” – both of which I consider to be part of Measure and Optimize.

Key Practices	Description and Benefits	Typical Tools
Visualize	Key to the success of Kanban – a board that all stakeholders can easily see/reference Definition of the agreed-to process for executing work and delivering business value (i.e., “value stream”) Visual representation of all work – “if it’s not on the Board, it doesn’t exist” Visual representation of business priorities	White board Flip Charts Blue Painters Tape Kanban Software Post-its in different colors
Limit Work	The amount of work/capacity of the people assigned to a given value step Set based on “best guess” and adjusted using metrics  (see below) Critical to overall smooth operation of the processes Stops stakeholders from overloading and stressing out staff Improves throughput and productivity – keeps people focused on what’s really important Empowers staff – gives them to power to say “Yes” (as well as “No”)	A number written on the Board Coaching or Lessons Learnt sessions with core staff (people executing the steps as well as the owner of the backlog)
Measure and Optimize	Tracking of “cards” as they move through the system (through-put) Examples of common measurements: Cards in the Backlog Cards added to Backlog Cards added to Key Workflow Steps Number of Cards Done this week Cards “Blocked” or Awaiting Decisions Cards Cancelled Card Aging Card Velocity Cumulative Flow Due Date Performance Regular process review/improvement sessions Spreadsheets Kanban Software Root Cause Analysis	Spreadsheets Kanban Software Root Cause Analysis
Explicit Policies	Rules associated with the workflow Typical policies can include: Roles and Responsibilities Request Process Description Kanban Operations Description Detailed “Step”/Workflow Description Prioritization Process Reporting Process Metrics Card Creation/Card Colors Emergency Requests Setting/Resetting Capacity Feedback Loop	Operations Guide Product Owners Guide Communications Plan

Roles in Kanban

Remember, Kanban is more a workflow management and improvement tool rather than a methodology.  There are no defined roles, but that said, all environments using Kanban need at least three roles:

• Card Creator.  Individuals who identify what work needs to be done by the system,
• Prioritizer.  Someone/some group/etc.  who has the authority to establish and reestablish priorities (ie., the order of the cards on the Board).  In most of the environments I work in, a “Product Owner” is in this role.
• Executer.  A person or group of people who do the work defined on a Kanban Card.

Beyond these roles, it’s the “Explicit Policies” and any associated methodology (e.g., Scrum) that determines who does what.

Why Should a Project Manager Care?

From my experience, Kanban is proving a fantastic tool for addressing two of Project Managers trickiest challenges:

• Running projects in an Agile/Scrum environment
• Enabling the organizational change that is part of most projects

Though this will be a subject of an upcoming blog, fundamentally Kanban can provide just enough structure to help make Agile projects more manageable and successful.  It also provides a very light-weight workflow process that enables organizational change associated with project rollouts while at the same time being easy to understand and explain to the IT and business stakeholders.

For pragmatic project and change management tips and tricks, check out FitforProjects
downloads section on www.FitforProjects.com.