Kanban in Software Development – Guide for App Owners

Kanban basics

Have you ever seen a simple table of three columns showing the things to be done, those currently in progress and the ones that are complete?

So, you have met Kanban then. But do not be fooled by this apparent simplicity – there is much more hidden underneath Kanban’s hood.

What is Kanban?

Kanban is a compilation of two japanese words: ‘kan’ – a sign and ‘ban’ – a board.

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.

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. Concept is similar to Scrum.

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 any 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 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
• making sure that the team understands the stakeholders’ needs and expectations
• making 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

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, Service Delivery Manager, you and, of course, the stakeholders.

4. Risk Review Meeting

This meeting does not have it’s 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 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:

• a release date of a particular part of the application, or
• a 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 few practices which 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 team work in an efficient way.

A well-functioning system has several characteristics:

1. Visualization
2. Work In Progress limit
3. Workflow management
4. Cadences (feedback loops)

Let me introduce you to each of the mentioned characteristics.

1. Visualization

The key to visualization is the Kanban board, used by the team on a daily basis [picture]<

Regardless of whether the team chooses an offline or online version of the Kanban board – it will look very similar each time.

The basic Kanban board consists of three columns: “to do”, “in progress”, and “done”.

The status of the tasks assigned to each team member can be tracked on the board, which is visible to all team members. Even one sight on the Kanban board will help you indicate the overall status. For example, if one of the columns contains far more tasks than others. It may mean that the particular part of the process has a blocker, ie. testing is a bottleneck. If so, we then need to look at why tasks spend too much time in that particular part of the process.

2. Work In Progress limit

The Work in Progress limit (WIP) is a value that determines how many tasks the team can work on at any given time. Just to be precise, each person works on one task at a time.

Yet there can be a few tasks in the “in progress column” assigned to different team members, or assigned to one team member but just opened.

The limit of WIP will make sense only if the tasks have similar size.

Once our knowledge about Kanban is growing in the team we will be able to more easily establish that our WIP for tasks in certain stages, such as “Testing”, is. For example, a WIP limit of 4 means that testers may have a maximum of 4 tasks to test at once.

3. Workflow management

Workflow management is the observance of the team’s work speed and how tasks move across the board, where bottlenecks appear and which columns are empty.

If we observe the columns for time, we notice that some of them fill up with tasks very quickly. Then, perhaps, we should impose a WIP limit on the remaining columns and, where the blockage arose, we can direct more forces to work.

4. Cadences (feedback loops)

Cadences, meetings described widely in the previous chapter, are the best moments to inspect and adapt our work.

Thanks to them, the team can collect the feedback from you and all interested parties, implement improvements and work better in the future.

Which metrics can you track with the team?

There are four basic metrics that you can track with your team on a daily basis.

• Lead time & Cycle time
• Work in Progress
• Throughput
• WIP Age

1. Lead time & Cycle time

Lead time is the time measured since the task was created and until the task is done (delivered).

Cycle time is the time measured since the work on the task was started and until the task is done (delivered).

From the client’s perspective, the smaller the difference between two measurements is (lead time/cycle time) the better. A shorter time here means that, once the need appears, the corresponding work is started. If the task is waiting to be done for too long, it’s a waste as it may not be needed any longer.

2. Work in Progress

Work in Progress, as the name suggests, indicates the number of tasks that the team is focused on in a particular period of time.

The bigger the number is, the smaller the number of tasks delivered in a particular period of time. The results are easy to see on Cumulative flow diagrams.
As Kanban says: stop starting, start finishing. It means that to deliver more (to move more tasks to the done column) we should limit the number of tasks that are in progress (to set up the WIP limit).

3. Throughput

Throughput is a measurement that indicates the number of tasks done in a particular period of time. You may recognize its similarities to Velocity, which is already known from Scrum.

Just as velocity shows the number of story points delivered in a particular period of time, throughput shows the number of tasks finished in a period of time.

If we want to, we can dive deeper into the math and count the throughput by dividing WIP by Lead time.

The relation between lead time and throughput is called Little’s law.

For example if the number of tasks in progress (WIP) = 8 and the approximate lead time of task = 4 days, then throughput = 8/4 = 2 tasks.

4. WIP Age

The last metric worth mentioning is Work In Progress Age. It is the amount of time needed to complete the task.

Such a measurement is useful if we want to indicate the tasks that were started a long time ago, analyze why the work takes so long and possibly determine if they’re still needed.
Lowering the value of WIP Age can also indicate that the team’s performance is increasing and that team controls their capacity better.

Kanban Pros

• In its basic form, it’s easy to understand. Watching tasks moved through a simple table with columns ensures everyone in the team is on the same page regarding the progress of work.
• Kanban reduces waste. As this is a pull system, the workflow is continuous so no one is waiting idly for work.
• It’s focused on events and not on time. In Kanban we are focused on delivering tasks. The time of their delivery is of secondary importance
• Bottlenecks are easy to find. Each team member can figure out if there are too many tasks in one of the columns. Therefore, corrective action can be taken quickly.
• Flexible. The scope of work can be easily updated. There’s no need to wait until the end of the Sprint to change direction. Tasks can be added or replaced anytime.

Kanban Cons

• As with each framework, Kanban also has its disadvantages:
• There are no commitments or no estimations, which are both possible with Scrum. The lack of these features may cause work to become ineffective for teams inexperienced in Kanban.
• There is no timing. As there are no timeframes and no iterations, it may be hard to recognize when we will finish and if we are delayed.
• It is harder to keep the constant paste of the team due to the lack of iterations.
• Kanban assumes that our plans are quite constant. It may not work well in a dynamic environment.
• The Kanban board may be outdated. If you do not update the board frequently, Kanban will not bring its value and will cause confusion instead.

When is Kanban a good choice?

Kanban is a good idea:

• For maintenance projects where we do not add additional features to the product but, rather, we fix bugs.
• For predictable scope where we are not going to change the whole direction of work frequently (which is possible in sprints). 
• For a scope of work where one task is independent of others.
• When the team needs to visualize their flow of work and/or you need to motivate them 😉  A Kanban table may be a good source of motivation for team members, as each team member can verify whether his or her tasks are moving faster or slower through the board than the tasks of others.

Kanban – wrap up

I hope that, after reading this article, you’ve understood the basics of Kanban flow and that, if we are using the Kanban table, it does not mean that we are using the Kanban system 😉 

The choice of Kanban or other frameworks always depends on what product we are building and the degree of certainty as to what the final product should look like.

Related posts