09 Lean Thinking Board, Lean Driven Agile Development Methods ( Below)

09 Lean Thinking Board, Lean-Driven Agile Development Methods (Below) #

Hello, I’m Shi Xuefeng. In the previous lesson, I introduced two common agile frameworks: Scrum and Lean Kanban. I emphasized that focusing on value stream is the core concept of Lean, and limiting work in progress is the core practice. In addition, I introduced the first step of implementing Lean Kanban: visualizing the workflow. Today, I will continue to explain the remaining four steps.

Before we begin, if you are more interested in tool usage, I will share a document about common tool configurations and usage. You can download it from the cloud storage with the extraction code “mrtd”.

Alright, let’s officially start today’s content.

Step 2: Define Clear Rules #

After completing the visualization flow, the outline of the kanban board is formed. The next thing you need to do is define clear rules.

The significance of visualization lies not only in making things visible, but also in making them understandable. After working for a long time, we often have a feeling that the cost of communication is even greater than the cost of work. The main purpose of communication is to synchronize and convey information. If there is a way to improve the efficiency of information transmission, wouldn’t it be great?

And the kanban board has an important purpose, which is visualizing the status. All team members can understand the current task status, bottlenecks in the process, task dependencies, and other information through the kanban board. This enables them to spontaneously take appropriate actions to ensure smooth value delivery and the orderly progress of the entire project.

Of course, to achieve this, visualizing the flow alone is far from enough. You also need to incorporate certain rules into the design of the kanban board. These rules can greatly reduce the cost of communication among team members, unify the team’s communication language, and form tacit understanding among team members. Kanban board rules consist of two aspects: visualization rules and explicit rules, let me introduce them separately.

1. Visualization rules.

In the previous lesson, we mentioned that the main elements of a kanban board are “columns and rows”. In fact, the design of cards in the kanban board also requires attention, mainly in three aspects:

Card color: Used to differentiate different types of tasks, such as requirements (green), defects (red), and improvement items (blue).
Card content: Used to display important information of tasks, such as the electronic kanban ID, name, description, owner, estimated workload, and lead time.
Card dependencies and blocking status: Used to draw attention, such as pasting different symbols on the cards to indicate the health of the current cards. For cards with dependencies and blocking status, the team needs to prioritize coordination and handling. This way, the kanban board becomes clear in terms of priorities.

2. Explicit rules.

The kanban board not only needs to be understandable but also needs to be easy to operate. This is very important. Especially in the early stages of introducing the kanban board, everyone is relatively unfamiliar with this new thing, so it is particularly important to define clear operational rules. Moreover, before the team becomes accustomed to the operations, it needs to be repeatedly emphasized to deepen the team’s impression and gradually cultivate team habits. Once the team is accustomed to using the kanban board, the efficiency will be greatly improved. These rules include:

Who is responsible for organizing and moving the cards?
When should the cards be operated?
What are the steps for card operations? (For example, marking the card once it has stayed for a day.)
When should offline communication take place? (For example, for defects and blockers)
Which indicators represent the highest priority tasks?
What are the rules for filling in the kanban cards?
Who ensures the consistency of offline and online kanban board states?

As the saying goes, these rules may have always existed within the team as a tacit understanding, but by visualizing them on the kanban board, there are great benefits in terms of clarifying the rules, enabling newcomers to quickly get started, and promoting continuous improvement within the team.

Step 3: Limiting the Number of Work in Progress (WIP) #

Limiting the number of work in progress (WIP) is the core of Kanban, and it is also the most challenging aspect. The main question is, how many is the appropriate limit for WIP?

To answer this question, we need to be clear about one thing: applying the Kanban method can only expose the existing problems of a team, but it cannot solve them.

What does this mean? It means that when there is no limit on WIP, the team’s delivery time and quality will be affected. The reasons behind this could be inadequate control of requirements, insufficient release frequency, inadequate automation to support rapid delivery, dependencies between teams, and strong coupling in system architecture… These are inherent problems of the team that cannot be solved simply by using the Kanban method.

However, the advantage of the Kanban method is that by reducing the number of WIP, these potential problems can gradually be exposed. For example, in an extreme case, let’s say we set the limit of WIP to 1, which means the team is only working on one requirement at a time. In theory, the lead time for delivery will significantly decrease. However, in reality, the team may find that due to the unavailability of the testing environment, acceptance of delivery cannot be completed, or the delivery window is too long and missing one window means waiting for another 2 weeks. In the end, the goal of achieving rapid delivery value cannot be met. The reasons here lie in the issues with the initialization of the testing environment and delivery frequency. These are inherent problems of the team, but they did not manifest when there was no high demand for delivery rhythm.

