Interesting statistics
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.
