Proto refill

Translator's Preface


In the Russian-speaking professional community of process managers, there is very little literature on the Kanban method in Russian. We, the Kanbanguide.ru community, have decided to correct this injustice and will publish the most significant articles from our point of view that have influenced the development of the method.

An article by David Anderson’s author of the Kanban Method reveals the features of how full-fledged, client-oriented kanban systems work with commitment and what is their difference from common practices for working with task backlogs.

Commitment pointThis is one of the key concepts of the Kanban method. In the kanban system, at this moment a commitment is made to supply a work item. Up to this point, there are many options (requests), some of which will be eliminated, and the processes are aimed at supporting the decision on the need to supply the item. After this point, it is confirmed that the customer wants to receive the item and agrees to accept the results of the work, and the service is ready to complete the delivery. From this moment begins the countdown of the execution time of the work item.

Replenishment meeting - a meeting during which work items are moved beyond the point of commitment.

Proto-kanban - organizations can use the kanban method for the evolutionary improvement of processes, but not yet apply all Kanban practices, for example, do not provide an effective balance between load and capabilities through feedback cycles, do not use service classes, etc. Such implementations are called proto-kanbans. Now, with the advent of the Kanban Maturity Model , the term has already been abandoned in favor of positioning such applications at the first levels of maturity.

More information on the basics of the Kanban method can be found in the book Kanban: a quick guide and on the website kanbanguide.ru

Proto refill


There is a class of replenishment meetings, which, it seems to me, is worth highlighting and giving them a separate name. At such meetings, the list of tasks that must be completed has already been formed, is often sorted by priority and obligations to complete them have already been fixed. I suggest calling these meetings proto-replenishment meetings. In this article, I will explain the reasons and ask you if such a name is suitable or not.


The work of replenishing such a kanban system is quite trivial. It usually occurs within a system and is based on technical, resource, qualification, or supply coordination dependencies to facilitate flow. In other words, replenishment is more related to the “criteria of readiness” (Definition of Ready, DoR) and selection based on readiness, rather than commitment, planning and sequencing of work in terms of business risks. The pool from which we select tasks is called backlog and obligations to complete tasks from it are already fixed. An agreement has already been reached with the customer that the backlog elements are included in the project boundaries and must be implemented.

At a full-fledged replenishment meeting, as described in the Kanban method, customers (service customers) are present, service requests are submitted, but obligations to satisfy them have not yet been taken.
(see The Kanban Blue Book)
«: ».  «.

Agile
». ¯\_(ツ)_/¯ (. )

Instead, the query list is considered a set of options. Replenishment consists of selecting options from the pool and discussion around the sequence of execution and appropriate planning. At the replenishment meeting, a commitment is made to fulfill the selected requests. In this case, the acceptance of obligations is actually postponed until the moment of replenishment of the kanban system and the correct pulling system is activated. Requests are pulled out of the queue when a kanban signal appears about the free capacity in the system. At a full replenishment meeting, customers not only attend, but also make decisions. The focus is turned outward and based on the view from the outside, and decisions are made evaluating the direct impact on the business of the planned delivery of the result of the work: the cost of delay is a key factor in decision making.


In another form of replenishment, as in the diagram below, the work is pushed into the system, possibly in large bundles, presumably based on faith, or on some somehow calculated idea of ​​the capacity of the system, but, in any case, it is pushed. Acceptance of obligations is not postponed. Obligations are made early, at the moment of pushing a set of requests to the system. This is a fairly common approach in large projects, they usually have a backlog of already fixed obligations. In this meeting, to replenish the kanban system is reduced to the selection of work elements for conducting them through the project workflow. The main task is to establish priority, and, as a rule, technical risks, risks associated with delivery, and risks associated with resources, are the main initial data for the selection process.At these alternative replenishment meetings, customers rarely attend, if at all, all participants are almost exclusively from the delivery side. The focus is on internal issues, and internal considerations and problems influence decision-making.


Thus, these meetings are different from those described above. Obviously, they represent a less mature and more superficial implementation of Kanban. The question is whether they should be designated as “proto-replenishment” or do we need a different, alternative name? Proto-Kanban is a well-established term commonly used to refer to Kanban boards without work in progress (WIP), although there are other options. This term was coined by Richard Turner of the Stevens Institute because case studies have shown that these proto-kanban implementations often mature into full-fledged Kanban systems. Consequently, these WIP boards were without limitation the evolutionary predecessors of Kanban, and the prefix “proto” indicates the expectation that they are a seed,from which something more mature can develop.

The question is, is proto-replenishment advisable or not? I think so. Typically, proto-kanban implementations focus on internal issues, and often they are on flight levels I and II , in the terminology introduced by Klaus Leopold.
Translator's Note
What happens when a kanban system is designed to look outside, wondering “who are our customers” and “what are they asking from us”? Then we usually see much deeper implementations, including WIP restrictions, pulling, and service classes. However, the transition from proto-replenishment to full-fledged replenishment will not happen without leadership. This transition emphasizes the true essence of Kanban implementation. If you were able to go beyond the scope of proto-replenishment, then you have implemented a pull system. This is a non-trivial step. And this is the non-trivial step that Kanban Coaching Professional (KCP) experts are called upon to help you take.

The recognition of proto-replenishment as a concept introduces a completely new way of understanding and teaches us to improve the depth of Kanban and tune the practice of application to organizational maturity. This will allow trainers and change agents to indicate the absence of deferred obligations and business risks that carry early obligations. It also gives another very clear and simple test for "do we Kanban or not." To get real Kanban, there must be customers at replenishment meetings, you should not have a backlog, you will have an options pool instead, and at the replenishment meeting, commitments will be made as you draw work into your kanban system . If this does not happen, you are still at the proto-kanban stage and you still have many opportunities for improvement.

Many thanks for participating in the translation artnek

All Articles