If you are using Kanban within Scrum or another Agile framework, you may not need to worry much about this. The meetings used as part of those frameworks should work perfectly fine. This is more meant to be a suggested guide of meeting types if you are embracing Kanban within your existing non-Agile (and possibly non-project) process.

There should be three types of meetings as part of a long-standing/long-term Kanban flow. A Prioritization Meeting, a Daily Stand-up, and a Retrospective.

Now, these meetings may not be needed in every scenario or in every office in the world. You may have a prioritization process and not need to hold discussions on it, you may find that you can do perfectly well with a weekly team meeting instead of a daily one. This really is meant to get you thinking about things you should be considering if you embrace Kanban or if you are having issues getting Kanban to work.

*Check out the free Kanban CFD template for Excel

The Daily Stand-up

If you are familiar with Agile, you already know this meeting. In Scrum, it is called the Daily Scrum.

In Kanban, these meetings are a little different. Ideally, you have worked hard to make Kanban very visual. People are working on their tasks, they are updating whatever visual system that was chosen to best portray your particular processes and flows.

There are no “Three Questions” and not everyone really even needs to speak. One should be able to see by looking at the visual system what is moving forward and where the tasks are at. For added excitement, you can certainly celebrate the pulling forward of the tasks. Your main purpose though is to investigate any blockers. Do the other stuff if you have time.

You want a leader there, a project manager or a manager, or someone with the capability to investigate blockers and remove impediments.  I don’t care what you call that person, Kanban doesn’t care either (Kanban isn’t Scrum, it defines no roles or titles except that which already exists). That manager needs to know about any blockers. They need to know what is going wrong and what is holding up work from moving forward.

Hopefully, you have a Cumulative Flow Diagram (CFD) prepared, or some other visual way to help identify any blockers. It may help because you want to work on the worst items first. The items causing the most problems should get the most attention in this meeting.

Books and Educational Material on Kanban

This is rather counter to a lot of how daily stand-ups are run in other Agile frameworks, and there is a reason for that – Kanban is about the long-term haul and keeping things running smoothly. If you have ever worked in Lean Six Sigma manufacturing environment, then you can relate to this. Things going out of statistical bounds, whether for the good or the bad is not a smooth operation. They both could be signs of very bad things. You need to put those fires out and get things smooth again. Kanban is also meant to deal with larger groups of people and more work, you aren’t likely to be able to cover all the items on the board so you need to focus on the most important and the most important ones are the ones in danger of not getting done.

Try to still keep it within the 15-minute time frame, and for really serious issues don’t plan to fix them in this meeting. Just plan to plan. Arrange a time to talk about really serious issues later, or arrange who is going to investigate an issue and get back to the group. Get a good idea of how you plan to move forward with planning how you are going to tackle this issue.

In this meeting, you also want updates on issues. You had a bottleneck yesterday and you assigned someone to look into it. Did they learn anything? Do they need assistance? Did they find the problem?

Prioritization Meeting

The purpose of the prioritization meeting is to fill the Kanban queue up and make it obvious what needs to be done next.

This meeting may or may not include any of the people who do the actual work tasks. It may be beneficial to include them for input, but that may also depend on the complexity of the particular flow. You may find, you don’t even need this meeting if you have a standard process in place. Kanban doesn’t care if you have this meeting or not as long as you have some way to choose priority and items to include in a queue or backlog of work so that the people doing the work know what is expected of them. Transparency is key, and what is up next needs to be transparent.

You really only need to ask two questions:

• What items need to be included in the Kanban flow?
• What items in a Kanban flow are the most important?

In Scrum, this may fall to the Product Owner to worry about.  In a general work environment, this may be for a manager or group of managers. If you have been relying on a first in first out sort of basis, you can keep that or you can change it. Kanban doesn’t care. Kanban only cares that this is transparent and everyone knows what is expected of them.

I bring up the prioritization meeting to get you thinking about prioritizing the backlog of work items. Kanban can be used in non-project scenarios with a continuous flow of work. It may be that your old method of doing work was causing some items to fall through the cracks. Formalize a meeting to discuss those issues to help put a stop to that.

It may be that people never know what to work on next and a manager needs to decide every single time what is up next. Perhaps holding a small half-hour meeting every week to prepare for the upcoming week could alleviate those problems.

You don’t really want to be in a situation where a person is just guessing at what needs to be done. You don’t want them to come and ask someone all the time because no one has planned ahead.  You want them to know.

The prioritization meeting is about planning ahead and making those plans visible to everyone. That way they can look at the plan and grab the work they need to work on. They feel more comfortable, the manager is less stressed, the transition of tasks is smoother.

The benefits far outweigh the small amount of time spent planning ahead a little bit. You define a time-period, say once a week, and you plan for the upcoming time-period what needs to be worked on and in what order that work should be done.

Who participates in this meeting? Kanban doesn’t care. It should probably be someone with the authority to assign work and is able to understand the work being done.

Retrospective Meeting

There are really two major parts to this:

• Self-Reflection: Individuals reflect and ask themselves how they can improve upon the work they just completed
• Collaboration: People collaborate and discuss with each other during a retrospective meeting ways that they can improve, what can be improved, and how are they going to improve it

Kanban has no end or no iteration. When are you supposed to hold a retrospective? Is it facetious to say all the time because you should always be thinking about improving quality? Probably. It also isn’t very practical.

That being said, of the three meetings, this one is the most important to have and the most important to adhere to on a very strict schedule. This is the continuous improvement, the kaizen, part of Kanban. This is how you get better, or at least the first step (taking action is how you actually get better).

The work is still ongoing, but you want to define a time period; a week or two – probably not much longer than that. Set up a recurring time period with a time-box that works for you (IBQMI suggests an hour-long time-box every week – that may not be practical in all situations).

After every task transition, the person or people who were responsible for the work should reflect back. They should ask themselves how they can improve. They should take notes and document what went well, what didn’t, and how can they get better. If they found things that may benefit others, they could bring them up at this retrospective.

Quality issues, defects, upcoming changes – these are some of the things that should be discussed in a retrospective. The core idea though is the same here as it is with Scrum and all other Agile frameworks – to reflect on the past work. To create a safe environment where people are not criticized for their mistakes, but made to recognize them and encouraged to improve.

Kanban/Scrum Board Tool Set

Reflection

Hopefully, this got you at least thinking about Kanban a little more seriously. I believe Kanban is underutilized for the huge value it can bring. I would like to see it used more and taken as seriously as it’s manufacturing counterpart Just in Time Manufacturing. It is more than just a board (I discuss that here: What is Kanban?), and it is much more powerful than I think it is given credit for. You don’t need Scrum, you don’t need other Agile frameworks. Kanban can do it, you just have to put in the work.

If you are feeling up to it, try out my new Kanban Knowledge Test.

Sources

Images from Pexels.com

IBQMI (2017). Certified Kanban Coach Training Material