Kanban in IT design. Metrics and their use to optimize the development process
This article provides an overview of how to effectively implement the Kanban methodology in IT projects. It explains key Kanban metrics like lead time and cycle time, and how they can be used to measure and optimize team performance. The article discusses how to eliminate wasteful activities in the development process, such as over-engineering, multitasking, and incomplete work. It outlines a phased approach to gradually integrate Kanban into an existing workflow, from initial learning to advanced mastery. The article emphasizes the importance of engaging the team, visualizing the workflow, setting work-in-progress limits, and using data to drive continuous improvement. Implementing Kanban can help IT teams deliver projects more efficiently, but the transition should be managed carefully to ensure success.
Utilizing Kanban provides two key metrics to measure team performance objectively: lead time and cycle time.
The execution time is the time from the moment the task enters the start phase to the moment it exits the finishing phase, i.e., in our example, it is the time delta from the moment the task is entered in the Work In Progress column until it moves to the Done column.
The execution time must also be managed to ensure that features are delivered on time. The team can optimize lead time in one of the following ways:
splitting a step into several smaller steps;
combining several smaller steps into one;
automation through scripts;
adding additional resources, such as computing infrastructure;
additional testing/review cycles to limit waste activities in subsequent phases.
The main problem with software product development is that the same feature can be more complex in one area than another. For example, a particular feature may be harder to implement than to test, and vice versa. The execution time of such functions can be controlled by dividing the task into functional domains. When doing so, you must include an integration endpoint to ensure that when the function is executed, it includes the integration of individual domains into the entire function.
Another metric is cycle time, which measures when work on a task started and when it was completed. This is not a measurement of effort but the cycle duration in the system. Cycle time is the time it takes for a function to travel from the beginning to the end of your process, while execution time is when the function enters and exits your process. Calculating average lead time and cycle time gives you an idea of your workflow. Comparing average task times at various stages can provide empirical evidence that a process is improving.
Once a reliable set of empirical data on lead times and cycle times has been collected, Little's law should be used to calculate team throughput: the long-term average number of customers in a stable system (L) is equal to the long-term average effective arrival frequency (λ) times the average the time the client spends in the system (W).
Let's express this idea algebraically:
L = λW
Or, in Kanban terms:
Average cycle time = Average task time / Average throughput
Throughput should indicate whether the change improved the workflow as the process goes through the tuning phase.
Using the fundamental practices and metrics described, the team can visually see the following issues in their workflow:
identify bottlenecks;
identify areas of "braking" of the workflow;
identify areas for flow improvement.
The flow control rule is based on the fact that the entire process must be constantly reviewed to find ways to make your team more efficient and productive. In other words, finding and eliminating wasteful activities in your process is vital.
For development teams, it is recommended that before the Kanban process in a project is launched, all project participants have a clear idea of the big picture of the project. The design knowledge area should include a set of priority features that will be implemented and an initial architectural vision of how all the features will work together. To be clear, this architectural view should cover all parts of the system, including but not limited to design, testing, physical design, and software, as appropriate. With this insight, the team can guide the development of interdependent features as the project evolves. This reduces the likelihood of rework due to incorrect assembly.
IT design and Kanban. Emphasis on the elimination of losses
A key element of Kanban and Lean manufacturing is eliminating waste. In the design environment, waste is usually caused by wasteful activities such as:
1) Doing more than necessary
The position “this feature will come in handy someday, let's add it” is unacceptable in an IT project. The team should focus only on what is needed now, that is, on optimally performing the task. This does not mean the precious task of developing a module/class to house future functionality should be eliminated. Still, the understanding that only works that adds value should be considered is at the forefront.
2) Doing what needs to be done in a sub-optimal way
You should create only what is necessary to complete the job. Doing work that does not contribute to the solution of the task is a waste of effort, especially since large projects in the field of IT development are expensive knowledge-intensive projects. Therefore, unnecessary or useless work should be excluded; the whole team should know this.
3) Multitasking
Multitasking always increases overhead because the cost of a context switch can be high. WIP limits define the boundaries of the "stretch" of the team's efforts.
4) Incomplete / Incomplete execution
Kanban promotes clearly defining when a task is due with entry and exit criteria for each column.
5) Waiting / Idle
The excuse "I can't start this task until I get it from..." doesn't work in Kanban. The visual board and daily meetings create an opportunity to identify blocking tasks. A typical example of an IT project is when the project is waiting for a validation environment. Kanban can help by separating the verification tasks into creating a simple system health verification environment and adding tasks that make the verification environment more complex.
6) Resource / Task selection errors
The excuse “Ask Vova to do this while he is not busy” does not work in the Kanban system.
Assigning someone who is available but not competent enough usually ends up with low-quality work that takes longer than desired and inevitably needs to be redone later. Any modification is a waste of time. Although Kanban does not provide any mechanism for isolating this problem, it does help identify it as a problem to be solved since a task supported by misassigned resources will likely take longer than usual.
Kanban Methodology Integration
Below is guidance on how the development team can integrate the Kanban approach into their current workflow. These recommendations are based partly on practical experience and best practices in the software development community.
Compared to other Agile methods, Kanban is a straightforward methodology with very low overhead and simple rules that can be quickly adopted. The fact that it doesn't interrupt the steps that are in progress is its strength because it can and even needs to be integrated into an existing workflow so that the team can self-organize and, if necessary, continue improving the workflow.
So what can you do to introduce Kanban into your flow gradually? There are three Japanese terms to describe the transition of Kanban teams from novice to master status:
SHU - a place where we study the basics of technology or methodology;
Ha - understanding the basics and the gradual introduction and adaptation of a new method;
RI - mastering technology, using advanced data and innovating.
Let's consider these stages in detail.
I. SHU - Introduction to Kanban
We offer the stages of introducing Kanban into the team:
Phase 1 - Learning: Engage a professional to learn more about Kanban.
Phase 2 – flow visualization: make notes of the current process using the whiteboard. Start where the team is now. Visualization is not an image of how you want to work but a fixation on how work is done. Good, informative, and accurate visualization is an excellent start for those who implement Kanban. The next step is ensuring the team understands each stage's entry and exit criteria.
Phase 3 - adding WIP limits. Adding WIP limits should be based on reality. A good option is to start by calculating the WIP as the number of engineers/specialists multiplied by a reasonable average number of tasks each performs simultaneously. Kanban recommends starting small and gradually increasing the WIP through experience, such as when free slots remain open or the cycle time is too long. This is starting to identify bottlenecks and resource constraints.
Phase 4 - a review. Review can be carried out at all stages. The goal is to discuss the progress of the process and remove bottlenecks, as well as improve what (and how) is being done.
II. HA - Using Kanban
Once the basic Kanban skills are formed, you can implement the methodology.
Phase 1 - a collection of indicators. Start collecting available metrics. This will provide objective data based on which pragmatic changes can be made. In addition, data collection provides the basis for objectively determining whether any process change improved the team's performance.
Phase 2 is the use of metrics. The metrics collected during discussions are used to improve the assessment of tasks/activities and to plan the amount of work the team can handle reasonably.
III. RI - Mastering Kanban
At this point, the team is fully versed in using Kanban. Using the collected data, you can now include it in your future planning sessions to estimate the duration of the tasks ahead of you. Now your planning is based on empirical data, not on imaginary assumptions. Since the estimates are based on empirical data, you can be sure of their accuracy.
In conclusion, we note that any changes are difficult, disruptive, and uncomfortable for many team members. Adapting Kanban (or any new process) in stages is strongly recommended, considering the significant problems of the people directly affected by introducing the new technology.
Nothing scares people more than the unknown. People will react negatively if the change and its goals are not fully understood. The chances of success will increase if the learning and implementation of Kanban are done gradually.
Finally, remember that the discussion of Kanban efficiency presented here is only for getting started. While Kanban itself is relatively simple, the rationale for its use and the context in which it was developed may require further clarification. Referring to the specialized literature to learn more about Kanban and how it applies to lean manufacturing and product development makes sense.
FAQ
How does Kanban help with risk management in projects?By making work visible and limiting work-in-progress, Kanban helps identify potential risks early in the process. Teams can see where work is getting stuck, aging, or deviating from normal flow, allowing them to proactively manage risks. Kanban metrics also provide data to assess and mitigate risks.
What is the role of a Kanban board in facilitating collaboration?The Kanban board serves as a focal point for collaboration, providing a shared understanding of work status, priorities, and bottlenecks. Teams often hold daily standups around the board to discuss flow, issues, and improvements. The board also enables cross-functional collaboration by making dependencies visible.
How can Kanban help manage stakeholder expectations?Kanban provides transparency into the work process, allowing stakeholders to see the status of their requests and the team's capacity. By using metrics like cycle time and throughput, teams can give stakeholders predictable delivery forecasts. Kanban also helps manage scope by focusing on completing existing work before starting new work.
What is the concept of classes of service in Kanban?Classes of service are used to differentiate work items that require different handling, such as expedite, standard, and intangible. Expedite items are fast-tracked through the process, standard items follow the normal flow, and intangible items may not have a defined workflow. Classes of service help ensure that different types of work are managed appropriately.
How does Kanban promote a culture of continuous improvement?Kanban makes problems in the workflow visible, encouraging teams to identify and resolve issues. By holding regular retrospectives and reviewing metrics, teams can identify opportunities for improvement. Kanban also fosters experimentation by allowing teams to make small, incremental changes and measure the impact.
What is the role of leadership in a Kanban implementation?Leadership plays a crucial role in supporting a Kanban adoption by setting the vision, removing obstacles, and empowering the team. Leaders need to model Kanban principles, provide resources for training and tools, and create a safe environment for learning and improvement. They also need to align Kanban metrics with organizational goals.
How does Kanban handle work that is blocked or delayed?Blocked work is typically indicated on the Kanban board with a visual marker like a red magnet or flag. Teams should have policies for how to handle blocked work, such as escalating to a manager or swarming to resolve the issue. Blocked time should be tracked as a metric to identify systemic issues.
What is the difference between push and pull systems in Kanban?In a push system, work is assigned to the team based on a predefined schedule or plan. In a pull system, work is pulled into the process based on the team's capacity and agreed-upon policies. Kanban is a pull system, where the team pulls work from the backlog as they have capacity, enabling a more sustainable and adaptive flow.