Code Library

Without getting into the debate over the difference between Kanban with a capital K and kanban with a lowercase k, we will use the term Kanban with a capital K to indicate a new approach to software development using Lean concepts and techniques, including the famous Kanban cards, which originated from the Toyota Production System.

Unlike Agile, and Scrum in particular, Kanban does not require new roles such as PO or ScrumMaster. In all simplicity (which is its strength), Kanban allows an IT organization to keep all their current specialists (such as DBA, business analysts, testers, etc.) and continue to use their software development life cycle even if it is based on the waterfall approach. The reason why Kanban experts do not worry even when faced with a waterfall model is because it is the very premise of the Kanban approach to optimize using Lean concepts and techniques no matter what process a team is using.

Although different Kanban (Lean) practitioners have different ways of applying Kanban in software development, we believe the essence of how a software team uses Kanban consists of the following steps at the simplest level:

1. Visualize the current workflow
2. Capture current metrics and rules
3. Identify bottlenecks
4. Establish a new service level agreement (SLA) and policies
5. Limit work in progress (WIP)
6. Measure new lead times and some other metrics
7. Optimize

Let's review these seven points, one by one, in more detail.

1. Visualize the current workflow.
Without a clear understanding of how the current process works and how work is actually performed, any discussion will be purely speculative. This is why the first step will be to visualize the workflow as soon as you can.

2. Capture current metrics and rules.
Without a good understanding of what the performance of the current process is and whether the business users are happy or not, any improvement attempt will be hazardous. Therefore, it will be key to capture rules as to what has been going on.
Examples of such rules could include the following:
a. All requests are delivered between six and twelve weeks.
b. No development will be allowed before the chief architect has given approval.
c. All products should be tested by users before being released into the market.
d. Some users are available only to perform user acceptance testing.

3. Identify bottlenecks.
By interviewing the team, we came to realize that the chief architect represents a bottleneck, especially when he is not available or is so overloaded that he cannot perform his review on time.

4. Establish a new SLA and policies.
The intent behind the idea of SLA and policies is to identify the business customers' or users' expectations and what both sides should do to get to this new level of performance so that they can establish a trusting relationship.
For an example of SLA, we can imagine that the team will guarantee that all new requests will be delivered in less than six weeks. In return, the team could use this opportunity to require that the users be available three weeks before production to thoroughly test all the new features. In terms of new rules or policies, the team could decide that they should work on regulatory requests first and only take care of non-regulatory items after.

5. Limit work in progress (WIP).
Once the new SLA and mutual expectations have been reached, it will be time to review the team members' workload and see how to establish some limits on WIP. The idea behind limiting WIP is to set the number of requests for work a team can accept into the system without becoming overloaded.
To clarify this point, let's go through an example with some diagramming. Let's assume that we have a team of two business system analysts, three developers, three testers, and two technical writers. With three developers on the team, we can only have a maximum of three requirements being developed at any given time. To mark this limit, we write a number 3 into the upper right corner of the Development column.
Because development work normally takes longer than requirements and analysis, we can imagine that the order point (the point at which the business analyst can pull one requirement into the Analysis and Design column to work on) will be 3, but the limit can be higher than 3—let's say 5.
Now, before examining more advanced concepts in Kanban, let's assume that there are three members of the staff working on this project, which can be translated into three lanes.
We should remember that because we only have three developers, we should turn the Analysis and Design column from a pipeline into a queue. This allows a developer to work on any request that is in the queue, something they could not have done if the queue had stayed a pipeline only for a specific developer.
To make it easy for team members to know when an item will be ready to be pulled into the next column (station), a column can be divided into two sub-columns, one "ongoing" and one "done,".

6. Measure new lead times and some other metrics.
Like in Scrum, the Kanban team also has a daily standup, but unlike the daily standup in Scrum, Kanban's daily standup focuses more on the workflow (to make sure that it is continuously moving) rather than on the Sprint's goal.
Before each daily standup, an update should be made to show the team's progress. The diagram that shows whether the lead time is improving or if there is an increase in throughput is called the cumulative flow diagram or CFD.

7. Optimize.
As part of our continuous effort to optimize the development team's work, we may be tempted to also organize the work around common data-related requirements to keep the work flowing.
This would mean that the number of limits in the Development column could be increased to 6.
This is to say that the order point for the Analysis and Design column can also be increased from 6 to 9.
Eventually we could combine the Analysis and Design and Development columns to allow for more frequent customer interaction.

Similarities between Agile/Scrum and Kanban