Dashboard or scrum

As the agile VP came to China, kanban became a hot topic in this discussion. Many teams are using dashboards to replace previous scrum.

Kanban originated from Toyota and is a classic representative of the Toyota generation model. Almost every company studying Toyota TPS unconsciously regards Kanban as the first model to be introduced because it is intuitive and effective. Agile visualization is a very important element and naturally comes to mind the concept of Kanban. What are the characteristics of Kanban?

In traditional TPS, panel has many types, such as inter-process, intra-process, signal, and external Association. Take the process room as an example. When the post-tool requires some parts, it writes the requirements (including specifications, quantities, and so on) to the dashboard and submits them to the previous process, then, the previous process needs to be produced according to the Kanban instructions. After the production is complete, the parts and Kanban should be submitted to the zero notice area next to the production line, parts produced without Kanban will be held accountable by supervisors. This is a typical embodiment of the Toyota PULL model. There are two characteristics here: one is that the production line can flow only when the requirements of the subsequent process are put forward; the other is that the requirements must be clear, including specifications and quantity. This clarifies the WIP capability of a production line.

How can these concepts be embodied in software development? Today, the software process has evolved into a layer of beautiful clothes or needs analysis-> Design-> Implementation-> test-> handover. In this way, each step can be regarded as a tool, and each tool has corresponding personnel, such as how many ba, how many developers and testers, and how many implementers. Their capabilities are definite. Therefore, when assigning ratio personnel, you need to consider balanced production flow between different processes to avoid waste. For example, if you have 4 implementers, each person can implement 2 stories, but only 2 tests, each test can only test two stories at the same time, so the implementation of the production capacity is twice the test, there will be a waste of manpower in the implementation phase. In this case, either the implementer has the same testing capability or the ratio of testing or implementation is increased or decreased. Each process requires a clear understanding of its own energy. When the energy reaches the upper limit, it is necessary to stop the new task from flowing in. When the task fails to flow out smoothly for various reasons, it is necessary to stop the entire production line immediately, and all the personnel concentrate on the task congestion, focus on troubleshooting. Until the problem is solved, the workflow returns normally.

Therefore, Kanban is actually nothing unusual, but the granularity and angle of control are different. Scrum should be organized according to the iteration, and the productivity is based entirely on the strength of the team. For example, for a iteration2-4 Week, a story must complete analysis-Development-test before starting the next one. However, kanban does not have a strong concept of time period. It allows some pool phenomena in each process, but pay attention to the depth of water. So scrum seems to be more suitable for general milestone-specific project development, while Kanban is better suited to online software or maintenance software. For example, our company's ERP has more than 30 years of history and has accumulated tens of thousands of bugs with honor. These bugs only need to be repaired. Each release can be repaired as much as possible, therefore, if the Po is free, the priority of these bugs will be assigned, and then it will be thrown into the backlog. Then the BA will come up with the top several to refine the configuration, and the Development will be responsible for repair and testing, the document is responsible for adjusting the old document. Is it like a pipeline job? For online software, because it is a permanent beta version, there will also be a variety of feedback every day, so these feedback will go through a similar process, the go live tool is added.

In fact, what impressed Toyota most is their courage and determination to continuously improve. As a software company, what we need most is not a tool like panel, but a kind of spirit behind it, the spirit that keeps forging ahead and never meets. With this spirit, all tools are cloudification. Isn't it better to ride your own magic horse?