Most recently, I started working for ScrumTrek. As part of the commissioning, all newcomers in our company are trained on open trainings of the company. And this is how my brain works, that I can learn the material well only when I can clearly convey its main theses to others. Poor my wife, colleagues and friends - how much they all had to hear from me! By the way, Itzhak Pintosevich calls this the universal method of the 3-P super-learning system.

So, as I go through the trainings, I will tell you about the knowledge gained through the eyes of the participant. Of course, for ScrumTrek, this is an advertisement. Although I personally hope that the chosen format will help with the answer to the question: does this training need you or your colleagues?
')
The uncommonly diverse composition of Certified Lean / Kanban Training participants at ScrumTrek attracted my attention only a week later, when I began to disassemble my notes. The training included representatives of not only the traditional segment: IT companies and banks - but also an industrial company and a government department. And who are the participants themselves? Developer, analyst, project managers, product manager, development department heads, personnel manager, general director of the company. We all admitted to the coach in a small practical experience in Kanban. However, many people have been actively using Scram for a long time, but now they want to scale the process from the development team to external units.



Kanban is more versatile than Scrum? How else to explain such a motley training audience. Is kanban harder to master? After all, the developers come to him, having behind him the experience of Scrum. But is the Kanban entry threshold lower? After all, it begins to be used along with developers and other divisions of companies.

Theory

Is kanban a software development process? Kanban is relatively easy to implement: just draw the work flow on the board, limit WIP, measure lead time - and no work with people is needed? If one of these questions you answered or wanted to answer in the affirmative, then you should pull up the theory.

In fact, Kanban is a method of improving service (processes), which is based on 9 values ​​and 3 principles. Why is this so important? Take, for example, the most unobvious value - understanding. She talks about the need to understand current processes before making changes to them. In this sense, Kanban distances itself from the realization of the cult of Cargo. For example, often Scrum teams diligently, but blindly (without understanding) fulfill formal regulations: there is a product owner and a Scrum master, meetings are diligently held, there are sprints. But at the same time, the fundamental principles of empiricism are violated: transparency (for example, isolated from “unpleasant” stakeholders, not inviting them for demonstrations, selectively related to feedback), inspection and adaptation (for example, there is a working product at the end of each sprint, though For some reason, the consumer doesn’t need it, and the team doesn’t do anything with it). Following this value, the trainer gave us a theory, constantly asking us questions about backfilling (understanding).

For example, such a problem. 2 of 3 lanes of the road are blocked for repairs, and then an accident occurs. A traffic jam is quickly formed, with an average travel time of 1 hour. At this time, the repair of the road to the accident site is completed, so there are 2 additional lanes to the traffic jam. What will be the average waiting time in traffic now? And if there is a wide shoulder on the right, and the story itself takes place in Russia? How many times on average does the speed of vehicles move after the passage of an emergency site?



Or here's an example. The trainer shows us the video “ONE PIECE FLOW versus BATCH PRODUCTION”, which convincingly shows the gain in speed in small portions. And it seems to us all and everything is clear! But here’s another question the trainer is asking for backfilling: “It turns out that you can fire a lot of people if you do the work in small portions?” - returns us to the need for a deeper understanding. The correct answer: of course not. When working in large portions, some of the employees are forced to idle, so in most companies they begin to transfer them back and forth between several projects. In other words, of course, Kanban cannot do the same work faster, but it allows you to do faster the whole project as a set of works interconnected in a single stream.



Of course, WIP limits, Classes of Services, Cost of Delay, Explicit Policies and other basic Kanban tools were also covered in the lecture. But above, I tried to give the most interesting part of the theoretical part - examples of how the coach tormented us for a deep understanding of the Little law, as well as the Bernoulli law and Goldratt's theory of constraints.

getKanban game

In general, the whole training was very practical. Theory (lecture) took a small part of it. Most of the time we played the game getKanban. I will describe how it was and what lessons we learned.



We broke up into teams of 6 people: Boars (and why not Kanbanas?), Gazmyas and Romashka. Each team leader gave a Kanban-board on the table, laid out papers of work on it, as if 9 day of work were going on, and set the task: “Your company develops a web application and earns on subscribers. New features bring new subscribers. More subscribers, more profit. Your goal is to maximize profits. Your task is to optimize the flow of work. "



During the game, we noted the performance of our work on the control chart (Run Chart), the lead time distribution chart (Lead Time Distribution Chart) and the cumulative chart (Cumulative Flow Diagram), and also considered the profit from the accumulated subscriptions.







By CFD, it is clear that by the end of the game, the Gazmas team learned to systematically roll any work in just one day! Actually, this was the reason for the victory of Gazmyas in the overall standings of the three teams.



Time for the game flew by! After the game, the coach helped us consolidate our lessons. So what have we learned?

1. The game allowed to feel the mechanics of the flow of work, the danger of accumulating the queue and the inertia of its resorption. After training on the way to the subway, I looked at the traffic jam on the Garden Ring, but I saw a stream. An ambulance with the flashing beacon and siren turned on rapidly along Expedite lane. Radish drivers disrupted traffic in the lanes, which increased WIP, helping traffic to grow. I put in a good, is not it?
2. We have seen how reducing the limit on the amount of work in progress increases its speed. I remember well the moment when the first time Cycle time became equal to one day. Feeling: “Incredible, here it is!” But there was a slight distrust: “Maybe we were just lucky this time, are these bones?” - at least, we were scared to reduce WIP limits even more. But then success repeated 2 more times in a row. I think that it was at this moment that we really learned the previously obtained theoretical knowledge of Kanban.

In fact, the list of lessons is longer. Above, I cited only the most important lessons (revelations) that can only be gained in practice, in this case as part of the game.

Practice

On the second day, we analyzed the real situations in the companies where we work, building a Kanban system for them. For obvious reasons, I will not give a detailed description of the cases analyzed.

Conclusion

Judging by the list of participants, the training is useful not only for teams at the start of Kanban implementation in the development process, but also for companies that want to build a transparent end-to-end process. Total, what gives training in a large cell? Theory with questions for understanding. The game is to experience the theory in practice. Analysis of real examples of your companies in order to apply their knowledge in business. Neither subtract nor add?