Therefore, if you can adjust your mindset and face the inherent problems of the team, you will understand that limiting the number of WIP is not just about fixating on a number. In my opinion, there are two key points in limiting the number of WIP: the demand inflow point and the demand outflow point.

1. Demand inflow point.

The key here is to limit the inflow of demand. You may think this is unreliable because when facing aggressive business stakeholders, the development team can only play the role of a meek sheep. After all, as long as you dare to say “no,” the business stakeholders will immediately send emails to cc your boss.

In fact, the competition of requirements is a perennial topic. Which development manager has not experienced dozens or hundreds of intense battles over requirements? I have previously faced intense competition of requirements within the same project team, which made me prepare to be kicked out. However, later on, we discovered that in the end, we are all in the same boat. With limited resources, there is not much difference in delivery time between handling 100 requirements at a time or handling 10 requirements at a time. Therefore, limiting the number of WIP is just a different way of competing for requirements. It changes from a situation where the business stakeholders provide a large number of requirements and get the development team to schedule them, to a situation where the number of parallel tasks is limited based on the priority of the requirements.

Of course, the development team must commit to delivering high-priority requirements as quickly as possible. If the business stakeholders see that the requirements are being delivered on time or even earlier than expected, they will gradually get used to this approach, and trust between teams will gradually be established.

2. Demand outflow point.

The key here is to accelerate the outflow of demand. In a typical Kanban, the backlog of the “ready to deploy” column is the most likely to accumulate because deployment activities often have to be scheduled according to the project’s rhythm, and a dedicated team performs them during specific time windows. If a large number of requirements accumulate in the backlog, there is a reason to push for faster release rhythm downstream, or to find a more flexible way to release.

After all, “You build it, you run it” is the principle advocated by DevOps, and it is also a classic team principle of Amazon. It means that the development team is responsible for the business’s release, and each release unit is independent without strong dependencies on each other, thereby achieving team self-reliance. By establishing the capability of safe release and making release a routine task, it truly contributes to the rapid delivery of the value of demands. In simple terms, if you want to be agile in business, you have to release as soon as you develop, completing one before moving on to the next.

As for what the limit of WIP should be, my suggestion is to adopt a progressive optimization approach. You can start from the number of team members and the current state of requirements, and set an agreement based on the number of tasks currently being processed, as long as it does not overload each developer, such as limiting parallel tasks to no more than three. Then observe the backlog situation in each stage and make adjustments through the practice of Step 4, ultimately achieving a stable and efficient state.

Step 4: Managing Workflow #

In the column Lesson 5, I mentioned the value-added and non-value-added activities in lean theory, and meetings are generally classified as non-value-added activities. As a result, some people may have the misconception: “Shouldn’t all non-value-added activities be eliminated to achieve the highest flow efficiency?”

If you think this way, does that mean roles like project managers are no longer needed? After all, they don’t seem to be directly involved in software development activities. Obviously, this is a very one-sided idea. In fact, in lean non-value-added activities, there can be further division into necessary non-value-added activities and unnecessary ones. Some meetings, although not directly value-added, are still very necessary. Therefore, we cannot simply think that lean means no meetings and no approvals.

The Kanban method is also rooted in the daily activities of the organization, so a complementary management process is needed to ensure the smooth operation of the Kanban mechanism. In the Kanban method, there are three common types of meetings: daily stand-up, queue replenishment, and release planning meetings.

1. Daily Stand-Up Meeting

Teams familiar with agile should be very familiar with the daily stand-up. However, compared to the “Three Questions of Death” in the Scrum method (“What did you do yesterday? What do you plan to do today? Are there any obstacles or blockers?”), the stand-up in the Kanban method is slightly different. Because in the second step, we have established clear rules and the team’s current situation is already clear, so we just need to sync up on key tasks. The Kanban method focuses more on:

