Geekly Articles each Day
📜 ⬆️ ⬇️

Ruthless automation. Director's cut

I want to talk about my experience in accelerating automation in a team of programmers, and about what techniques we used in practice, and what came of it.


Initial conditions


Our experiment to accelerate the work of programmers, we conducted in the following conditions:



First of all, the desire to develop arose after Jeff Sutherland's book about Scrum came into our eyes. You probably already know a lot about this technique, so I will not dwell on it. The main part of the article is not about Scrum.



So, when we read this book, we found that there is a dilemma, which is the wrong translation of the book title. The English name suggests that Scrum speeds up work four times: "The art of doing twice as much work in half the time."


And in the Russian translation it is argued that Scrum is a revolutionary method of project management. When IT managers are prepared for interviews, they are often told - pay attention to what a person is focusing on - on processes or on results. Russian translation concentrates on the process .


Why am I talking about it so confidently? I saw several dozen people alive who used Scrum. Most of them just started the Scrum process , and when you ask them: “What has changed in you?” They say: “It has become transparent, interesting, and fun”. But when you are interested in how the results have changed, whether the speed of development has increased, whether you have begun to hand over projects more quickly, it turns out that they do not know this, because they did not measure performance .



So, we read this book and launched the classic Scrum with all its main stages of the business process (they are shown in the picture).



Immediately mention the method of measurement (it will appear throughout the report). The traditional measurement method in Scrum is planning poker . It consists in the following: for each task, the team (or those of its participants who understand something in this task) is given points in points - 1, 2, 3, 5, 8 and up to 34 (figures from the Fibonacci series). According to the aggregate of estimates, the average is taken. The task is considered completed when it was accepted by the customer.


First results



What did the introduction of the classic Scrum give us? Before him, the average daily output per person was 4.2 points, and with its introduction, the figure rose to 7.73 points . It turned out that our productivity increased about two times.


Everyone liked it, we told our colleagues from other departments about it, the whole company became interested, everyone began to introduce Scrum.


But nothing happened, because everyone was fascinated by the fetish - they bought cork boards for themselves, stuck stickers on them and limited it to this. Even the owner, who was also interested in Scrum, was trolling employees: he approached the corkboard, took pictures of it, then came in a week and took pictures again - the board did not change.


I wanted more



Increasing the performance twice seemed boring to us. Therefore, I began to read the book again. On pages 54-55 I noticed some shuharis . It was written in the book that this is a principle of aikido, which read - first do everything according to the rules (shu), then begin to improvise (ha), and only then separate and create your own technique (r) .


What is interesting is that this principle was thrown out in the well-known Scrum Guide, and only “shu” remained from the “shuhari”.


And we decided to go all the way.



The basic acceleration algorithm that is recommended in Jeff Sutherland’s book is the Deming cycle . In simple words, it can be formulated as follows: you look at how your people work, you notice where they are stupid, where the delay occurs, you come up with some kind of change, you introduce and you see what happened. If it is better, faster - leave the change. If it gets worse, you remove the change. The main thing is to do it quickly.



By the way, the Theory of Constraints of Goldratt Systems speaks about the same, only concentrates on another. She says - find the narrowest link in your system, expand it or remove it. Then repeat again.


The goal, and that, and the other - to do so as quickly as possible to get the result on the full production cycle. The same idea, by the way, was expressed by the developer of the Toyota Production System - the goal of the production system is to ensure that the client’s money comes in as quickly as possible.



The role of the observer of the working process is performed by the Scrum-master. We can say that it is a coach. When you read the experience of your Scrum colleagues, they perceive the Scrum-masters as a protector and say that the Scrum-master should remove obstacles , drive away some people, help with something.


However, I am sure that the Scrum-master is an observer and a trainer who teaches his people to work faster, looks where they are stupid, helps, prompts, searches for something new, tries different combinations. As a coach in football.


The experiment team.



To get the most out of the context in which our experiment took place, you need to introduce a team. If I tell you that there were two Stas in it, Oleg and Igor - this will not tell you anything, because no one knows these people. You, plus or minus, only know me.



Therefore, instead of two Stasovs, Oleg and Igor, as a team, there will be presented characters that everyone knows and that are most similar to real people:



The next stage is improvisation.



On the very first day, when we decided to change everything, we:




In total , during this experiment, which lasted about a year, we found about 40 accelerators . I tried to group these 40 accelerators and now I’ll quickly tell you how each of them influenced the workflow.



Just in case, I will mention where these accelerators came from. There is nothing new here. I came up with some principles myself, some of my guys came up with it, we read something from books. For example, when in a book it is recommended to do something like this to solve such and such a problem, we must take it and try it. If it turns out, then leave. If there is no sense, we throw it away.


Null change



So, the first thing that started our rethinking of the process is the book "The Code of the Samurai . " I recommend that everyone read, purchase, and keep it at home. Because it was written 500 years ago, and already 500 years ago, people knew how to manage, how to obey, how to develop and how to improve.


The attention of the character, whom I call Piglet, in the “Samurai Code” attracted these two phrases. He saw that:



