Kanban in a nutshell
If you’re working in an industry involved with production – generally with any physical products like cars, engines or software – then you’ve probably come across the word “Kanban.” Although Scrum is a more typically used software development method (it’s already a buzzword in software production), Kanban is being implemented more and more due to its approach being more pragmatic than dogmatic.
“Kanban” is a Japanese word coined by Taachi Ohno, an industrial engineer involved in the production workflow of car parts at Toyota. Kanban means “signboard” in Japanese, which accurately summarized his approach to production in a nutshell (although recently, as with most project management software, it evolved to fit your computer screen). Essentially, Taachi Ohno’s approach signaled the different tasks in production and at which point of production a task was in at any given moment. Even though Kanban seems complex and is used in complex production lines, the emergence of its approach came from a very basic system: a supermarket.
In traditional, small-sized supermarkets deliveries for stocks are based on the actual needs, which means the store owner will order only the products that he is running out of instead of bulk ordering products with no regard to their inventory status. This is called a pull system. A pull system in a supermarket means that ordering begins only once the inventory reaches to a pre-determined level. This level depends on the frequency of the customer visits and subsequent sales of a specific product.
Now that we’re distracted by supermarkets and car production, let’s ask our big question:
How is Kanban used in software development?
Although software development lacks the physical aspects of manufacturing processes, Kanban can be integrated to optimize the input and output, namely the work of your developers and your features. In this article I won’t be giving much detail about the integration of a Kanban system, but rather giving you a general view of the approaches to Kanban so you can decide if it’s optimal to implement into your tech team’s workflow.
1. Visualize Work
As the name suggests, Kanban is a highly visual approach regardless of the industry it’s being used for. I believe this aspect of Kanban is the aspect that influences the psychology and motivation of the stakeholders and developers the most. As we are creatures who are stimulated mainly by our visual senses, this creates a very crucial experience in Kanban.
Many companies who uses Kanban even use an actual, physical board to visualize their workflow. In my opinion and experience, this is an awesome approach Kanban: even though nowadays visuality means looking at your computer screen for 8 hours a day, having an actual board to pass by and interact with at creates more mental stimulation.
What do you find on a Kanban board?
A Kanban board has a so-called “swimlanes” (since it literally looks like a swimming pool with lanes). These swimlanes include different phases of development. These lanes vary from company to company and from team to team according to their structure and related tasks. The lanes that are used often in software development are:
- In Progress
“Backlog” is basically an idea bucket where a Product Manager writes the tickets or issues without a definitive time line or strategy. As an example, you might have had a request from your company’s business-focused departments for a specific feature, but want to first discuss it with all the stakeholders and your developer team leads to decide if it makes sense to develop or if it will bring enough business value for the invested time and effort. Personally, what I find very effective is to create a sheet that you share with the business side. This can be your account managers, sales managers or technical account managers. Since they are the ones who have continuous feedback from the clients, they are the ones who will come up with various feature requests – so get many requests as you can from them. Then it will be your duty to select the features to be placed within the “Ready” lane and to prioritize them.
“Ready” is the lane you move the issues you’ve discussed with all stakeholders and determined the upcoming steps and a rough time line. It is always a question if the product manager should limit the number of issues opened in Ready lane: even though there are many different approaches to this, I would suggest you first collect metrics on your team and then decide what the optimal amount of issues is.
You can do this by finding out the number of issues that are closed per week, and then deciding if you want to double this number as the maximum number of issues to stay in the Ready lane. Since the issues are taken one by one from the Ready lane to In Progress, you can move a single issue at a time. However, most teams want to see more issues so they have a rough vision what is coming up next. My suggestion is to have two times the number of developers in your team. If you have too few issues in the Ready, your team will lose their vision on the product; if you too many piling up then they will be demotivated since it will look like they will be never reach a “Yes, we made progress!” moment. Make sure that you do not assign a developer to the tasks in this lane.
“In Progress” is where the issues are already being worked on. The moment you start developing something related to this issue, you need to move it from Ready to In Progress. This lane is where work in progress (WIP) comes in play (which will be explained in the next section). One of the most crucial duties of a product manager is to determine the WIP limit for the In Progress lane and make sure that everyone in the team sticks to it.
“QA” is where the issues that are waiting to be QA’ed. In some tech teams there is a dedicated team for QA. In this case, you should fix a maximum number of issues that will be in the QA lane. This number will depend on the number of QA engineers you have. You can find this number by experiments. You can fist determine a number that makes sense to the stakeholders, then you fix a time where you will evaluate the workload and redetermine the maximum number of issues.
“Done” is the lane that makes your stakeholders happy. Issues should be moved to Done only if they are QA’ed and deployed, and if there are no more steps to be taken. Should something fail in QA , you don’t move it to Done but rather back to In Progress.
2. Limit Work in Progress (WIP)
This is a very important aspect of Kanban. Although many managers and stakeholders think it is a positive thing for the developers to work on as many different issues as the possible, multi-tasking is not a positive approach in software development. The more issues the developers have to tackle, the more distracted they will get. This distraction results in unfinished work, long production cycles and low quality in finished work. For these reasons try to find the optimal number for WIP in your team.
There are different approaches to finding your optimal number. If n represents the number of your developers, then 2n or n+1 might represent a way to determine your number, depending on the different dynamics and bottlenecks of your team. In case the determined number creates too much stress or too much slack time, then you might consider modifying this number.
3. Focus on Flow
As was mentioned before, the visual aspect of using a Kanban board also helps you to clearly visualize the production bottlenecks. If you see that one lane has too many issues piling up, you might need to observe the workflow through that point. During your observation you need to focus on finding the element in the team that creates the bottleneck. Reasons can be that there is not a high enough number of developers, that there are too many dependencies on other issues or that there are dependencies to external partners.
In order to see the bottlenecks and the improvements that have been implemented it is crucial to collect metrics of your workflow. Some significant metrics are lead time and cycle time.
Lead time is the time from when a request has been made by client or a stakeholder to when the issue is completed. In other words, this is the total time a client waits for an item to be delivered
Cycle time is the amount of time when the team is working on the issue. This does not include the time the issue spends in the Ready lane.
4. Continuous Improvement
This is a method to identify the opportunities that teams have to make the workflow more efficient and to reduce waste. Continuous improvement streamlines the workflows. When the workflows within a team or among various teams are efficient, teams save money, time and workforce.
Throughout this, product managers should be observing case studies to discover opportunities for improvement. Always keep in mind is that some companies fall into the trap of focusing too much on improving their workflow with creative ideas, and that these solutions may be negatively affect your longterm outcome.
These four approaches in Kanban are things to consider if you’re interested in implementing it in your tech team. Depending on to your development approach, Kanban can be a good solution for increasing productivity and decreasing waste.