How to effectively combine different (project and non-project) activities in Kanban?

Question

In our company, we're currently trying to get started with Kanban. When discussing about how to handle the different work items / user stories / tasks, this question came up:

How do you effectively handle different activities in Kanban?

For example, I don't have to work for only one project. There are also other tasks I have to do (participating in special work-group meetings, client training some days, etc.). All members of our team are still involved in other activities that are completely independent of the actual project we're working on.

As Kanban is an evolutionary approach, we think there should be a "smooth" migration, meaning that we don't want to force all the team members to stop participating in other working groups.

Our possible approaches are:

• Include other activities as tasks on the Kanban board.

  Problem: most of the other activities, like training or meetings, are fixed in time. When other work isn't finished, starting those "non-project" activities would break the Kanban Limit, but allowing this, would not require us to include them in our Kanban process.

• Ignore non-project activities in the Kanban process.

  Hopefully there's a better approach.

• Create a second board for those other activities.

  Problem: How do you control the WIP-limits?

How can we handle this these different activities with Kanban?

Answer 1

Kanban: Not a Day Planner

The Kanban framework is not a day planner. You are not supposed to add all your routine chores and obligations to the Kanban board. Kanban is a pull-queue system, and columns on the board ought to represent process queues.

Cards May Contain Task Details

An individual kanban (the card itself) may contain additional details such as sub-tasks, identify task performers, or other information necessary to determine when a card is ready to be pulled into the next queue.

However, a card is not a calendar item for your day planner. It shouldn't contain anything not related to the user story on the card. For example, mentioning that you aren't currently working on the card because you have a dental appointment is not appropriate data to store on the card.

Outside Influences Affect Flow and Cycle Time

Even if you have a matrixed organization or multiple concurrent projects, Kanban requires no explicit changes—except possibly reducing your work-in-progress limits to reflect actual project capacity. Cards are pulled from one queue to the next when they are ready.

If other projects reduce the capacity of the project, increase cycle time, or disrupt flow, then the Kanban framework will detect that and enable your team to make those issues visible. Once the issues are made visible, Kanban provides you with continuous opportunities for kaizen. Armed with this information, you can choose to reduce waste and improve flow, but that's entirely up to the project team.

Answer 2

Great question.

Modelling your work with a Kanban system helps you see what you are spending all your time on and whether or not it provides value.

If you are working on multiple projects then giving each project it's own swim lane or board will help you visualise how your capacity is spread across them.

In our team we gave each project its own swimlane and in doing so realised we were working on way too many projects!

As for the non project work, you could as you suggest ignore this, treat it as background noise and look for changes in the cycle time on your project work to look for signs of things outside the project impacting in the project work.

The drawback with this approach, of keeping this non project work implicit, is you have no visibility of how much of your team's capacity they are really taking up.

You might see your cycle times increase and infer that it is because half your team is off doing, to use your example, client training.

To continue with the example of client training, if you called out client training as an explicit demand placed on your team you could then make it clear that this has an impact on the capacity available for project work.

Knowing what this impact is will help you throttle how much project work you pull in and so not over commit yourself.

One option would be, as you suggest, to put this non project work on a separate board. The advantage of this is you can have columns that fit with whatever states this work goes through if it differs from the states your project work goes through.

An alternative would be to keep them on the same board but give the cards a different colour. Then you could see at a glance how much project work you have in progress and how much competing non project work you have.

You could have a policy that allows, for example, '6 pieces of project work in progress and 3 pieces of non project work'

Then you know if you are out of balance between how much project work and non project work you have in flight.

If I were in your position I would experiment. Come up with a way of visualising the non project work in relation to the project work, for example as cards of a different colour on the same board, limit how many of these are allowed to be in progress at any one time and see how you get on.

If that doesn't work out for you, inspect and adapt, and continue until you have a way of modelling the demand placed on your team and your team's capability to fulfil that demand. The Kanban system will give you the means to balance the two.

Answer 3

As for myself it is a known dilemma and in our company we took approach in merging utility/recurring tasks in our main Kanban process pipeline where we have two separate rows. One is for the main flow of the items and the second one is for recurring small tasks (it does not counterfeit with Kanban itself, it is just a two layer process). The WIP limits are calculated per column for both rows.

Such board example using Eylean board tool for Kanban

Yet, as CodeGnome said, it is not a day planner so you should add only tasks which are related to the production and they have final value for your goals. Kanban is strongly against the waste, so you should not litter on your board with such tasks as "Meeting" or similar. Try keeping those away. If you are doing Kanban, you should do it on your production, not your daily routines.

Answer 4

Don't overcomplicate your Kanban.

How to start

Pick the right approach and stick to it. There are two approaches with Kanban introduction:

• visualise what you are doing at the moment
• visualise where you would like to be

Let's assume you would like introduce validation in your process. With the first approach you improve your organisation by doing baby steps, but there is a good chance that you won't have validation in your process, because your the journey took you somewhere else. With the second approach you'll have it, but you'll miss the other opportunities. Based on my experience the second approach needs more discipline and knowledge about the Kanban method and the whole organisation (I'm not talking about a single team here, but the whole deal).

What is on your board

"One board rule them all..." You'll need only one board, and it should reflect what valuable you are doing at the moment. If the task you are working on adds value then it must be on the board. If you have only one item there and the rest are non-value adding tasks, you are doing something wrong, but this will reflect in your lead time and throughput.

The problem with non-value adding activities is that they provide the false believe that you are actually doing something useful. It may happen that one feels that way, but the customer might have a different opinion about it. However, not all non-value adding activities are bad. For example, an effective planning meeting can have a good effect on the lead time or/and the throughput.

Two parallel, loosely coupled boards are hard to maintain, and doesn't make too much sense either. Which one is more important? If one of them, why we need a less important board? So, have only one board. Of course you can have a chain of boards, where a board visualises a significant part of the organisation.