How to forge the process yourself. 2GIS Company Experience

Mikhail Vyazankin ( mihey911 )

I will tell you a story about one overloaded team.

We had a team, not very big, 20 people of highly qualified specialists - developers, testers, DevOps. This overloaded team had a dozen customers, mostly domestic. This dozen of customers constantly fought for priorities. For the team, this is a big stress, tension, the team does not understand what will happen next - every day some new business task may arrive. In such conditions, Scrum, which they had been working for two years and to which they were accustomed, began to break down, and the commitment (what they promised to do for the sprint) could not be done, because someone very important resorted and wanted something very valuable. And valuable is money, it is necessary to do them.
')
And the team was tired of this, and was ready to change . This is an important condition.

Initially, I intended to give you a set of recommendations and recipes for organizing the process, but it is easier to explain the recipes with an example, so there will be a story with a few distractions about what and why we are doing, and how you can do it at home.

About myself. I started programming at 11 years old. I have been working in professional IT for more than six years, of which for three years I am a manager. He worked in several companies, managed projects from small to large, the largest - about 40 people in a team. In recent years I have been keen on Agile-methodologies, I am actively interested in how all this can be revived, what can be done from this, various studies, experiments.

The main difference of this team from many is that it has gone all this way, which I will now talk about, consciously. They understood very well what we were doing, we constantly told them all about it.

To start making any changes, it was necessary to set a goal for ourselves, answering the questions: what do we want to achieve in the end, what do we want to do with this team, with this process, how do we want to simplify the life of the team?



The first is that we needed not to lose motivation, because it was hard and tense, people began to tire. It was necessary for them to do simple, easy, so that they would work in a high. Naturally, this implies that we needed clear priorities.

Clear priorities are the most painful part. As it turned out, few people know how to make priorities clear.

From this the next goal - we need predictability.

Our expectations: we have a motivated team, clear priorities, we set up the process and were able to make it predictable, i.e. able to constantly repeat the result, and we know how long it will take for some task, etc. And a useful bonus - we must have an independent team that makes everything conscious, i.e. can practically without the intervention of people from the outside, without some coaches and managers, develop the process further, self-improve, and most likely will not get into the situations described above.

After we defined the goals, in order to understand the horizon, where we want to go, we needed to understand in more detail how it will be, and what exactly will we do to achieve these goals? Those. we had some conditional indicators that we wanted to achieve, and options for concrete actions.



So, we could fix that Scrum that was. For example, the commitment of the guys did not comply - because of the priorities did not do what they promised. We could take and begin to teach them to observe this commitment - to spend a lot of strength and nerves, the external conditions would not change, and the guys would puff and suffer ... We would do everything according to Scrum, but it is unknown what would have turned out.

We could assemble something new from the bricks, i.e. throw out Scrum and say: “Guys, let's think out our process”. Then they were interested in such an interesting thing as Essence from the SEMAT institute. We did not use it the way the institute wanted to use it, but rather turned to it as a reference book that gathered all the elements of IT processes and described their advantages, disadvantages, and compatibility. We looked, did not like.

We had the option to declare kanban. Declaratively. The manager came and said: "We have kanban tomorrow." We have weighed up the pros and cons of this option, it seemed that in this case the team would almost never achieve independence.

We decided to go quite a strange way - we decided to evolve the team a little bit. I still like this option most of all, I think this is a promising option. But, running a little ahead, I will say that we still got kanban, but then we consciously walked this path, we knew what rake we were on, we fixed what we wanted.

Before starting, we had to learn not to be afraid of changes, because the project is critical for business, if we break something there and lose even what we already had, then the business will lose its power, it will not be able to respond to any important things.



It was necessary to accept the fact that our stakes are high. In troubled projects, this is always the case - if you have a really important project for a business, then the stakes are high by default, you just have to put up with it and then carefully think what to do with it.

We had an installation that the team wants the best. Most of the teams want the best, and want to make sure that their work is awesome, so that it brings results. Not very many professionals just come, get paid and leave. And we decided to help the team do better. This also helped us not to be afraid, because we knew that we were not alone, we were not alone who understood the problem and would not be alone to solve it, i.e. the team will help us.

