Kanban is a compilation of two Japanese words: ‘kan’ – a sign and ‘ban’ – aboard. The word kanban has become the name of the entire production control method. On a production level, this word was first used in 1947 by Taiichi Ōno, a pioneer of Lean production. The goal of the Kanban system was to produce only what is needed when it is needed and in the amount needed.
Kanban has a strong lean background and is connected with the concept of just-in-time manufacturing. The key assumption of both is to make the production process more efficient, not to cause waste, and to stay ahead of the competition. Toyota was the first to use this latter concept and, even today, it is considered a precursor to the Lean approach.
According to the Kanban system: If the last component of the product was used, then the production of such a component was started. No earlier. This allowed them to avoid losses in the form of storage.
In a few words, Kanban says no to:
- Absences
- Stocks
- Delays
- Queues
- Inactivity
- Unnecessary activities and controls
- Unnecessary movements
To summarize: Only activities that add value to the product are welcome. The concept is similar to Scrum.
Get Free Product Owner Guide Ebook
Drive Your Product to Success – Free Guide for Digital Product Owners
Even the best team can’t deliver a successful product without proper guidance. If you own digital consulting service, our Ebook will be a perfect resource for mastering the fundamentals of successful product delivery.
Are there any roles in the process? If so, what is your role?
According to one of the basics of Kanban, you should ‘start with what you are doing now – which means, among other things, that you do not need to create special roles to start using Kanban.
Yet, as you begin to use Kanban, you may find that some roles will develop on their own over time. Kanban describes two main roles: Service Delivery Manager and Service Request Manager. And, of course, a well-organized team. Those roles are similar to the ones described in Scrum: Scrum Master and Product Owner.
What you should remember is that the role of Service Request Manager may be a rotating one. It does not have to be you who will cover the duties described below. It can also be an experienced person from the team, so feel free to ask for such support, if needed.
The Service Delivery Manager is responsible for:
- Checking the board with tasks to make sure that nothing is blocked
- Encouraging the team to undertake continuous improvement
- Organizing Kanban meetings
- Managing risk
- Making sure that the team according to the client’s priorities
While the Service Request Manager’s responsibilities are:
- Ordering the items in the product backlog, according to priorities
- Facilitating the selection of subsequent tasks to be performed
- Engaging stakeholders in the process
- Make sure that the team understands the stakeholders’ needs and expectations
- Make sure that the product development process continues in a good direction
When will the team need me?
You and your team might be surprised but, with Kanban, there are more meetings than when using Scrum. In Kanban, we call them cadences. Some companies use all of them, while others use only a few. It always depends on the needs and the company’s size. Let me introduce you to seven types of Kanban cadences.
1. Daily Stand-Up / Daily Kanban Meeting
As the name suggests, the Daily Standup meeting (also known as the Daily Kanban meeting) takes place every day, preferably at the same time. It should take the same amount of time as the Daily Scrum in Scrum – up to 15 minutes. The meeting should be a daily synchronization of all team members. It is held standing to keep it efficient and so that the team is focused only on the most important topics. During such meetings dependencies, the flow of work, and any possible room or opportunities for improvement are discussed.
2. Replenishment Meeting
The Replenishment meeting is similar to the Refinement meeting in Scrum. As in Scrum, it can also occur on demand – ie. daily, weekly or even bi-weekly. The duration is also up to particular team needs, it’s recommended you take no longer than 30 minutes. During the meeting, the team reviews the content of the product backlog together with the Service Delivery Manager. They discuss further priorities of work, classify the backlog items according to the Classes of Services and they review the risks and dependencies.
Classes of Service are the way to organize items in our backlog, according to their priorities and the way we should treat them. Using them should help us to improve predictability and deliver the most important items first. We can have as many CoS as we need, such as:
Work item type: when items are organized by their type, ie: bug, feature, research, etc.
Cost of Delay: we can organize items by the amount of money we are losing by not delivering them on time. Fixed Delivery date: when items are organized by delivery date.
3. Service Delivery Review Meeting
The Service Delivery Review Meeting has a similar sense to the Review meeting in Scrum. It occurs bi-weekly and takes up to 30 minutes. This is the meeting where we check the delivered scope against the customer’s requirements. As it is our key priority, in order for the client to be satisfied, this meeting is really important as we are collecting feedback regarding our work. Key participants of this meeting are the team, the Service Delivery Manager, you, and, of course, the stakeholders.
4. Risk Review Meeting
This meeting does not have its substitute in Scrum. The Risk Review Meeting occurs once per month and takes about 2 hours. As its name suggests, potential and real blockers and risks are discussed. Information from this meeting is sent to the Delivery Planning Meeting to be able to take into account such potential risks in planning.
5. Delivery Planning Meeting
The Delivery Planning Meeting may sound similar to the Planning meeting in Scrum but it happens with varying frequency (based on the cadencies). This meeting’s objective is to plan the delivery, especially when there are a few teams working on the same product. The goal is to then synchronize their further work. During the meeting, there is a discussion about which team is available to deliver which item. Information is then forwarded to the Daily Stand Up meeting.
6. Operations Review
This meeting does not have its substitute in Scrum. It happens once per month and can take up to 2 hours. Its purpose is to discuss the dependencies between all of the teams and verify whether we operate efficiently, as well as if we could improve our efficiency.
7. Strategy Review
This meeting does not have its substitute in Scrum. It occurs quarterly and can take even half a day. This is mostly a business meeting where all of the factors, such as market impact and delivery speed, are discussed. The goal is to optimize operations, discuss potential problems, and set up both short and long-term goals. As you can see, the meetings in Kanban concern and involve various levels within the organization. Ask your Team which meetings occur in your organization and in which ones you should be involved.
How does the team estimate the end date of work?
As a Service Request Manager, you may need to figure out the end date of our work:
- Release date of a particular part of the application, or
- Release date of the whole application
- In both cases, it is worth reaching out to the team to give you estimations.
But you have to know that, in Kanban, we do not estimate. The key to success is to build a well-working Kanban system and then – based on the measurements obtained so far – predict the future. There are a few practices that will help to build a well-working Kanban system. A system that will allow you to collect data, measure them and make predictions for the future.
Outside of the system, there are also a handful of metrics worth keeping track of.
In this section, I will introduce you to both the basic principles of a good Kanban system and its basic metrics.
How can you be sure that the team works effectively?
An effective Kanban system is the foundation for helping the teamwork in an efficient way.
A well-functioning system has several characteristics:
Technology gives individuals warning signs that they are likely to suffer from something serious if they continue on their current path.
- Visualization
- Work In Progress limit
- Workflow management
- Cadences (feedback loops)
