Demystifying Kanban for Software Dev Projects

I am a software developer and have been adopting Scrum in dev projects for many years now. I also have keen interest in lean practices and have been looking to incorporate these techniques in dev projects. Recently, I heard about the use of Kanban, which is one of the lean practices well known in software projects. I had the opportunity to attend a webinar: “Kanban for dev projects: How Exactly?” This webinar was conducted by Sanjay Kumar, a well-known Agile coach and lean practitioner.

Kanban is well known in the manufacturing environment, adapting Kanban principles in software development was interesting to learn. In this blog, I would like to bring out some of the key highlights of the webinar. The webinar helped break some of the common myths on using Kanban for software development projects.

What is Kanban?

I was aware that Kanban is an overloaded term and connotes different things for different people. Some refer to it as a board, card, system or a method. It was interesting to know that Kanban is all of these!
The term Kanban system originated in Japan at Toyota Production System, when the company implemented Kanban for Just-in-time (JIT) manufacturing. This concept was later adapted by David Anderson based on his experience in IT projects. David’s work expanded the concept of Kanban beyond manufacturing and into the knowledge work industry such as IT.

While referring to Kanban in IT, it is important for us to think of it as a method – Kanban Method. As a method, Kanban has proper meetings, ceremonies and robust metrics that many are not aware of.

Six core practices in Kanban Method:

When to Use Kanban?

It is common knowledge that Kanban is good for support projects. While this is true, I understood the significance and the role Kanban can play in development projects. Here are a few reasons I learnt as to why Kanban may work well for dev projects:

1. Projects transitioning from waterfall to Agile – Particularly when there is high level of resistance from team members or when members have to go through a learning curve that may impact productivity. Kanban could work better as it follows inclusionary change approach. While Scrum is a well-established process in development, in some situations Kanban may offer better solution and smoother transition to agile.
2. Beginning of new development projects – New projects have typical challenges where in requirement is not well understood by team or there is high uncertainty of requirements. Other challenges could be that they are in the forming stage and are not in a stage of norming, team’s dynamics have not taken shape and the team is faced with technical challenges. Given the set of complexities, using a more complex process or a process that require bigger learning cure such as scrum may add one more layer of complexity, which makes Kanban as a viable alternate
3. Product company with a mix of planned & unplanned work – Product companies already has products in production & in many cases have planned work such as new features that the company is planning & unplanned work such as defects. Kanban could be a good fit here particularly when the ration of unplanned work increases & crosses 25-30% as this poses a challenge to do proper sprint planning
4. Mature Agile team – Some teams may be doing scrum for a long time are moving to continuous delivery. Their processes are so defined that they do not want to wait until the end of the sprint to release a particular feature. In this case, the delivery of project has moved from batch basis to item basis where each individual item or feature can move out to production independently. I have seen in many cases such mature scrum teams transition to Kanban as Kanban allows for item based flow.

It is apparent from the above examples that Kanban works well and is an effective option in uncertain, complex and dynamic scenarios.

So what makes Kanban work for uncertain scenarios?
The key thing that makes Kanban work in uncertain/dynamic scenarios is Decoupled Cadences
Here is sample Kanban board I came across in the webinar:

• Ready column has items committed to be picked up in near future. One needs to replenish this ready queue to make sure team has enough work to pull into this workflow. You need a cadence for pulling in work into the ready column from the backlog.
• Other cadence is output cadence where we need to push the work out to deployment.

In Kanban the two cadences need not be aligned like scrum, where everything is tied to the sprint. In Kanban method, you can be pulling into the flow every week and delivering every week, fortnight, month or quarter. The fact that the two cadences are not coupled makes Kanban more flexible.

What is required to implement Kanban in dev projects?

There are two key steps to implementing Kanban in dev projects –
i) Getting ready
ii) Getting started

Getting ready

This phase is aimed at understanding the service delivery context. There are three steps in this phase:

1. Understand the demand
   • Understand the requirements flow into the system. For example, mature product will have requirements related to defects, CRs and features whereas new products will predominantly have features
   • Understand the rate at which the demand is arriving and this could be different for defects, features and CRs
   • Predictability of arrival – Planned or unplanned demand. For example, features could be planned, while defects are unplanned and CRs could be both
   • Level of urgency – All demand may not have the same sense of urgency. You may not have a FIFO kind of queue in the backlog. High priority items tend to go on top of the backlog.
