Interesting statistics
Kanban is straightforward to understand compared to some traditional agile project management frameworks. This simplicity is its main strength, and therefore the use of Kanban can catalyze change in how work is organized.
Consider how Kanban practices are implemented in the development team:
A. Visualize your workflow
Kanban is based on the idea that the team should see its workflow. Using a visual representation of the workflow, the project manager can find potential for improvement.
All developer activities are planned, tracked, and visually presented on the Kanban board. Regular and ongoing opportunities are provided for team discussions to ensure the team is focused and working on the most critical tasks. Faster actions, such as fixing bugs, can be visually represented in a different color.
Alternatively, a Kanban board for IT developers can have several workflow steps:
Backlog: all functions/actions to be performed;
Analysis: The slack needed to understand and analyze the problem, capture the requirements, define exit or done criteria, and consider different architectural approaches;
Design: initial design engineering;
Implementation: implementation of the solution;
Validation: debugging and verifying the correctness of the implementation and its compliance with the criteria defined in the analysis phase;
Done: The task/action matches the exit criteria.
Such a board might contain a separate urgent workflow that creates capacity for those inevitable items that need to be accelerated. Of course, this "band" should be used infrequently.
The visual aspect of the Kanban board encourages discussion within the team on how to optimize the team's processes and methodologies to reduce time wasted in the team's workflow.
Because Kanban visualization allows the entire team to see the entire process, it is the first step to allowing the team to optimize the process. While the team is working on the project, there is always time to make suggestions for adding or removing steps from the process—the Kanban board evolves as the process evolves. Having the board in a prominent place creates both a mechanism and an opportunity to discuss the process. This is usually done during short, focused daily meetings to discuss progress and block issues (ideally moving tasks through the workflow).
B. WIP Limit
The classic approach to how a team engages in design work is to give them multiple tasks/features to implement at the same time, as well as to have a constant stream of meetings to critically think about bugs and determine the current "quick" tasks that need to be completed in the shortest possible time. This leads to inefficiencies due to the need to switch between tasks. A more practical solution is to ensure that each person focuses on fewer tasks and lets them work through them. The purpose of this practice is to limit work in progress.
Every project has limits: people, computing power, licenses, planned vacation, etc. These limits need to be clearly defined and documented on the Kanban board. This is done by assigning a work-in-progress (WIP) limit to each column on the Kanban board representing the limit. For example, suppose we want to assign a work-in-progress limit to the implementation phase. If we have four developers and assume that a developer can work on no more than two tasks simultaneously, the resulting WIP limit is 8 (= 4 developers * 2 tasks per developer). This defines the maximum number of tasks/activities at this process stage.
The critical point here is that Kanban uses a pull system. If the project manager believes that the WIP limits determine the number of free slots available for each column, then he can move the task to the column only if there is a free slot. For example:
the team cannot start a new item from the backlog if the analysis phase has reached WIP limits;
however, as soon as any element in the analysis phase is completed, it can be immediately moved to the design phase if there is one free slot;
there is no limit for the Done column.
The concept of pull is that tasks can only be pulled from the right instead of being pushed from the left. In addition, the team needs to define entry criteria at each stage to ensure that only completed work is accepted. Acceptance of something incomplete will inevitably cost time and, therefore, money. Returns of unfinished tasks can be the bane of any IT project, especially if their return to the flow is due to system overstrain (non-compliance with WIP workflow restrictions).
The critical point about moving from the backlog to the analysis phase is that it provides an opportunity to decide which task or function currently has the most significant value. Since priorities often change throughout a project due to new information or technical issues, reconsidering what should be implemented as soon as possible or as late as possible is critical in using a continuous system like Kanban.
Once the WIP limits are in place, it becomes obvious where bottlenecks exist in the process because one or another element creates back pressure on upstream activities. Increasing WIP limits will likely mean that tasks are stuck in the column for too long and the work is dragging on too long.
Once an initial set of WIP limits have been determined, they will likely need to be adjusted as the project progresses. This is natural and to be expected. One approach is to observe how smoothly tasks flow through the Kanban board and experimentally find the optimal WIP by increasing and decreasing WIP limits to smooth the flow.
C. Flow control
One of the essential organizational goals of any project is to make the most efficient use of the team's resources to solve the project's tasks. The visual aspect and work-in-progress limits discussed in the previous sections help identify bottlenecks and help the team optimize the workflow from start to finish.
D. Ensuring Policy Transparency
As the saying goes, "The best disinfectant is sunlight." This means that only when the policies are explicit can the problem be seen.
The purpose of this core practice is to clearly articulate any underlying policies in the workflow, i.e., how things are done. Once formulated, they become "facts" for the project, reducing any subjective analysis or emotional burden associated with the development process.
Creating opportunities to review the process through the collected objective evidence or individual facts is essential. These opportunities can generate improvement ideas that everyone agrees on because the discussion is based on facts. Ideally, this feedback should occur whenever enough evidence of a problem exists. The issue must be subjected to meaningful discussion, which can sometimes go on for weeks or months.
The emergence of bottlenecks is also an opportunity to discuss ideas. Ideas after discussion can be placed on a backlog (or tasks) to be prioritized and added when the next available slot becomes available.
Daily meetings provide an opportunity to discuss issues objectively.
As a physical element, the Kanban board allows people to talk about the "board" rather than the "person". By shifting the discussion to the “task” field (“What is stopping task A from progressing?”), the manager can eliminate a common problem such as getting personal (“Why is it taking so long to solve task A?”).
E. Joint improvement, experimental development
In the context of IT project implementation, Kanban provides critical metrics (such as cumulative CFD flowcharts) that can provide real insight into:
the current state of the IT project;
some idea of the projected schedule for the future;
some critical data is needed for planning.
All of this information ties into existing management reporting structures and can provide an even more realistic view of the actual status of a project than, say, a Gantt chart.
Since Kanban is a continuous flow, it is possible and necessary to discuss changing a workflow item at any time. As a rule, this is due to the chronic state of the process phase, which becomes the “bottleneck”. This requires the team to find a solution to the problem to eliminate the bottleneck or improve the flow. Ideally, such a solution is based on reliable empirical data showing the constant occurrence of bottlenecks in this phase.
Once a decision is made on an improvement option, it should be scheduled like any other task, adding it to the initial phase; in our case, this is the backlog, and then implementing it. As the metrics gathering continues, the team can objectively determine whether the idea has improved or worsened the team's performance.
The theory behind this core Kanban practice is that problems are identified from a long-term perspective, fact-based changes are made, and then the results are recorded to detect problems. Thus, improvement is cyclical and helps to optimize workflow continuously.
