Manage Productivity the Agile Way (Personal, Team & Project Kanban)

by Evan Leybourn on      6 minutes read

While there are many popular processes for personal productivity, GTD & Inbox Zero immediately spring to mind, neither of these scales well to manage team or project productivity. Part of the Agile toolbox, Kanban is a workflow & workload management method to improve the productivity of individuals (sometimes called personal Kanban), teams and projects. At its core, Kanban provides Just In Time (JIT) visualisation, scheduling & control mechanisms to track tasks through their lifecycle.

Background

The original concepts of Kanban were developed in the 40's and 50's by Taiichi Onho at Toyota as a mechanism to control Just In Time (JIT) production and manufacturing processes. Kanban, which approximately translates as "signboard", can be described as a "visual process management system that tells what to produce, when to produce it, and how much to produce"

At it's simplest, each task (or card) on a Kanban board passes through a formal workflow of 3 states (visualised as columns on the Kanban board); Todo, Doing & Done. When there is available capacity in any state, it will "pull" any "ready" tasks from the preceding state. The visualisation component, or cards, of a Kanban helps identify when a task is ready, where there is spare capacity and if their are any bottlenecks or impediments. Of course, being Agile, these cards and processes are completely visible to all participants including the Customer. Example Kanban Board

Todo Doing (WIP 3)Testing (WIP 2) Done
In Progress Ready In Progress
Expedite (WIP+1)
☐
☐
☐
☐
☐
☐
☐
...		☐
☐		☐☐
☐		☑
☑
...

Each card is placed on the Card Wall, which is divided into multiple labelled columns each representing a single Kanban state. Activity columns are then divided in half, the 1st half being "in progress" and the 2nd half being "ready". The Todo (sometimes called the Backlog or Waiting) column is the complete prioritised list of outstanding work, and should be continuously updated as tasks are completed, added or reprioritised. Remember the 3 keys to a good Backlog - Prioritize, Refine, and Reduce.

Example Workflows

Teams and projects may have more complex workflows and will define the specific states that make up the lifecycle of their Tasks (the Kanban). These can be a simple or complex as required, such as the following workflow for a software engineering project;

  • Backlog – Tasks that are ready to be worked on. Based on the logical sequencing of tasks and agreed prioritisation, the project team members select the next task to work on and promote this to the Design state.
  • Design - Basic tasks that require specialised BA or SA design work before being passed to the developer. Once designed the task is promoted to the Doing state.
  • Development – Tasks that are actively being worked on by a team member. This may include software development, writing unit tests, writing user documentation and defect resolution. Once the task has been completed it is promoted to the QA state.
  • QA – Tasks that are functionally complete, but undergoing validation. In the case of software artifacts these should be promoted from the development environment to the test environment. Testing can include integration, functional and UAT testing and is generally performed by the specialist testing resources. If a test fails the tasks is demoted back to In Progress, otherwise it is promoted to Done.
  • Done – Tasks that are complete and ready to be provided to the customer. For iteration based Work, at the end of an iteration, done tasks (and their user stories) are presented to the product owner for review and deployment. Tasks that are “Not Done” may be rolled into a new user story, accrued as technical debt, or it may be decided that they are no longer required and are removed. Different teams, projects and organisations may have different definitions of Done such as;
    • code has been produced, meets development standards, and has been checked in and run against current version in source control,
    • unit tests written and passed,
    • system tested and passed,
    • builds without errors for deployment, and
    • relevant documentation, including diagrams have been produced or updated and communicated.
  • Blocked (optional) - Tasks that have upstream or downstream dependencies external to the project team that are preventing progress. These impediments are moved to this holding state to highlight these issues to the customer and management for escalation and resolution. Once unblocked, tasks are promoted back to the In Progress state.

I've even seen personal workflow states such as; Research -> Reinforce -> Evaluating -> Blogging.

Managing Bottlenecks and Blocked Tasks

To identify bottlenecks and process limitations, each workflow state (or column) should have a limit (called a WIP or Work In Progress limit) to the number of "in progress" & "ready" tasks. For teams, the sum of all WIP limits should be no more than your total team size+1 and the WIP limit for each column should be close to the number of resources in any specific role. Smaller WIP limits tend towards faster completion, but can be changed to improve bottlenecks or staff utilisation. For example;

  • Personal Kanban: You should be keeping context switching to a minimum & we humans have limited attention spans, so your Doing column should have a WIP limit under 5.
  • Team/Project Kanban: You have 2 members assigned as testers, so your QA column should have a WIP limit of 2.
  • Team/Project Kanban: You have 2 members assigned as testers working on the same Card, so your QA column should have a WIP limit of 1.

In conjunction with monitoring flow, the WIP limit acts as a control mechanism within the system, forcing team members to collaborate & change role (e.g. from Development to QA) to prevent or resolve bottlenecks. The Kanban board provides real time & clear feedback, for example when all the cards in a state are "ready" to move on, but the following state is at WIP capacity there is an obvious bottleneck that needs to be resolved. This visualisation and control of workflow also acts as direct stimuli for continuous & incremental improvement.

But What About Urgent Tasks!

Finally, formal Kanban provides a single "expedite" track, at the top of the board, for urgent Requirements and Tasks. There can only ever be one card at a time in this track and it is given the highest priority, above all other Cards. It is recommended that, if possible, team members finish their current Cards before moving onto the expedited Card.

Let me finish this section by giving you Toyota's original 6 rules for Kanban.

  1. Do not send defective products to the subsequent process
  2. The subsequent process comes to withdraw only what is needed
  3. Produce only the exact quantity withdrawn by the subsequent process
  4. Level the production
  5. Kanban is a means to fine tuning
  6. Stabilize and rationalize the process

Links

http://www.personalkanban.com/
http://www.zsoltfabok.com/blog/2011/01/visualize-wf-dod/
http://en.wikipedia.org/wiki/Personal_Kanban

Attribution

Image is CC BY NC - Blambarde