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

Kanban_WhiteboardKanban (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:Simple_Kanban_Board-small_v1

  • 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

  • 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:

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


Are Project Managers Needed in an Agile World?

I’ve been helping companies inProject_Management_Image_17775705_stroduce and adopt Lean and Agile/Scrum approaches in both IT and business departments for the last decade – and the question that continues comes up is: “now that we’re implementing a Scrum-based development approach, do we still need all these PMs and a separate PMO organization?”

The answer is easy: the ScrumAlliance says no and PMI says yes.  I’ve found (not too surprisingly) that the answer a person chooses usually depends on their personal experiences, history, current role and responsibilities.  My answer is that both PMI and ScrumAlliance are right – up to a point.  Before I discuss these points of view, let’s start with definitions:

A Project

A project is a complex set of objectives, work, and deliverables that lead to the accomplishment of a pre-stated goal.  This involves a well-defined start and end, utilizing various resources including multiple people who are both directly and indirectly involved in achieving the project objectives.  Objectives are achieved through the execution of a series of tasks or activities.

A Project Manager

There are many definitions for what a project manager is, but most would agree that they have responsibility for:

  • Assuring the overall success of “a project” from start to finish – from initial planning (sometime as early as the business case and budgeting) through to completion of the project (which may or may not include “end-user adoption”).
  • Project Plan development and monitoring/maintenance
  • Monitoring staff and the tasks they are responsible for.
  • Budget management.
  • Monitoring and managing risks and issues.
  • Assuring smooth communications and collaboration – within the Team and across the organization.

ScrumAlliance: No. Project Managers are not needed

Based on my personal experiences, I think most Agile/Scrum practitioners do not believe there really is a need for a role of “project manager”.  And officially, the ScrumAlliance does not have a role for a “project manager”.  There are two roles, ScrumMaster and Product Owner, whose responsibilities overlap with some of Project Managers.

ScrumMaster Product Owner
Assuring Project Success Partial – assures a Team is functional and productive, but not “overall success” Yes –responsible for defining the work, it’s priority, and when a complete set of work is ready for release to the end customer
Project Planning and Status Monitoring Partial – “manage” the product backlog and burn-down charts.  They facilitate Sprint backlog planning and review meetings. Partial – product backlog prioritization, story identification
Monitoring Staff No – the Team decides what and how to work on tasks/stories and how to organize itself No
Budget Management No – the concept of a budget in the traditional sense does not exist No
Managing Risks Partial – removing “blockers” to the Team completing stories – but does not extend outside the Team No
Assuring Communications Partial –  facilitates the daily standup/scrum meetings Partial – facilitates scrum planning meeting

PMI: Yes. Project Managers are needed

Actually, though PMI believes that PMs are important, it is very difficult to get a clear read from PMI on exactly what they view the specific role of a “Project Manager” is on Agile/Scrum-based projects.  PMI’s main focus is educating people in Agile techniques – as they state “Project managers who are using Agile practices in their projects can broaden their influence and impact in their respective organizations and enhance their careers with the Agile certification, especially those professionals already holding the PMP®”.

The Role of PMs in a Lean and Agile Environment

Let me start off by saying that much of my career has been in the classic project management/command-and-control world.  But my transformation into a believer and strong proponent of Lean/Agile/Scrum/Kanban happened pretty rapidly because it was amazingly obvious that Agile improves the effectiveness of most projects more effectively than any other single approach I have ever experienced (anyone remember Method/1, Upper and Lower CASE tools, etc.)

My view is that in many smaller, development-oriented organizations (or stand-alone teams), there is not a need for the Project Management role.  I’ve also found this to be true in more mature Agile-oriented organizations where Agile has become the defacto approach for running projects – including non-developmental activities like operations, support, and planning.

As shown in the chart below, I believe that most of the traditional PM role can (over time) be handled by someone like a Development Manager combined with a Product and ScrumMaster.

SMALL DEVELOPMENT ENVIRONMENTS ScrumMaster Product Owner Development Manager
Assuring Project Success Assures Team success Assures Product success Assures that resources are available
Project Planning and Status Monitoring Facilitates Sprint backlog planning, story grooming, and burn down tracking Overall product backlog, definition of themes and Epics
Monitoring Staff N/A N/A Staff HR
Budget Management N/A Coordinates with the Development Manager Prepares and manages the development budget
Managing Risks Helps remove Sprint blockers
Assuring Communications Daily standups, Sprint Planning Meetings, and Sprint Reviews Sprint Planning Meetings, and Sprint Reviews

There are two major challenges with this view: (1) Large Projects and (2) Hybrid Projects.

Large Projects. As organizations and projects get bigger – or as projects become programs and span multiple Geos, cross organizational boundaries, or have distributed development teams, there is a need for a role that can handle cross-team task coordination, budgets, overall program status, risk management, communications, process change, and roll-out planning.

This is a role that FitforProjects often plays on projects and I don’t have a problem with calling this person a Project Manager even though overall accountability for success may reside in another role.  What’s interesting about this approach to project management is that the role is more “Project Enabler” than “Manager” – and in many ways requires better communication, organizational development, and facilitator/coaching skills than Project Mangers typically have.

Hybrid Projects.  Many organizations, especially those starting the transition to Agile, end up with an unplanned, “hybrid” structure where some programs are run Agile and others are not.  In other cases, parts of a project might use Agile and other parts don’t.  This typically creates a very challenging project environment where traditional Project Managers have accountability for budgets as well as the overall success of a project or program – while at the same time Agile Teams and their Product Owners feel that have are responsible for what gets done when.

Conculsion: Avoid inadvertently creating a dysfunctional project ecosystem

Implementing an Agile development approach takes more effort than just sending staff to Scrum, ScrumMaster, Product Owner, and PMI training.  You must also explicitly address how to handle project “management” and accountability.  If you’re ambiguous about roles and responsibilities, don’t be surprised if Agile doesn’t quite work out the way you expected.

Agile Marketing Campaign Development

For the past couple of years FitforProjects has been involved in the management of projects where we are helping companies select and deploy marketing technologies – these tools are helping companies increase their marketing agility as they move to online and social media driven business models.  Interestingly, we are using Agile approaches in a non-traditional way to manage the process of developing requirements, selecting software, and rolling out the technologies across the globe.

But something interesting is also happening on the downstream/adoption-side of these projects: the Marketing Teams continue to use waterfall-based project management to plan and execute campaigns, but the product development teams are using Agile/Scrum to rapidly deploy new products and services.  This is causing process “traffic jams” because change is happening too fast for the marketeers to keep up.  As a consequence, the business is losing revenue and mistrust and tension grows between Marketing and Product Development.

Recently, during a brainstorming session, I suggested that using Agile and Scrum might be effective in radically improving Marketing’s internal business operations and creating a more responsive and lean marketing campaign process.  It turns out that applying Agile to the marketing campaign process is remarkably similar to using Agile on a classic IT project; you have most of the core “requirements” to create a Srum-based project including:

  • (Semi) Dedicated Teams
  • Fixed Deadlines
  • Well understood process with a set of defined tasks including campaign design, images, text content, localization, hiring vendors, etc. that lend themselves to being turned into Agile “stories”
  • Close collaboration between “campaign” developers and customers
  • A campaign that is running is more important than a perfectly designed campaign that never gets off the ground

From a benefits perspective, Agile delivers:

  • Better quality
  • Better buy-in and more participation
  • Better visibility into the progress of campaign development
  • Faster campaign development and deployment

As my FitforProjects colleagues and I have been continually suggesting – Agile is not just for IT.  It’s a core foundational element in your “pragmatic project management” toolkit and should be part of virtually every business project.  I really encourage you to consider piloting Agile on your next business project – I think you will see benefits almost immediately.