We also came to understand that we need to take small steps. There is such a wonderful concept - kaizen (kaizen), it has something in common with kanban - when you are very, very slow, with dotted strokes you move your process somewhere to “good”. Kaizen allows you to get a cool bonus when you can roll back the applied changes, i.e. they changed something - they did a swab, they understood that they lost their pop, quickly removed, as if nothing had happened.

And the main thing that we have learned from all this: if we move in small steps, then it is important not to be afraid of mistakes. If you made a mistake and are not afraid to admit it to yourself, just take it and fix it. Try some other thing, even if there is an error, then you have already learned it and quickly fix it.

Again, we love goals, and before making any point changes, we wanted to understand how evolution will take place. Those. we realized what we have at the exit is the goal, what we want to get the team, and now we need to understand what we want to get the process in this team.



The process should be simple, because teams don't like complicated processes, they don't like when everything is difficult, when a lot of bureaucracy or something else. Naturally, we needed efficiency, we needed to digest business-critical tasks several times faster. Predictability was also needed, because business loves predictability, and we ourselves love predictability, it is much easier for us to live when it is clear what will happen in a few days, weeks, months.

We compiled this roadmap:



We had a broken Scrum, we took sprints out of it and threw out sprints, said: “Everything, we, like, are now working on kanban”.

The main goal of kanban, if anyone does not know, is to build a stream in such a way that the tasks get through it optimally quickly - from setting a task to a ready-made solution that you have in production.

And we went further, or rather, we were going to go further, but realized that our assessments do not work in such a system. No need to cling to the estimates, they can be replaced by something, it is important to get predictability. Let's get predictability in that we just make the task very transparent. Those. we decided to make the tasks very understandable, when we can say with a high degree of probability what problems and pains can arise. We spent a large amount of time, invested it in communications, but learned how to break tasks into simpler, more understandable both for the team and the customer, for the business.

Then quietly began to impose restrictions - to make the system more efficient, you must first loosen it, and then tighten it, where necessary, in order to optimize the flow.

After the introduction of restrictions, it was possible to start measuring the resulting results. It has already become clear what we have achieved, what we have in the end tsiferki. I repeat, we have got kanban –constraints, metrics, communications - these are all familiar things for kanban, this is a big part of kanban-about specific things.

Actually, how did it all happen, how did the team go through it all?

In general, the process was quite long, about six to eight months, the guys and I went through all this, tried not to drive the horses, in an attempt not to break down what we have, and in the process of the team’s awareness of what we are doing. We spent a lot of time on awareness, and awareness came to us through a tool like retrospectives.



We conducted retrospectives, not as usual - once in 2-4 weeks. When we had some kind of problem, we gathered at a retrospective, discussed this problem, and the managers gave up ideas on how to solve the problem. The team either accepted the idea, or rejected, or offered contree, but much better, because it knew some of its mechanics. Therefore, retrospectives are the most effective tool and, perhaps, this is the best point of influence on such commands that you want later in Agile somewhere. Retrospectives are gold.

I will try not to dwell on some kind of kanban paraphernalia, on some things that are peculiar to Agile. It was not important. We, for example, tried such a thing as a physical board - to post stickers on the board on columns. But we had a very IT team that did not like physical boards, and ended up with a team lead outweighing these stickers every day in proud solitude, and then repeating somewhere in the task tracker. We tried it twice, the second time we just had the whole board crumbled in the end, because everyone had scored. Do not, do not. We have all replaced this with a classroom automated board, brought it to the big screen - the effect is the same, but we didn’t need a physical board at all.

Another interesting point. As I said, we walked in small steps, and in the process they looked, for example, like “create a button in Jira”. Just create a button. It would seem, from the point of view of a large process, from a business point of view, to create a button is some kind of garbage. But she saved us a bunch of testers nerves. Developers no longer suspicious of kanban. Thanks to this thing, everyone understood what a flow is, and from this “unfortunate” button we received so many bonuses that the efforts to create a button are incommensurable with the received bonuses. Therefore, when you are offered a small change, you should not refuse, it is worth a try. It can then be easily rolled back if you don't like it.

