08 Lean Thinking Board, Lean-Driven Agile Development Methods (Above) #
Hello, I’m Shi Xuefeng.
When it comes to Agile development methods, you probably can’t help but think of bi-weekly iterations, daily stand-ups, and requirement breakdowns. Indeed, as a fast and flexible development model that embraces change, Agile has been widely recognized in the industry. However, even though the Agile Manifesto has been published for nearly 20 years, many companies are still struggling with Agile transformation, and there are numerous cases of failed transformations.
I once came across a company that was once heavily promoting Agile. However, many of their so-called Agile coaches were also project managers, and their thinking and working habits were still in a project-based mindset. Despite having well-structured daily stand-ups and boards everywhere, there were no significant changes in the delivery results of the products. Shortly thereafter, due to organizational restructuring, the ambitious Agile transformation project came to an end.
Although this company superficially adopted popular Agile practices and introduced Agile tools, the team did not reach a consensus on the value of Agile. The team leaders also served as Scrum Masters, turning the daily stand-ups into daily work performance meetings. At the Agile retrospective meetings, the leaders even proclaimed, “Agile is about eliminating change; our goal is to ensure that the team follows the plan.” This kind of “in name only” Agile does not help companies achieve the expected benefits of agile response to change and rapid value delivery.
As the most widely used Agile framework, many concepts and practices of Scrum are well-established, such that often iterative development is almost synonymous with Agile development. However, Scrum’s definition of roles is not easy to understand, and if organizational change is involved in implementing Scrum, progress can be difficult.
In reality, there is no universal path for an enterprise’s Agile transformation, and there is no fixed method to follow. Today, let’s talk about another mainstream Agile development method - Lean Kanban. Compared to Scrum, the incremental changes in the Kanban method are more easily accepted by teams. In my previous team, through long-term practice of the Kanban method, not only did product deliveries become smoother, but the overall capabilities of the team were also enhanced.
So, what is this magical Lean Kanban all about?
If you haven’t heard of Lean Kanban before, it’s necessary to briefly understand its background. In fact, “Kanban” is a Japanese term that refers to billboards that can be seen everywhere in daily life. In the context of production manufacturing systems, Kanban is used as a signal card primarily for information transfer. Many people think that Kanban was created by Toyota, but that’s not entirely true. For example, in the Nikon manufacturing workshop where I used to work, Kanban was also widely used.
Of course, the reason why Kanban is widely known is also due to the Toyota Production System. The book “The Machine That Changed the World” first mentioned the famous Toyota Just-in-Time (JIT) production system, and Kanban is a core tool in it.
Simply put, the Kanban system is a pull-type production system. Unlike traditional large-scale batch production, Kanban adopts a just-in-time production approach. This means that downstream processes notify upstream processes of the parts and quantities to be produced through Kanban when they are needed, and then the upstream processes start production.
In other words, pull-type production starts with the needs of the end consumer and works backwards. It produces only what is needed, rather than producing a large amount of things that no one wants. This reduces inventory, accelerates the flow of work-in-progress, and enables flexible response to change. Here is an image that illustrates the operation of the entire Toyota production system for your reference.
Image Source: https://www.toyota-europe.com/world-of-toyota/this-is-toyota/toyota-production-system
The Kanban method in software development borrows the Lean thinking of the Toyota Production System and similarly focuses on limiting work-in-progress and accelerating the flow of value. In other words, if there is no pull system with work-in-progress constraints, it can only be considered a visual system, not a Kanban system. This point is very important.
For example, many teams use Jira and establish boards that cover various stages of development for collaboration, but this is a typical visual board, not a Kanban board. So, why is work-in-progress constraint so important for Kanban method?
As mentioned earlier, accelerating the flow of value is the core of Lean Kanban. In software development, this value could be a new feature, a bug fix, or an experience improvement. According to Little’s Law, we know that average throughput equals work-in-progress divided by average lead time. Work-in-progress represents the number of work items that the team is actively working on in parallel. You should be familiar with lead time, which is a core metric for measuring the output effectiveness of DevOps. It represents the time from the start of development for a requirement to delivery and release. For example, let’s say there is only one refueling equipment at a gas station, and the average refueling time for each vehicle is 5 minutes. If there are 10 vehicles waiting, then the lead time would be 50 minutes.
However, this assumption is based on the condition that all the work in the queue is executed in sequential order. In actual software development, if a developer is working on 10 tasks simultaneously, the actual time invested in each task is not 1/10.
Taking the previous example, if one refueling equipment has to refuel 10 vehicles, it means that the actions before and after refueling each vehicle have to be repeated, such as taking out the refueling gun and moving the vehicles. This results in a significant resource consumption due to task switching costs, which leads to a much longer time to fully refuel a vehicle than 5 minutes.
Therefore, the quantity of work in progress affects lead time, and the more tasks being done in parallel, the longer the lead time, which means longer delivery cycles. This is clearly not an ideal situation.
Moreover, lead time also affects delivery quality, with an increase in lead time resulting in a decrease in quality. This is not difficult to understand. As the number of tasks increases, complexity also increases, and task switching always leads to mistakes. Additionally, human memory is not always reliable. At the beginning of a project, the understanding of a requirement is the clearest, but after some time, it becomes difficult to recall the details. At this point, if someone relies on their own understanding to complete the task, it is highly likely to result in a significant amount of rework due to misinterpretation of the requirement.
Furthermore, in software development, various changes and unexpected events always occur. If the delivery cycle is longer than the rate of requirement changes, it means there will be more urgent tasks. For example, if a boss discovers a critical online bug that needs to be fixed with high priority, similar urgent tasks will increase the number of work in progress. As a result, the team falls into a downward spiral, which has a very negative impact on team morale and delivery expectations. Sometimes, 90% of a team’s effort is focused on fixing issues, leaving no time for delivering requirements and innovation.
An even more serious problem is that at this point, the trust in the IT department from the business department will decrease significantly. The business department may think, “Since we cannot predict the delivery of requirements, then I will just submit a bunch of requirements at once.” This further leads to an increase in work in progress.
It can be seen that a small amount of work in progress affects the confidence of the entire development team. I have summarized the interconnections mentioned earlier in the following diagram:
Of course, regarding the example of the gas station earlier, you might say, “Why not add more refueling equipment? Why rely on the same machine?” Indeed, when there are too many parallel tasks, adding more resources can help alleviate the problem to some extent, but there is a limit to reducing lead time. This is similar to having 10 people complete one month’s worth of work in 3 days with the help of 100 people, as discussed in the classic software engineering management book “The Mythical Man-Month”. The communication cost between people increases exponentially with the increase in the number of people. Also, in the short term, the addition of new team members may even slow down the original delivery speed due factors such as internal training and adaptation to the environment.
By understanding the core principles of lean kanban and the importance of limiting work in progress, we can grasp the correct direction of kanban practices. So, how do we start implementing the lean kanban method step by step within a team? And what are the common pitfalls and countermeasures during the implementation process? These are the key points I want to share with you. I have divided the implementation of the lean kanban method into five steps.
- Step 1: Visualize the workflow;
- Step 2: Define clear rules;
- Step 3: Limit work in progress;
- Step 4: Manage the workflow;
- Step 5: Establish feedback and continuous improvement.
Today, I will introduce the first step of the lean kanban implementation method: visualizing the workflow. In the next lecture, I will continue to discuss the remaining four steps.
Step 1: Visualization of the Flow #
In the Kanban method, improving the flow efficiency of value and delivering customer value quickly are the core principles. Therefore, the first step is to clarify the value delivery process and make the process visualized through modeling the existing process. I have already introduced the topic of value stream modeling in the 5th lesson of the column. If you don’t remember, don’t forget to review it.
In fact, within an organization, regardless of the development model used or the organizational structure, the value delivery process has always existed. Therefore, in the beginning, we just need to faithfully and objectively present the existing process, without optimizing and adjusting the existing process. It is also because of this that the introduction of the Kanban method brings relatively small impact to the organization in the initial stage and will not cause strong discomfort or even backlash due to radical changes. Therefore, the Kanban method is a relatively gentle and progressive improvement method.
Next, we can define the Kanban based on the value stream. There is no standard style for the design of the Kanban because the value streams of each organization are different. For teams that have just started using the Kanban method, the main elements of the Kanban can be summarized simply as “one column, one row”.
1. One column.
This refers to the vertical queue of the Kanban, which is divided into various main stages according to the flow of value, such as common stages like requirements, development, testing, and release. Each identified column can be further divided into two states: “in progress” and “done”. This is also a significant characteristic of the lean Kanban pull production. The granularity of column division can be very detailed, such as further subdividing the development stage into design, coding, self-testing, review, and testing, or just treating it as a separate development stage. The criteria for division mainly include:
- Whether it constitutes an independent stage. For example, for development with frontend and backend separation, frontend development and backend development are two independent stages generally handled by different roles, which are more suitable for independent stages.
- Whether there is flow and handover of states. Kanban is a signal card that drives upstream and downstream collaboration, so we need to pay close attention to stages with upstream and downstream deliveries and reviews. These are also key nodes that indicate delivery throughput and lead time.
In addition to these, the design of the Kanban needs to define clear starting and ending points. For the lean Kanban, covering the complete end-to-end value delivery process is an ideal state. However, in reality, when starting to implement the Kanban method, due to various factors such as organizational structure and team division of labor, it is only possible to establish Kanbans in partial stages that can be managed, such as development and testing stages. This is not a big problem. After optimizing the output effect in the local stage, we can try to extend forward or backward.
Furthermore, even if the Kanban can cover the complete end-to-end process, the focus of each main stage is different, so the Kanban may also use the method of classification and grading. For the development Kanban, the starting point is generally when the requirements are ready, which means that the requirements have been analyzed, reviewed, designed, and communicated and agreed upon with the development team, and the endpoint can be the state of testing or release. The starting and ending points of the process should also be reflected in the Kanban design to indicate a complete workflow in the local stage.
2. One row.
This refers to the horizontal swimlane of the Kanban. Swimlanes are used to distinguish requirements from each other, especially when using physical Kanbans, confusion may often occur due to the arbitrary placement of sticky notes. Defining swimlanes can solve this problem well. For example, different lanes are marked on highways, so vehicles can travel in their respective lanes.
Of course, swimlanes have more significance than that. Swimlanes can also be divided according to different dimensions. For example, in some Kanban designs, an emergency lane is added to meet the insertion of urgent requirements. In addition, non-business related technical improvement requirements can also be handled in separate swimlanes. For projects with frontend and backend separation, a requirement can be split into frontend and backend tasks, and acceptance can only be performed when both the frontend and backend tasks are completed. In this case, the frontend and backend tasks can be placed in the same swimlane to reflect the relationship between requirements and tasks, as well as the dependency between tasks, and to quickly identify the bottleneck that currently blocks delivery.
Of course, there are no hard rules for Kanban design. In our team’s Kanban, there are often areas for suspended requirements, defect areas, and technological exploration areas, which are used to manage specific types of issues. For example, for long-standing suspended requirements, they can be removed from the Kanban after a certain period of time. After all, if a requirement has not entered the task queue for several months, it may not be a real requirement. These can be flexibly arranged based on the actual situation of the team. If you use tools like Jira, although there is no concept of areas, it can be realized through swimlanes. For example, distinguish swimlanes based on epic tasks and then create epic tasks for corresponding areas.
Summary #
Today, I introduced two commonly used agile frameworks, Scrum and Kanban. Kanban originated from the Toyota Production System and is characterized by its pull production approach. The core of lean Kanban is to focus on value flow and accelerate it. Limiting the number of work-in-progress items is a core practice, as it directly affects the team’s delivery cycle, product quality, and even trust between teams, leading to a downward spiral.
Practicing lean Kanban in a team can be divided into five steps: visualizing the process, defining clear rules, limiting the number of work-in-progress items, managing the workflow, and establishing feedback and continuous improvement. Today, I introduced the first step, which is visualizing the process. By visualizing the team’s delivery path through value stream mapping, the main structure of the Kanban board is established. The next step is to start applying Kanban. In the next lesson, I will discuss the remaining four steps. Stay tuned.
Thought question #
Finally, let me leave you with a thought question: Is your company also practicing agile? In the process of agile transformation, what was the biggest problem you encountered and the biggest pitfall you stumbled upon?
Feel free to write your thoughts and answers in the comment section. Let’s discuss and learn together. If you find this article helpful, please share it with your friends.