Kanban is a very common task management mechanism. Kanban is found in most of the team collaboration tools we use, such as Tower, Teambition, Trello, Github, Gitlab…

Kanban can be used not only for teamwork, but also for personal time management and optimization. But do you really know how to use kanban?


Kanban is an important concept in Toyota’s production model. It refers to a tool for controlling on-site production processes in a just-in-time (JIT) manner. The pull production system in the just-in-time production mode can shorten the flow of information, and cooperate with quantitative, fixed loading containers and other ways, so that the material flow smoothly in the production process.

The following points to note from the above definition:

  • Just-in-time Production – this is a management strategy that improves the return on business investment by reducing inventory and associated collateral costs during production.
  • Control of the scene– Kanban is a kind ofThe reduction ofandThe site controlmethods
  • Pull production system– Traditional software development usesPush (Push) modelThat is, a task is to be completed by a designated person within a specified time. A pull production system, on the other hand, is more like a producer-consumer model, where kanban is a signal, etc., that when upstream has completed tasks, it tells downstream to start processing those tasks
  • Quantitative – Each part of the process has a fixed bandwidth, which helps expose bottlenecks in the process


Kanban is summed up very well in “Analysis of Lean Product Development (I) — Kanban Development Method”. The essence of kanban tool is: when needed, the next process sends a signal through kanban to the previous process — please give me the required amount of input, and the previous process can only produce on demand after getting kanban. Kanban signals are transmitted from downstream to upstream, pulling upstream production activities and making products flow downstream. The source of the pull is the most upstream customer value, which is the customer order or demand.

The following steps will introduce the stages of kanban application. If your team is still stuck in phase one, try moving on.


The article Outlines

  • Step 1: Start with the existing process and visualize the process
    • Process abstraction
    • Continuous improvement of the process
    • Kanban scope
    • Priority division
    • Push and Pull models
    • Expose bottlenecks
    • conclusion
  • Second stage: wIP restriction
    • What is wIP
    • Why restrict wIP?
    • How much is WIP limited?
  • Step 3: Incorporate Scrum
    • A quick word about Scrum
    • Merge into kanban
      • Set the Development cycle
      • Daily review
      • Process monitoring
  • Kanban day tour
    • Design the kanban
    • Create a task
    • Let’s start
  • Extended information


series

  • If I am the front end team Leader, how can I make the front end collaboration specification? 🔥
  • If I am the front end team Leader, how can I do a good summary design
  • If I am the front end team Leader, how to use Kanban to manage tasks well?


Step 1: Start with the existing process and visualize the process

Visualizing the development process is the most basic use of Kanban. The above is a typical kanban example that visually describes the life cycle of a feature item and the team’s development process. It shows us a process like this:

Requirements Analysis -> Product Design -> Development -> Test -> DeploymentCopy the code


Process abstraction

Every person and every team has a different workflow. We need to sort out our workflow before designing kanban.

For example, the ‘personal’ process is very simple, with only one action: ‘do and don’t do ‘. So personal kanban usually looks like this

todo -> doing -> done
Copy the code

You’ll notice that even simple processes have three sub-modules for each part of the process: not done/doing/done. For personal kanban, the main purpose of dividing these three modules is to restore the current scene. This is even more important for teams, as you can visually track the progress of task development through kanban


Our team’s current development process is simple:

Design -> Development ->...Copy the code
  • Design: Application design, optional, usually outlined at the start of a project or important feature development
  • Development: Normal development process

Of course this is only a ‘partial’ process for the front-end team, and the complete software development process is shown in the first Kanban example. Because we’re not an ‘agile’ team, we just do front-end development. The big picture is that requirements analysis, product design, testing, and deployment are beyond our control. So it should not be generalized into our development process.


Continuous improvement of the process

Processes are not static; they evolve with practice. For example, because our team members have uneven abilities and experience, for example, new code often has bugs and details are not well done. How to solve it?

First, think about any process improvements you can make to mitigate or eliminate this and improve the quality of your code.

After much thought and discussion, we decided to add a cross-testing /Review/ ux testing session after the development session. There are three levels of meaning in this: cross-testing refers to assigning others to test, Review refers to code-level Review (white box), and user experience testing triggers acceptance testing from the user’s perspective (black box).