Two months after the start of this whole evolution, we told the guys about CycleTyme. CycleTyme is the average time from when your task hit the task thresher to the time it exited. Usually, customers, product managers, or someone else came to the input, and said they wanted it, but it ends somewhere in production, i.e. on combat servers. So, in two months, when the guys got used to the stream, we measured this CycleTyme for ourselves, and they already perceived it easily. Those. they got used to the flow, they understood how it works.

We had the next change in about three to four months - we began to introduce limits. Limits are the physical actual constraint on some type of work to be performed. For example, you have two developers, they are unlikely to physically be able to do 12 tasks simultaneously. And we, as rational people, say: "Let them do two tasks each". And here we have some kind of limit appears by itself - four tasks. Optimally, when a developer does not spend time, does not switch between tasks when he is working on one. And kanban tells us that it is desirable to bring these limits to unity. Optimally - by the number of people who are engaged in work.

The second important limit that we have introduced is the number of tasks that the team as a whole is currently performing. We strongly cut down the incoming stream. We had a huge number of customers, and we agreed with these customers as follows: we told all customers what tasks other customers set for us, i.e. all customers knew that we now have a lot of tasks. And if they needed something priority, they could go and negotiate with the "neighbors", simultaneously finding out which of the tasks is more important for the business now. It brought a lot of pain and suffering, both to customers and PM, but it allowed us to focus on important tasks and not overload the team. We began to perform tasks much faster.

Once again about the retrospectives. Everything that I told you, how it was, everything was introduced through retrospectives, we all discussed this with the team at retrospectives. In fact, the only tool that the team can implement without serious consequences, through which the team can put some idea. Everything else, if they are not ready to listen to you now, they will simply miss the ears, you will simply leave the room, and they will forget. In one ear flew - in the other flew.

In the end, what did this team do? What success did they achieve?



We received the same task pool when all customers know about everything - it is open and understandable. The fight for priorities stopped by itself within a few months, the priorities became clear, predictable, and we were able to solve business problems very quickly. How fast? For example, the task is that an advertising company needs to quickly make a promotion page. We reduced it from two weeks to two working days.

More than half a year has passed since I do not work with this team, and they still develop the process by the team themselves. They make some changes in retrospectives, do something that they themselves understand, these newest blocker buttons create.

For example, they now have a cool post, called the “postmaster”. This is a person who for several days is responsible for all mail entering the team and spreads puzzles. Position elective and passing. Usually, developers do not like to reply to the mail at all, it irritates them, but when they realize that in a few days they will give it to someone, it becomes easier to live this way. They began to sort out the mail regularly, quickly respond to it, everything became normal. And, as a bonus, we in this team received such a cool piece as continuous delivery. This is when we did the task in the morning, and in the evening she was already “in battle”. Through automation, they drove off, and depending on the severity of the task, in a few hours, and maybe even minutes, it can get on all servers. Such an experience we have turned out.

How can you experience this experience on yourself, if you work with teams, it doesn’t matter with which, and you want to use something, teach a team something?



First of all, we need a goal. Once again, you need to see what you want to get from the exit team, what pains and problems they have, what problems you want to solve with these changes.

We must see what options you have, how painful and painless. Once you have chosen a more or less acceptable option, you need to think in steps how you will implement it. Even if you introduce it with an eye to the team, you need to have some support points, to know whether you have now, at the current moment, succeeded or not.

The most important thing: do not be afraid to make changes. The hardest thing to start. The first step was made, it will be easier to go on. And be sure to reserve the right to make mistakes, learn how to quickly roll back your decisions, admit mistakes, make some small steps. Small back steps are much easier to do than a big jump.

And try to avoid revolutions in projects, i.e. what I told you first when you come and say: “Today we have kanban,” and throw out all that was. If they suddenly come and say: “Today we will hang red wallpapers for you, and we throw out your old ones” - for example, I will be very upset. Therefore, if you come to the team with such a proposal, it will be just as upset.

Contacts

» Mihey911
Twitter
» 2GIS company blog

This report is a transcript of one of the best speeches at the WhaleRider management and entrepreneurship conference .

On the conference website you can subscribe to the mailing list, where decryptions of the best reports from several recent Whale Rider are published. Through the same list, you can follow the preparations for the new conference.

And the main news is that we have begun preparations for the spring festival “ Russian Internet Technologies ”, which includes eight conferences, including WhaleRider .