Why set up a Kanban?
In his book Learning to Scale, Regis Medina presents the pillars of the Lean management system (also called Toyota Production System)
One of the main pillars is the "Just In Time", which is a production system consisting of minimizing the lead time of products through the different stages of the flow, as well as the inventory of these products, be it intermediary or final products.
To achieve the “Just in Time”, it is necessary to make the workflow visual in order to surface the problems and solve them with a continuous improvement mindset, which is the motto of the Lean management.
A Kanban sequencer allows exactly to do that through a ticketing system that shows real-time information about value creation in the flow, through:
- Visualization of the work in progress at each moment of the day
- Who is the client of the request?
- What is the purpose of the request?
- When was the request made?
- Who is in charge of completing the request?
- What is the current status of the request?
- Visualization of possible blocking factors including:
- a significant inventory level of intermediary products
- a lead time (stagnation time + processing time) in deviation from the standard. Here is a visual of the components of a lead time cycle
Kanban as an industrial lean tool
As every lean tool and framework, Kanban was first used in the manufacturing industry to sequence tasks between several production stations. The aim being to visually manage and control in-process inventory levels between successive workstations
To ensure normal production, each workstation requires a certain amount of parts or objects that are partially processed, that the preceding workstation must provide. In the “Kanban” method, batches of parts or necessary objects are placed in standardized containers (this simplifies counting and visual inspection).
A label or “Kanban” is attached to each container. When a post receives a full container with its label and if it needs another container to ensure its production, it detaches the label and returns it to the previous post. The latter will then produce enough to deliver a new container to which it will attach the same label. And so on from post to post.
The number of kanban in circulation must be limited to avoid the formation of a high inventory level of intermediary products
The operation can be visualized as follows:
From Kanban in the manufacturing industry to Kanban in agile development projects. How to make the leap ?
The Kanban tool can be implemented in agile projects, since the manufacturing flows in the industrial and IT fields are quite similar.
In our agile development projects, we used the Kanban for two steps of the flow: Development in Progress – Code Review
The similarities between manufacturing and agile software development can be drawn in three points:
1- See a step in your agile flow as a workstation . For example :
- Workstation A = Work in Progress
- Workstation B = Code Review
2- A step in the agile workflow is like a workstation supplying another
- This is the case for the example of Work in Progress & Code Review. The Code Review “workstation” is a client of the ticket that was in progress and got completed by the developer
3- The containers “bins” holds the products coming from workstation A and that should be processed by Workstation B The Trello / Jira column for the Code Review can be considered as the container, thus the same rules apply :
- Once it is empty, the previous workstation is notified to “supply” with new product to process (if you’re following a pull workflow system)
- Once the container contains too many items (to be defined depending on the project) the visual system signals it as an abnormality. For this you can use the chrome extension Kanban WIP (https://chrome.google.com/webstore/detail/kanban-wip-for-trello/oekefjibcnongmmmmkdiofgeppfkmdii?hl=fr)
Prerequisites for the implementation of the Kanban in an agile development project
In order to set up the Kanban tool, 3 prerequisites must be completed:
- Visibility on the dependencies between the tickets of the day in order to start the day with the tickets that unlock the Epic stream. If ticket A depends on tickets B to be completed, then the team should start with ticket A. This can be visualized through a dependency graph
2. Avoid taking tickets that are “too big” meaning that they take almost all day to be completed. It is advisable to split them into two to three tickets. This will allow the developer to take part in developing and peer reviews activities throughout
3. Synchronization in the celerity of the team’s developers : a ticket (feature) is supposed to take the same time to be developed by each member of the team. This condition is important because a developer will only start his second ticket of the day if he finishes the Code Review and thus reduces the in-progress of tickets in Code Review
The role of the Agile Coach / Scrum master is to converge efforts to meet these three conditions on a daily basis, without which the kanban system will not produce the expected results
How to illustrate and use the Kanban during daily meetings?
The illustration of the Kanban sequencer can be done through a board on PM tools such as Trello, Jira. For more visual details you can also use a Google Sheet file shared between the team members:
- A developer carries out two different activities during the day: Develop - Make Code Review. These two activities are each presented in a separate line
- Each ticket has a different color code, to easily see who develops and reviews the ticket
The table can be used as follows:
- During the daily standup, the developers choose the tickets for which they want to do the Code Review (respecting the prerequisites). For example Developer 1 & 4 will do the code review of each other because their respective tickets 92 & 96 will take the same time to be developed. Therefore there will be no stagnation time of the ticket waiting to be reviewed
- Once the developer finishes his ticket, he checks the table to do the Code Review
Results with impacts
The implementation of the Kanban in our project was done between two “workstations” : Work in progress and Code Review step
Over a month of implementing the tool, the stagnation time (and thus the lead-time) of the tickets in the Code Review stage of the flow has decreased by 50%. It went from an average of 1 day to 4 hours.
This result was an enabler for the rest of the steps of the flow : To deploy – To Validate by The Product Owner.
It allowed the team to have more story points in Done and therefore have a shorter cycle to roll out features to staging.
Next steps :
As shown in this case study, the Kanban tool was used between two steps of the flow “Work in Progress” & “Code Review”. It can be used in other parts of the “production flow” such as : a Kanban sequencer to have just in time :
- between tickets that are deployed in staging and the validation by the Product Owner
- in the features design, between the designer outputs and the Product Owner validation of the screens
The experiment proved that it’s possible to implement best practices of lean manufacturing into agile development using Project Management tools.