2. How are we delivering – what is our capability?
   • There are various dimensions to this such as
   • Pace of work completion – Similar to velocity in scrum, Kanban has throughput which is the number of items finished per week.
   • How fast do we finish it? – This refers to the cycle time or lead time and SLA performance (performance against the SLAs.)
3. How frequently do we need to deliver to production – Understand delivery expectations?
   • Cadence based or on-demand deployment – this could vary depending on the item. Features & CRs could be cadence based and defects could be on-demand.
   • Is delivery item-based on batch flow?

After having understood the context of where you are working, we progress towards implementing Kanban.

Getting Started

Below are the key steps to implementing Kanban.

1. 1. Designing Kanban system
      There are three components of Kanban system:
      i) Visualization of work,
      ii) pull mechanism,
      iii) WIP limits.You can define the total number of items you are working on in the columns and also visualize the work in different swim lanes. The top most swim lane could be production defect, work related to change request in the middle lane and the bottom most could be new features. Below is an example design of Kanban system.

1. 1. Decide the inflow cadence – In planned inflow, you could have replenishment meetings where the frequency of these meetings would depend on the flow of request. Usually new features and low priority CRs would fall under planned inflow. Unplanned or dynamic flow is for urgent items such as defects and some of the urgent CRs.

1. Delivery cadence (outflow cadence) – Once the team is done with the work, how often do we deliver release to production? The release can be planned once per week/fortnight/month/quarter. For some items such as high priority CRs or defects, you may want to plan the release item by item. However, some of the low priority items can be released as a batch.
   • One thing unique to Kanban method is delivery planning meeting, which is different from release planning meeting. For a monthly release for example, meetings would happen at the beginning of the month, however, delivery planning meeting would happen “x number of days before the delivery”. It’s an evidence based meeting which looks at the flow and tries to understand how much is done already and how much could we possibly do by the release date.
   • For example, if you have a monthly release, you would have a delivery planning meeting say by day 20 or 22 to look at the flow & see how many are completed and how many are close to completion and to do a refined and better estimate of how many items can be actually delivered to production at the end of the month.
2. Manage the flow – Various considerations for managing the flow include:
   1. Develop a sense of urgency – when you touch one item, you finish it. The culture of touching multiple items & working in parallel with each taking multiple weeks should be avoided as much as possible.
   2. Avoid bottlenecks & starving – Bottleneck refers to the work is not moving across probably because of capacity constraints. Starving is where you have enough resources but not enough work, which is often faced in sprint. Kanban’s visualization provides effective solution to this. In any of the columns where there are not enough number of items, there could be possibility that the next activity to that could be starving.
   3. Daily Kanban – This is comparable to scrum stand-up meetings; however, the format is different. The key difference is that everyone is not required to speak and not all items on the board require to be discussed. The team lead/coach, decides the most important items that needs to be discussed with the team. Many teams finish their daily Kanban in 15 mins even if they have more than 20 people. Other key dimension of managing flow is open collaboration throughout the day, which is usually missing particularly in new teams. The last part of managing flow is Kanban metrics.

• Inspect and adapt – i) Product review and feedback where you collaborate with the customer & get feedback in order to make course corrections. Kanban doesn’t have a cadence for customer demo as it recommends you to define the cadence in terms of how often you want to discuss with the customer. While there is no fixed cadence like a time box or sprint in this case, Kanban has something very important known as discovery Kanban. You can think of another Kanban board towards, which will be used by the business people such as product owner and product manager,where they track their work and discuss with customer on a regular basis to get feedback. This helps them move an item from the idea stage to getting ready for dev on the floor. Ii) Process review is about understanding how well is the process working for you. Kanban has a meeting called as service delivery review, similar to retrospective with an added dimension of objectivity. Basically, as a team coach one will bring the Kanban metrics to the table to share them with the team and then start an open discussion.

Timeline – here’s an example to map different cadences for monthly delivery.

• Day 29 is the release date at the end of the month.
• Replenishment meetings (inflow cadence)– Happens at the beginning of every week to see how many items could be pulled from backlog to ready column
• Daily Kanban – Every day
• Service delivery review/retrospective – Fortnightly – this frequency can be decided based on the situation/project. This is up to the team
• Delivery planning – 7-10 days before the release date.

The webinar gave me a better understanding that Kanban is a well-defined method and when implemented right can work well for software dev projects also, particularly those projects that are mired with uncertainties and complexities.

Hope this lengthy blog has thrown some light on effectively using Kanban in dev projects. You can access the webinar on this topic using the link below: