Agile

Kanban: The Mercurial Perspective

To understand Kanban, you must first learn what it is and is not. I covered some of this in What is Kanban?. To sum up that article, there are two different Kanbans – we will call them Lean Kanban and Agile Kanban. Agile Kanban is too often confused with Lean Kanban, although there is no rule that says that you can’t use just Lean Kanban in Agile projects (The Scrum board could be considered a variation of the Lean Kanban board); forgoing the Just In Time Delivery aspect of Agile Kanban.

 Reproduced from What is Kanban?

Agile KanbanLean kanban
Derived From LeanPart of Lean
Defines Just In Time DeliveryComplements or part of Just In Time Manufacturing
Named after Lean kanban, consists of JIT delivery, kanban boards,  process flow controlsConsists of kanban (visual signaling), or a kanban system using signal cards
Method for managing knowledge workSystem for visualizing the status of work
Has a capital “K”Has a lowercase “k”
Uses Work In Progress (WIP) to provide structureMay have cards that say WIP on them

But here today we are going to focus on how you use Agile Kanban and the Just In Time Delivery to your advantage outside of projects. We are going to attempt to look at it from a different perspective and leave out the Kanban board. The Kanban board is really just for tracking the work (You don’t even have to use it if you don’t want to, you probably should though).

The Continous Kanban Loop – The Mercurial Perspective

First, a couple of definitions to help you understand what I am talking about below.

Task (or work): Work that is made up of actions or activities. Completing weekly billing may be a task.

Activity: A single logical work action. Writing an email and sending an email would be two activities. It may form part of a larger task such as gathering information from a client so that you can properly update their address.

Process: Method to complete a task or activity

The Endless Iterating Loop

The Endless Iterating Loop diagram above is something I created using names that I also created. They are not part of any official Agile Kanban in existence (because an official Agile Kanban doesn’t really exist). The idea behind them is to help visualize how your Kanban process might work. Each loop represents a process.

Think of each loop as the stages or phases your work should go through.

  1. Planning: What are you going to work on and how are you going to complete it? What are the highest priority tasks? What makes sense to work on first? Can you clearly identify each activity that needs to be performed as part of the larger task?
  2. Adapting or Coordinating: Do you need help with something? Is there someone you have to work with? Do you need resources to complete your task? What do you need?
  3. Burning: Now you do the work. You take your planning and coordination and you get the task done. You are burning through your tasks to get them done.
  4. Adjusting: This is part of doing the work. Maybe you don’t need to adjust anything, but meetings get missed, things come up, schedules change. You may have to adjust and adapt your coordinating activities. The work you did may also be subject to correction or adjusting.
  5. Evaluating: This is the Continuous Improvement phase. Can you do the task you just did better? Did you learn anything from this task that may help you complete other tasks? How can you make things better in quality or efficiency?

Sometimes things are fairly simple. You have a task with one activity that takes you ten minutes, you may not get highly involved with these stages. You probably don’t need much planning or coordination. I would still suggest you take a minute and evaluate the task. Can you do something to reduce the need for the task? Can you improve your planning or priority of tasks?

Longer duration tasks with several activities may take more planning and coordinating. The larger the task, the longer you should spend evaluating the overall process. How long you spend is up to you and your workplace, but you don’t want to get into a situation where you are spending larger amounts of time evaluating the process than you do performing the required work.

The Real World

You are not likely to be able to work on one large task beginning to end and then move on to the next. If you have a job where you can work on one thing at a time – are they hiring?

In the real world, you are more likely to have several tasks going on at a time. This is where tracking things with the Kanban board can be important (or doing anything to track it, the Kanban board is just a ready-made solution carried over from lean manufacturing).  What you want to create is an endlessly Spinning Wheel of Work.

Spinning Wheel of Work

You don’t want to overload this wheel. You want to keep it running smoothly and at a steady and constant pace (as much as possible). Overloading the wheel with work causes all sorts of problems. Employee mental health is one such major problem and that can spiral into other problems.

From a strictly business perspective, overloading the Spinning Wheel of Work can cause:

1. Quality of work issues

2. Poor planning (quick planning)

3. Skipping/merging phases in the Endless Iterating Loop

4. No advancement or improvement to the process

This is where Work In Progress (WIP) limits come in to play. You try to increase or reduce the flow of work into the wheel to keep the wheel running smoothly.

I can’t tell you how much work you should give to your employees to keep the wheel running smoothly. That depends on the type of work/business and should only be done by someone with experience in the business or area of work. You may not get it right the first time, this should be part of evaluating the process. Were the employees overworked/underworked?

Each task goes through the stages of its process. Tracking where each task is at and which activities remain to be completed.  You can have multiple people working on a wheel, pulling work into the wheel; or it can be a single person juggling multiple tasks. Agile usually suggests we avoid task switching, reality says it will happen so you might as well try to control it. That is what Agile Kanban is good at.

In Conclusion

I hope this different perspective of Kanban, mostly avoiding the Kanban board, helped you to understand how Agile Kanban should work behind the scenes of the Kanban board.

Sources:

Handshake image from Pixabay.com

3 replies »

  1. I’m now not certain tһe place уou aгe getting yoᥙr info,
    Ƅut ɡood topic. І must spend some time studying mսch moгe oг understanding more.
    Thank you for magnificent information I was searching fօr this information for my mission.

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.