Piglet was so carried away by this idea that if he could not make a decision in seven breaths, he refused. Once, I even missed a merry booze.


It became interesting to me, I re-read this book once again and noticed that approximately on every 10th page it is written: in order to make decisions quickly, you need to think in advance how you will act in this or that situation.


What does it look like?


It is like a strategy when you have rules for making decisions .
How in our country most often imagine a strategy? When you ask someone: “What is the strategy of your company?”, They show you a long “bagwalker”, where it says what they will do this year - what company plans, budgets, tasks, how they will grow in sales and t .d


This definition is not close to me, it is not suitable for my purposes.


Therefore, we left for ourselves only the second definition and began to perceive the strategy only as a set of rules for decision-making .


Accordingly, the zero change that we introduced to our Scrum process was that, trying new accelerating techniques in our team, we formulate principles for them , give them names (to make it easier to memorize and discuss), and use further in our work . These principles are the carriers of everything else.


The main secret of improvements



The next fundamental principle to which we have come is the "main secret of improvement . "


Believe it or not, but we have brought out the “main secret of the improvements”, the effectiveness of which we have seen many times.


It can be formulated as follows: 75% of problems in change arise because people do not work as they were told.


Why is this happening? The fact is that people who are trying to implement changes (for example, Scrum) come and say to their subordinates: "You are now working in a new way." And then just go. And when they return in a week or two, they see that there are no results. And in the end, these “editors” decide that Scrum does not work, and permanently delete it from its memory and from its set of tools. The same thing happens with all other techniques. I saw it an insane number of times in my company, and they constantly tried to convince me that something (some kind of change) was not working.


Therefore, we have formed the basic principles of change - to change, they must be applied . If we decided that today we do not have technical support - just want to see what will happen without technical support - then there is no technical support, and nothing else.


This is probably the most important thing on which our success was based, on the fact that the guys who worked with me accepted these rules. They did not ask me for orders, orders, changes in staffing, permutations. We just agreed and did it together. As a result, in one day we could check the effect of some methods, practices, etc.



There have always been a lot of cool managers around. I myself once wanted to become so.


Who is a cool manager? This is the one who thinks that it is necessary to set a task, call a deadline, and when the deadline passes, but the task is not completed, tune the performer. This is not mine, but their expression. So they say: Scrum is all crap, you have to set tasks and hurt when you do not perform on time.


But we decided for ourselves that deadlines are evil . Why?



The last point should be explained separately. Immediately I ask women not to be offended, especially since such an approach is now even more common in men. This metaphor was invented in order to somehow explain the actions of some managers.


Analogy from life: Imagine that a woman asks a man to fix a crane and gives him 5 days to do it. What will happen all these five days? A man will do some business of his own, and a woman will remind you? No, it will not. She will come every day and quietly watch - repaired or not repaired. And here comes the fifth day, the woman comes up, looks - did not fix it. Waiting for the morning, and in the morning ...



And most importantly, for a woman it is a positive result . Why? Because after that you can do this:



And now draw an analogy with cool managers who set a task so that a person does not fulfill it in time, and then it can be turned up and down . It seems to me that this is some kind of sadism. They have so much fun and believe that this is work , and you have to pay for it at 300-500 thousand rubles a month.


We are not like that, so we formulated for ourselves the principle that a term is needed only when nothing needs to be done after it . For example, the deadline for reporting. After it, the task can no longer be done, because the penalty for late submission of reports seems to be 20 percent of the proceeds?


Goals



Surely everyone happened to see their subordinates in this state.



You come to work - and your employee sits like this.



Or like this.



What to do with him? I used to do this:



As a result, several times he was frankly sent, once he brought a person to a faint, and that does not count the shed tears - both male and female. Disgusting, still ashamed.



A man who is constantly screaming turns into an asshole. Although it is more correct to say that the asshole is the one who made him that way.


What is bad condition? If you constantly yell at a person, you will no longer see his tears, which means you will not know that he is sitting and doing nothing . Because a depressed person does nothing . For efficiency, this is a huge loss. If a person came in the morning depressed, he will sit all day on the Internet, open the configurator and switch back and forth quickly. Yet programmers are sitting by the monitor from the door, right?


Therefore, it is better not to shout at people. It is necessary to analyze the situation, and it may turn out that the person is simply not motivated . A person has no motivation because he has no goal . He came to work and does not know why. And if he also got some negativity at home, for example, for not reaching any home goals (his wife wants to go on vacation to the Maldives, but he cannot provide this), he just comes to work. Because how to achieve the goal, he does not know . Or maybe he has no purpose.


Therefore, we formulated for ourselves the principle that we need to talk about goals . At first, one sat with each of them, talked, then gathered together and discussed.


As a result, we managed to derive a certain “average” goal - one for all .


This “middle goal” was such - to work for a future employer . This formulation has a lot of meanings (well, I think so). I will mention only two:



We formulated such a goal for the children, and this had a very positive effect on them.



A few words about "customization on the fly" - a purely technical way to speed up the work.



The picture shows an incomplete list of such accelerators. These are abstract solutions that very quickly solve certain classes of problems . The most typical example is data validation. Instead of every time when the user wants to prohibit something while holding the document, write the code for 30 minutes, we do the check in three minutes without launching the configurator. Everything.



