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!
- 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:
- Limit Work
- Measure and Optimize
- 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.
Description and Benefits
|Measure and Optimize||
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.