Here is the improved kanban (Design -> Development -> Cross test):


Kanban scope

Personal kanban with a high level of appearance


You see ‘personal Kanban,’ ‘Team Kanban,’ and ‘A Kanban that covers the entire software development process.’ You’ll find that kanban can be applied to a wide range of levels, representing tasks at different levels of granularity.

We have two kanbans inside the front end team, a weekly schedule kanban and a task Kanban.

The weekly Schedule Kanban task granularity is’ project ‘or’ major feature ‘and is used to plan and track the general tasks of the week. On the other hand, task kanban is a variety of detailed tasks, such as small features, Bug fixes, details optimization. The average granularity is less than 1 person/day, which can restore the development site of each development member to the maximum extent.


On the team collaboration level, we also have a development kanban. This is similar to the first kanban example, which reproduces a complete application development process. Each team occupies a column on the kanban to display and track the flow of information between teams:

Research and development of kanban


Priority division

In our team kanban above, we have a few special columns: Schedule/To-do week/Buffer. The main purpose of the main column is to prioritize tasks and allow the team to focus on the tasks that should be prioritized right now.

Kanban priorities can be handled in two ways:

1. Split kanban:

For example, priority sort buffer > To-do of the week > Schedule

  • Schedule – Tasks that need to be done in the near future. Some tasks are low priority and may not be dealt with for a year or six months. This column is kind of like a memo
  • Weekly Planner – Select some tasks from the planner column as’ development goals’ for the week. Say what you plan to accomplish this week
  • Buffer – Filters the highest priority tasks from the weekly schedule that need to be processed first
  • Completed (Week end Time) Place the tasks that have been completed each week. This corresponds to the weekly schedule and can give feedback on the progress of the weekly schedule.

We usually ‘file’ the completed column once a week. If you are using Tower, you can view the archive and get all the history by week


2. Set the task priority

Special labels can also be set at the task level to mark the priority of the task. In addition, high-priority tasks can be placed in front of the queue to indicate the priority of the task

Using Tower, you can set the priority of a task, and it will use different colors to mark it:


Push and Pull models

Left ear Mouse. I was impressed when he mentioned the “X and Y talent theory” in one of his programs. He pointed out that talent can be divided into two types:

  • X type talent: give task do, don’t give task don’t know what to do
  • Y type talent: self-driven, with autonomy and initiative, have a sense of belonging to the enterprise. Such people are good managers

Most people are X-type talents, so enterprises need to spend a higher salary to hire Y-type talents to manage and drive X-type talents. But I don’t think we are born with this. Given certain responsibility and encouragement, or under certain management mechanisms, we can also become Y talents or even Y teams. Many agile theories advocate ‘team autonomy’ and expect teams and their members to drive their own business. Pull patterns can also reflect this idea.

Traditional teams use the push model, in which the Leader assigns tasks to team members, specifying completion times and various indicators. This approach, also known as a Push System, relies on timing and being ‘passively’ pushed to do something when the time is up.

Kanban is great for pull mode. So kanban is also called a Signal, and you can think of a task as an ‘event’ that drives the work (similar to the producer-consumer model). It’s still a bit like an assembly line in a factory, where the upstream output is an ‘event’ and the downstream actively pulls the upstream stuff for processing.

The advantage of this model is that the Leader no longer needs to worry about the details of work assignments and decisions, leaving the team members to arrange events effectively themselves. It also avoids situations where team members are only familiar with some of the projects, or only know how to do and be responsible for one thing or another. This makes the team more passive when members leave, because other members are not familiar with their work. Pull mode, therefore, also allows team members to get out of their comfort zone and get involved and familiar with various projects

We currently use a hybrid model, where some tasks are assigned to the right person in advance, whereas if there is no leader assigned to the kanban, the task can be assigned to anyone, a combination of push and pull.


Expose bottlenecks

Sections of a process are connected like pipes with inputs and outputs:

Tasks -> (Process 1) -> (Process 2) -> DoneCopy the code

The output of the previous process (Done) is the input of the next process (Todo). Ideally, the flow of information should flow smoothly and smoothly through pipes. If a link bottleneck, so may lead to busy busy dead, idle idle dead.

If you think about it, kanban’s process management is a bit like an ‘assembly line’ in a factory. If one part of the process is blocked, it will pile up a lot of components, and the downstream part will be idle and wait, and the upstream part of the process will be blocked.


This bottleneck in the process can be easily identified through a kanban field restore. How to solve this problem?

This is analogous to a program. When we find a performance problem in a program, there are usually two directions to solve it:

  • Is it an algorithm problem? Can you use a better algorithm or solution? Corresponding to the development task, to consider whether the implementation of the wrong way?
  • If it is the bottleneck of hardware, can you expand hardware resources and upgrade better hardware? For development tasks, consider whether to add more people?

In the next section, I’ll show you how to make it easier for Kanban to expose bottlenecks by setting wIP (bandwidth).


conclusion

With Kanban we can get these benefits:

  • Process visualization: Kanban allows you to see what steps a task will go through and where it is currently
  • Restore development site:
    • Visually track development progress
    • Exposing process bottlenecks
    • Contribution visible
  • Pull mode: Self-driven





Second stage: wIP restriction

Most teams use Kanban only at the first level, which is process visualization. The appeal of Kanban goes beyond that. The second stage is to start limiting wIP.


What is wIP

Work-in-process (WIP), also known as semi-finished products. As the name suggests, it’s a partially unfinished task.

In kanban, some columns have work-in-process limits that limit what the segment can do at the same time. In other words, limiting the ‘bandwidth’, or throttling, of a link.


Why restrict wIP?

1. Expose bottlenecks faster

Although process bottlenecks can be identified at ‘level 1’, they are not as intuitive, at least from kanban. You may have to follow up with inquiries to understand which processes are stuck.

After limiting the WIP, the bandwidth of each link is fixed. For example, the WIP limit of the ‘test’ link is 6. If the ‘test’ link reaches the limit, the upstream cannot plug it with other tasks. This exposes a bottleneck in the ‘test’ section

How to set the WIP limit is also important. If the WIP limit is too small, the number of concurrent processing tasks will decrease and resources may not be utilized. If the WIP limit is too large, it will not expose bottlenecks. The next section describes how to set up the WIP.


2. Avoid interrupts and context switches

Another benefit of limiting WIP is to reduce the number of members that can concurrently handle multiple tasks.

As with computer processes, context switching costs are high. For developers, task interruptions and switching can also waste switching time because we need to adjust/review our thinking to get into a new task flow.

So by limiting the WIP, members can focus on the task they are working on, and then pull in new tasks.


3. Add time

When downstream congestion occurs, there may be surplus time upstream or downstream. This extra time may seem like a waste, but there’s a lot that can be done for the developer or team. Such as:

  • Break/study: Use this time to study. For the front end, it is necessary to constantly learn to improve their level and competitiveness, which is also beneficial to the project development. In the 996 environment, entrepreneurs are gradually depriving us of our ability to produce productivity.
  • Help solve the bottleneck: There is a bottleneck downstream, we can stop and help them solve the problem. For example, if other colleagues are stuck on some problems, we can help them solve the problems together. If something goes wrong in the downstream test, we can test it together. Move forward as a team to improve team cohesion and responsibility
  • Optimization: Reflect on process issues and consider how to improve productivity
  • Other things: You can cross-test and document, optimize your development tools


How much is WIP limited?

Wip limit value is not specific and computable, it needs long-term experience accumulation and running-in to determine a suitable value. The smaller the value, the more members can focus on the current issue, enhancing collaboration among members. The higher the value, the more things can be handled and the more flexible the task scheduling.

An empirical compromise formula is: WIP = team size * 2-1.





Step 3: Incorporate Scrum

Scrum is also an agile framework. Its rules are very simple, but very difficult to master. So in phase three, we can try to incorporate some of the Scrum rules into the kanban management process


A quick word about Scrum

A typical Scrum process is shown above.

In short, Scrum begins by breaking up the application development process into multiple iterations, called sprints (sprints), which typically last 1-4 weeks.


At the start of each Sprint, the Product Backlog is screened for tasks that can be completed by the Sprint in terms of priority and time assessment. Then focus on these tasks during the iteration cycle

Scrum also defines activities for continuous feedback and adjustment, such as:

  • Sprint Planning meeting – Before starting a Sprint, plan what tasks need to be done in a cycle and evaluate the time of the tasks
  • Daily stand-up meeting – synchronizes development progress, identifies obstacles in development, increases communication and communication
  • Review meeting – held at the end of the sprint to review planned work, what was done and what was not. Some teams will have the lead of the feature demonstrate what they have done, and then the PM will see if the feature meets the requirements
  • Retrospective meeting – Held at the end of the sprint to review and reflect on the problems encountered in this iteration and how they could be improved

In addition, Scrum defines roles and values. These are beyond the scope of this article, and we will not copy them all. Interested readers can check the references


Merge into kanban

Set the Development cycle

The obvious difference between waterfall and Agile is that the development process is split into multiple iterations. Scrum is defined as a ‘sprint’.

In our actual development, we would take a week as a development cycle. I think a week is just right, it’s too long to assess the duration of the task, and there are more unknowns.

Before the week starts, select tasks to do this week from the “Plan” column and drag them into the “To do this week” column. This process is a bit like a Planning meeting for Scrum


Daily review

At the start of each day, I gather my team and ask them briefly about the progress of the task in front of the board, reviewing the previous day’s work to see if there were any obstacles. If there are obstacles, deal with them, and if tasks exceed expectations, consider whether the plan should be readjusted.

The idea is to expose problems as early as possible to keep the process running smoothly. Kanban is an important communication tool here. Daily queries are short, typically no more than 10 minutes, and the process is a bit like Scrum’s daily stand-up

In Tower, instead of dragging the card directly to the completed list after completing a mission, we click “Completed” on the last link so that we can review the completed mission the next day, and then drag it to the “Completed” column


Process monitoring

Burnout figure

Burnout charts are a common tool for tracking Scrum progress. Its appearance is as follows:

The horizontal axis is the development period, and the vertical axis is the number of tasks. Ideally, the number of tasks should be zero at the end of the period, which means that the ideal line segment is a diagonal (blue line), which is also a reference line. If the red line is higher than the blue line at a given point in time, progress is delayed; otherwise, it is ahead of schedule

With burn down charts, we typically plot a dot on the burn down chart during a daily review to indicate the amount of work that has not been completed up to this point


Cumulative flow chart

The cumulative flow chart counts the wIP in each column for each day. Thus, it can reflect the task processing rates of different links and expose bottlenecks between links:





Kanban day tour

Let’s practice the kanban usage process described in this article by imitating the classic article kanban Day Tour. The tool we use is Tower, which is also the one our team is using now. Its functions are basically sufficient.


Design the kanban

Let’s say we have a three-person front-end team and the development process goes like this: Develop -> cross-test -> deploy. Based on what we learned above, we designed a kanban layout like this:


Create a task

Now click on the Tower task creation window. Tower’s mission features are already very rich. In order to make it easier for others to handle tasks, we have some specifications for tasks


  • (1) title:Summary in [scope] (time assessment).
  • scopeRefers to the scope of the task, e.g., project A, project B
    • Time to assessAsk for an evaluation of tasks that take longer. It is generally recommended that the granularity of the task ranges from 3h to 2D. If the granularity is smaller than 3h, the task should be combined; if the granularity is larger than 2D, the task should be split
  • (2) Assign the person in charge: optional, if you do not assign the pull mode
  • â‘¢ The Deadline of the task
  • 4 Set the task priority
  • ⑤ Detailed description
  • â‘¥ Detailed tasks
  • ⑦ Dependent task
  • ⑧ Task tag: you can specify the type of task, such as function, Bug, optimization, reconstruction


Let’s start

Plan what you need this week:


Start work, sort by priority, put into buffer:


Claim your mission


Ok, we’re done. Put it in the next column



Downstream reaches wIP limit, no, need to clear, stop manual work, do a cross test



The next day, the task was not bad. Did you have any problems? Move the task formally to completed after completing the review


😫 very tired, do not write a summary, so it,

In this paper, finished!


Extended information

  • Recommend online kanban tool software? Electronic Kanban recommendations
  • Implementation rules of Kanban system
  • Lean Development and Kanban Methods
  • Analysis of Lean Product development (I) — Kanban development method
  • Scrum vs. Kanban, or Scrum + Kanban?
  • One Day in Kanban Land