Putting “Middle Goal” and “On-the-fly Customization”, we get the “Layoff Kit”. What it is? This is exactly the set of knowledge, experience, ideas that a person, leaving the company, takes with him .


For each member of the team, we have compiled a rather large list of what needs to be studied, what needs to be tried, what needs to be sorted out, so that, having left the company, it can be applied to new work.



Priorities are an insanely important thing.


In my life I tried many different options for assigning priorities for performing tasks - to the extent that I used the model of innovative-vector enterprise development from a doctoral dissertation in economics.



But practice has shown that efficiency is in simplicity. Therefore, in the end, I chose the usual Eisenhower matrix for prioritization . Everyone knows about this tool - when all tasks are divided into four squares.


In the principles of the team it is reflected as follows:



Why does the employee have no choice of execution order? Because the choice of a task for a programmer is a terrible evil for efficiency . He can choose a task all day. What is day? This is 20% of the week. All day passed. After all, he does not just choose a task, he can go into the configurator, see how it is solved, what are the pitfalls, and then he will be frightened and change his mind about doing it. And so it goes all day, and maybe more.



And the two biggest evils for efficiency are when a person is scared and when it is incomprehensible to him .


Scary - this is when a person is sitting and him:



And fear paralyzes, as well as the possibility of choice . The man began to do, he was afraid to ask - and he sits paralyzed until you come to him and ask - what is there?
When we had this whole experiment, I didn’t realize how important this was. I understood this only when I moved to another company. Now my fear looks like this. Do you know this person?



Or, if someone didn't find out.



This is Evgeny Malyarov, the author of the metadata.js platform.


I am afraid of this man, because he has the knowledge, times in 20 exceeding mine. And I'm scared to ask him, because I’m used to being the best, and here I’m an idiot. And I'm afraid.


I have already said that a person can stupor all day. Now I can go all day, just to wait for the end of the day and run away.



When scary, you can get out of the situation with the help of humor . We found this way intuitively. When a person makes a mistake, we laugh at him. And since everyone laughs at everyone, including me, then nobody is offended.


And what to do when it is not clear? Imagine, a programmer sat down, got a task and does not understand how to do it.


It is necessary to force people to get up from behind computers to help the friends, and to explain to him that it is not clear. Why do you need to force? You can just say: "Help each other guys." But the guys will not help, because programmers love to look into your monitor. For them, getting up from the monitor is a problem. It happens, you say: "Guys, listen to me, I'll tell you a cool thing now." But they sit, look at the monitors, say they are listening, but in reality they are busy with their own affairs. As a result, sometimes it is even necessary to turn off the monitors so that they do not stare there.


And what to do when it is not clear to anyone and no one can help each other? Five people sit - no one knows how to do it. In this case, you need to arrange:




I am often accused of turning the development into a pipeline, preventing people from developing their competencies in breadth. The team was not an exception either - the Donkey asked me this question - I cried, screamed and asked for more difficult tasks, because he was the most inexperienced, low paid and uncertified.


I say - pf, why not? Just let's balance. I can’t pay you a scholarship on behalf of the employer for studying the platform, but on the other hand, I don’t need a pipeline of non-interchangeable employees either.


They took and balanced. On average, it turned out to allocate 30% of the time for solving problems new to humans. The principles were:



By the way, since I mentioned Donkey ... He, as a result, turned out to be the most effective employee. He gave out the least points, but if you count the cost of the point, it turned out to be the lowest. Roughly speaking, the results of his work cost the company the cheapest. .



– .


, , . . , — , . , , – , . – . , . , . – . , , , .


, , .



… , « ». .


, ? . :



, , , . , - , .


, , .. , – . – , , , . « », .


, . . , – , - . , , , , – , , , , – -, .


, , , , . , – , , , -, , , . , . , .


. , , , . , . , . , , . .


, , . – , ? . , .. – , , ( — ).


– , . , – 3% . – , , , .. . - , .


, , , . . , . – - – , ?


- – , , . , .



. , .


, 1? . – , , . , – , – , , , , , .


, . , . , .


, . , , , . , , , !


- , , , . – , ! , ? , . ! , … — .


: . , , , , , – . . , .



. . Scrum – , .


. , , , , 15-00, . . – , , ., -, – .


, , «». , , « ». – . , , . , .



– .


Scrum – , . . ? . Those. Scrum .


, , , , , 20 % .


.



, , -. « », , , . – , , .


- , , – . , . , – . , , - .


:




. , , . !
.



.




, «» , .



And after all this, I left this company, and a “cool manager” came to my place. This is a cool manager who Scrum calls “scrum” and says that this is a new-fashioned technique. Since my guys remained in the company, they continued to measure their effectiveness, and gave me their performance, how they work now. Now their effectiveness has dropped to 2.5 points.


If we calculate the quotient from the final and the very first measurements, it turns out that all the applied methods and principles gave us an efficiency increase of 4 times .


PS There is also a video version: one and two .


')

Source: https://habr.com/ru/post/445326/

More articles:


All Articles