Tasks waiting to be delivered. Kanban pursues the quick flow of value, so for tasks that are blocked in the delivery phase, you need to focus on the reasons behind it.
Urgent, defect-fixing, blocking, and long-unused tasks. These tasks also have corresponding definitions in the rules. If these issues occur, the team needs to handle them with the highest priority. Here is a little trick: When a card is placed on the Kanban board, the person responsible for the card will manually add a small dot mark for each day it stays. By counting the number of these marks, you can see which tasks have been stuck for too long. For teams using electronic Kanban boards, this is even easier. For example, Jira itself supports displaying the duration of staying. Of course, you can also create your own filters to sort by duration of staying and focus on the top issues.

The daily stand-up meeting should be kept as efficient as possible. For some controversial issues or discussions on technical details, they can be discussed separately after the meeting. At the same time, the organizer of the meeting should observe the execution of the daily stand-up as much as possible. If there are pauses or the meeting is not smooth, it means that there is room for improvement in the rules. For example, if daily stand-up relies on an organizer to drive the entire process and the team remains silent as long as that person does not ask questions, it means that the rules are not clear enough. In addition, for any inspirations or good ideas that emerge during the meeting, they should be recorded and followed up as optimization items.

2. Queue Replenishment Meeting

The goal of the queue replenishment meeting is twofold: prioritizing tasks and displaying the status of demand development. In general, the queue replenishment meeting requires participation from business, technical, and product project stakeholders to reach a consensus on the prioritization of requirements and fill them into the ready state on the Kanban board.

In the early stages, I recommend holding this meeting at a fixed time each week, as this helps the entire team share the rhythm of demand delivery, understand the status of demand delivery, and help establish a good cooperation and trust relationship between business and technical sides. During the meeting, discussions and adjustments regarding the number of work in progress can also be made.

3. Release Planning Meeting

The goal of the release planning meeting is to achieve final delivery. In general, the project delivery rhythm will affect the queue replenishment rhythm, and it is best to keep them synchronized. In addition, with the separation of deployment and release, the development team is getting closer to continuous development and continuous deployment, while release planning is controlled and planned by the business side. The release planning meeting helps synchronize information between the development team and the business side, thereby achieving the ideal state of rhythmic deployment and on-demand release.

Step 5: Establish Feedback and Continuous Improvement #

In fact, whether it is DevOps or Lean Kanban, the ultimate goal of any method or framework is continuous improvement. Because as a new development mindset and method, it can better serve the business only if it is combined with the actual business situation and continuously optimized in terms of rules, rhythms, tools, and processes. I will provide a detailed introduction to measurement and continuous improvement in this part. You should always remember that there is no naturally perfect solution, only continuously optimized solutions. The practice of the Kanban method is a gradual process. Therefore, David J Anderson, the founder of Kanban, summarized the maturity model of the Kanban method to guide medium and large teams in the practice of the Kanban method, as shown in the following figure:

Image source: http://leankanban.com/kmm/

This model divides the maturity of Kanban into 7 levels. In addition, it provides specific capability references for each practice dimension at each level, which has a strong guiding role in the implementation of the Kanban method and can be used to benchmark existing capability maps.

If you want more detailed information, you can click on the link I shared with you at the beginning of this lecture as a supplementary reference.

Summary #

Okay, let’s summarize. In these two lectures, I first introduced the background and origin of kanban to you. Kanban originated from the manufacturing industry and is a commonly used method of production signal transmission. Kanban is also a core tool of lean production represented by the Toyota Production System, which is a demand-driven production approach.

Next, I discussed with you why it is necessary to limit the number of work in progress (WIP) and the underlying concept of shortening the lead time of delivery, in order to establish a cooperative and trusting relationship between the business side and the IT department, and to achieve quick, high-quality, and predictable delivery.

In addition, I introduced you to the five core practices of lean kanban, including visualizing the flow, defining clear policies, limiting WIP, managing the workflow, and establishing continuous feedback for improvement. Mastering these practices will give you the key to embark on the lean kanban journey. After actually implementing these practices, I believe you will gain more insights and achievements.

I want to remind you that rigid practices without considering people are the biggest obstacles to implementing lean kanban within an organization. As mentioned in “The Toyota Way,” continuous improvement and respect for people are the ultimate coordinates for all improvement methods, and this is something we must pay attention to.

Thought Question #

Finally, I have a thought question for you: If you were tasked with implementing the Lean Kanban method within a team right now, what challenges do you think you would face?

Feel free to share your thoughts and answers in the comments section. Let’s discuss and learn together. If you found this article helpful, please feel free to share it with your friends.