Introduction to Kanban

Introduction to Kanban

I have spent the major part of my working career working in a SCRUM setup. But in the past few years I have had the opportunity to build software in a Kanban setup. And it’s been a good experience. While SCRUM still remains the most popular framework I can see Kanban being more useful for certain types of organisations

The goal of this blog is to go over the basics of Kanban. Let start 🚀

What is Kanban

Kanban is a visual way of managing and completing work. It’s focus is to make you faster in completing the work that is in progress. It does so by relentlessly focussing on removing bottleneck that exist for the team

Is Kanban Agile

Kanban is lean. Scrum is agile. What does that even mean? It means that the primary goal of Kanban is to increase the speed of the work in process. On the other had the goal of scrum is to deliver working software as quickly as posisble.

The Kanban Board

Kanban comes to life with the Kanban Board. The goal of this board is to provide transparency to everyone on the work being done. Let’s look at the key components that make up the Kanban Board.

A Simplified Kanban Board

                        A Simplified Kanban Board

Columns

The current state of work is defined by columns.  All work in a particular state resides under the same column. There are no limitations on what you want to call your column or the total number that you can have on a board. Just don’t make it too long otherwise it will become unmanageable. Each card travels from one column to another before it reaches its destination. So how does one decide what columns make sense for you? By looking at your workflow! Ask yourself what happens to work once it lands on your team’s queue. The board above shows some examples of columns that teams use.

1.Prioritized Backlog: All the things that your team needs to do. It is prioritized from top to bottom so that when bandwidth opens up in the engineering team new items can be picked up.
2.Development: All items that are being actively built on by the development team.
3.Testing: All items that are being tested by the QA team.
4.Done: Everything that is completed and ready to be released

Cards

The Kanban Card gives you all the important information regarding the work. Again, there is no prescribed format for what needs to be on the card. You should put what your team finds useful. Think of it this way. If you had a physical Kanban board in your office and one of the leaders in the organization was walking by it and stopped to read it. By looking at the board they should be able to be able to understand what is happening and the current state of the work. I have listed down common information that you will find in Kanban Cards:

1.Title of the work which tells you what it’s about
2.Kanban/Story Number to track it
3.Due Date of when it needs to be completed
4.Type: Story/Bug/task
5.Platform: Web/Mobile/iOS/Android
6.Release:
7.Assigned To

Work in Progress(WIP)

This is the work being done by the team. You can look at the total team WIP, Each Column WIP or even each person’s WIP. It tells you what is the total “number of things” that are being worked on at this point of time. WIP doesn’t always tell you what the total workload on the team is.

WIP Limits

The notion behind WIP limits is that if you focus on a thousand different things at once you will not be able to make much progress. The idea is to set boundaries on how many different things the team and its members can juggle at any given time. If you give them more things their efficiency starts getting battered, bottlenecks start to emerge and nothing gets done.

You should set your initial WIP Limits based on what the team thinks will work and then tweak it as you move along. You will find that you did one of the following:

1.Overestimated your team’s capacity for doing work. You will begin to see all the Kanban Metrics go red.
2.Underestimated your team’s capacity. As a result business will see work getting shipped at a slower pace than expected

No reason to be worried. It’s an iterative process. Learn from the experience and find the right balance and the right WIP limit.

Examples of WIP limits:

1.Board Limit: The maximum number of cards on the board at any given point
2.Column Limit: The maximum number of cards on each column at any given point of time. Each column can have a different WIP limit
3.Team Limit: The maximum number of cards that can be assigned to each person in the team at any given point of time.

Swimlanes

It is a way to divide the board horizontally from left to right. Grouping of work that are distinct from others can form a swimlane. Examples of swimlanes are-Web, iOS, Android, Escalation, Platform, Project

Color

Color coding your Kanban cards and processes helps improve their visibility. It makes it easy for people to understand things in what can sometimes become a really crowded Kanban Board. For example you can use “red” to signify high priority escalation that needs to be taken care of immediately.

The Kanban Process

Kanban follows a pull system. This means that when the development team has capacity they pull in work into their system from the product backlog.

This is different from SCRUM which is a push system.

There is no owner in the Kanban process. The entire team as a whole is responsible for the smooth running of the system. In the real world however, I see product, engineering and delivery managers taking on the responsibility of the Kanban Board.

So how does the process work? You have your Kanban Board which has a prioritized backlog on the left side. As capacity becomes available people pick up tasks from the backlog.

You have “replenishment” meetings as and when more things need to be added to the prioritized backlog. In these meetings the tasks are discussed and doubts clarified.

Kanban Metrics

There are three metrics that are important to track as part of your Kanban process. They help you understand how things are working and which areas need your immediate attention.

Lead Time

It is the total amount of time from when the product team commits to developing a feature to when it is released. Your stakeholders care about the cycle time.

Cycle Time

The total time that the team works on a task is its cycle time. It tells how long tasks take to complete once they are picked up.

Throughput

It is the total number of tasks completed during a period of time. That period can be a day, week, month or something else. It has to make sense for your team. It helps you gauge whether Kanban is working or not. By plotting the throughput on a histogram you can get a good measure of the real world capacity of the team. This makes planning easier and more accurate.

Benefits of Kanban

Kanban brings in a lot of value for the team. It has some tremendous benefits:

1.It brings transparency to software development. By looking at the Kanban board you can make out how development is coming along
2.It is easy to understand. It does not have a complicated jargon that you need to get used to in order to understand it
3.You can implement it very quickly
4.It offers users flexibility. You can customize almost everything to suit your needs. You can modify how the Kanban board looks, the number of columns in it, what information to put on the the Kanban cards.
5.It helps reduce waste.
6.Blockers are identified faster in Kanban. So less time is wasted and the team can get together to solve the issues causing work to be blocked
7.Continuous delivery means that you don’t have to wait for a sprint to get over for a release. It can be done as and when needed
8.Once you find the right WIP limits it improves the output of the entire team. Nobody is overstretched or under-utilised.
9.You spend less time in planning meeting and more time shipping product

Conclusion

Like any other system Kanban is only as good as the people running it. Some things to keep in mind when you are implementing the Kanban system.

1.Are you able to adhere to the WIP limits? Or are you seeing it being overridden way too often for anyone to take it seriously?
2.Is the Kanban Board maintained and is it a true reflection of the current state of things?
3.Do you have executive sponsorship in your company to help Kanban succeed?
4.Is the team taking collective ownership of the board? Or is it beginning to feel like it’s no-one’s responsibility

If any of this is happening to you then you are not alone. It is not easy to implement and adhere to any framework. You will face challenges but if the system benefits the company and makes a difference then it will prevail in the end 🔥 🔥


You may also like