I recently spoke at the Saint TeamLead Conf 2019 conference, in a report I talked about how I was able to find a number of problems in the workflow and then gradually overcome them. Here I will try to describe the most valuable practices that helped me not only to establish a workflow, but also to stop mocking the developers. Employees have changed their attitude to the company as a whole and the work process.
Development Process Challenges
So, when the ready-made approaches did not give a result, and we were close to despair, I started analyzing the processes and began to analyze everything by the bones. The result is a list of problems:
- The board is overloaded with tasks - there was real chaos on it. Looking at the board, understanding the processes was almost impossible.
- There were no normal evaluations - we did not know how to correctly evaluate tasks according to lead time, because of this, the deadlines were constantly on the way, business leaders ran into development.
- We were constantly framing the deadlines - we couldn’t say exactly when the feature would go into production, most often we rolled it out much later than planned due to external factors, for example, the business resorted and asked to quickly do some urgent feature in the first place.
- There was no understanding how to speed up development - hiring new people and loading engineers by 100% do not always make the process faster.
- Planning and urgent tasks - if with current tasks it was somehow possible to make plans and indicate approximate dates, then urgent tasks that usually flew from the business broke all plans.
- Meetings are time - consuming - our most common mistake: something does not work out or we need to prioritize tasks - and let's get together and discuss. Or regular meetings, where the developers sat for an hour or two and did not understand what they were doing there.
- The problem of motivation and involvement of teams - often some innovations were simply brought down by the authorities from above, without asking the opinion of the development team, this did not paint the atmosphere in the team.
In fact, the task of any leader, be it TL or CTO, is that he should become the link between business and development.
To somehow get out of this situation, we turned to the Kanban method. What does he tell us? Let's improve what is already there. Well, we went to improve our development process.
Putting order on the board
We started to argue: if the backenders completed their task and transferred it to the front-end, will they immediately start it? Looking at the board, this is incomprehensible. According to the principles of Kanban, we divided each direction of development (we had 5 of them: backend, frontend, DevOps, QA and design) into two columns: Do and Done. The problem immediately became apparent: our bandwidth does not allow us to do as many tasks as they want from us.
Kanban also says: let's introduce a WIP-limit and limit the number of tasks. How do we set limits? Empirically. Of course, they missed a couple of times, but then they picked it up so that we did not have to accumulate tasks in the narrowest place. An additional profit of WIP-limit is a trigger, which says that as soon as we have the task taken away, we can take the following. This is a kind of pulling system.
What did this lead to? Engineers began to be more attentive to tasks, because when they can not solve a problem, then a blocker is put on it. You can’t take more tasks, since there is a WIP-limit, engineers must wait until they are helped to solve it. There is a chance to stay without tasks.
When we began to analyze in detail the problem of returning tasks, it turned out that everyone does them differently, for example, someone writes tests, and someone does not. There were rules in this regard, but those that were let down by the authorities. They did not solve the developers problem. We introduced new rules ( Definition of Done ), which are integrated into the board. They could act both on some column, and on the type of card. For example, for an API, a back-end needs to document all methods and stuff. The rules were accessible to everyone and visible on the board, and most importantly, they came from the engineers themselves and solved their problems. If something was not done, the engineer saw it and went to do it.
Grade Tasks
We did not know how to evaluate tasks by deadlines, and Kanban tells us: “No estimates”. What to do? We accumulated statistics and built such a schedule. This is a spectral diagram, the dependence of the number of tasks on time.
We began to study it, saw on the graph 3 peaks that correspond to three types of work. Based on these types, a classification and criteria for such work were developed. We introduced these types on the task board, and then we added additional rules for each in the process. We got the following:
We agreed with the customer, that is, with the business, on a service quality agreement (SLA). A manager comes to us and asks: “And how much will you make this feature?” We can’t say how much it will be done exactly, but we can say how much time it will take a whole batch of such tasks. Scrum poker was no longer necessary, and we stopped torturing people with timing questions. We just looked at the statistics and called the dates for business.
Of course, this approach also had disadvantages. For example, this did not work with tasks of a new type, for which we simply did not have statistics. They pretended to be in old ways, but then they accumulated a sufficient amount of data and this problem came to naught.
Then we were faced with the fact that some tasks began to fall into other types of work. We did a little research and found out that we did some tasks much faster, because the business promised partners there something and asked the developers to do them urgently. And some tasks on the contrary were not so important, they were put off. So we got priorities, that is, agreements on classes of service of services (CoS), we placed them on the board. And so that the business does not abuse it and does not set increased urgency for all tasks, horizontal WIP-limits have been introduced.
How to speed up development
Again turned to the task tracker statistics. We found that many tasks hang on the board in anticipation of improvements, checks or additional data, that is, they realized that development can be accelerated. They began to look at how many tasks are accumulating, how much they are idle, and found that some features were developed less than they expected acceptance. We decided to set a day for accepting features, and the time for issuing tasks was reduced. And then we fastened the CD (Continuous Delivery) and began to send notifications.
It became clear that we needed a tool to evaluate our improvements. We decided to use the cumulative flow diagram. In a nutshell, how it is built: we assign a color to each work center (columns on the board), take statistics on how many elements (tasks) are in a unit of time in a column, and plot them on the graph, placing them one under the other. On the graph, the X axis is time, the Y axis is the number of tasks.
What did we get from here? Here it is easy to see the lead time (production time) - the horizontal line (the width of the flow along the X axis) begins with the statement of the problem and reaches the stage of readiness. Thus, here you can see how the task goes through all stages of development - the line intersects all the colors, each of which corresponds to its stage. And also the total WIP-limit of the board - the flow height along the Y axis. How to increase the development speed? You can reduce the WIP-limit (that is, make the flow on the graph narrower), or you can make our flow, which is directed from the origin to the upper right corner of the graph, tend to go up even more (that is, to raise the flow direction even more up, reduce its angle relative to the Y axis). To direct the flow stronger upward, you can introduce some new practice, for example, implement Docker or make a convenient knowledge base. This does not have to be a technical innovation; a new approach to management can also give such an effect.
Thus, we got a tool that clearly showed which improvements work and which do not.
Business planning, urgent and useless tasks
Business development planning was the biggest pain. What did we do? After receiving the task from the business, a meeting was held between the analyst and the developer, where they decomposed it, and the developer proposed solutions. As a result, we understood how much and what resources the task required. And only then the business without our participation made its plans and considered how much we can release features. In Kanban, this is called replenishment cadence .
Relatively speaking, we allocate slots of a certain size, in accordance with the WIP-limits, where you can put tasks. Each slot holds only a limited number of tasks. In another way, this method is called “cup planning”.
We made a simple tool for business (a table in Excel) in which it could visually plan. The managers fought among themselves, argued whose task is more important, and then they came to us and gave the tasks to development.
Since we already had limitations, the business was more attentive to the choice of tasks, chose the most important ones, and did not overwhelm us with any nonsense that occurred to them. And one more big plus: they selected the tasks themselves without our participation, without distracting the developers to meetings, they worked quietly and did not spend time on meetings.
We also turned our attention to the problem of urgent tasks. They began to analyze statistics on them and realized that these tasks are not so urgent. For example, we need a promotion on seasonal wheel changes for motorists. We know that this always happens 2 times a year. Once they are repeated, let's reserve slots for such tasks on the board in advance. There will be nothing urgent - we will take another task from the queue, we will not remain without work. As a result, we found out that 60% of urgent tasks are actually not urgent.
There was another problem. We often sawed features, which then eventually turned down the business, because they turned out to be useless from a business point of view. We suggested that businesses do MVP features that require several times less time than conventional development. Feedback began to be removed much faster, and engineers began to realize that these were experiments. Previously, when weeks of work done were thrown into the trash, they worried, it poisoned their lives.
We began to test 85% of the features in such a way that in the end we freed up a lot of time, which we then spent on hypotheses tested in practice. They already brought the company money. Also, if something went wrong in the process, then the customer of the feature on the part of the business could make corrections at an early stage, and not through the entire development cycle.
As a result, such a fact was discovered that not all ideas work. And since they do not work, then do not do them. Since then, the developers have ceased to engage in monkey labor, and did exactly what the company brings money.
Meetings
The improvements that we introduced by that time had already killed a number of useless meetings. Prioritization discussions were no more, since we gave this to the business, we also planned without engineers. We also abandoned the five-minute raids of managers with a request "quickly help." There were only really necessary meetings. We also introduced the rule that now meetings are scheduled for a specific time so that everyone can plan their schedule.
As a result, all meetings on boltology were transformed into the following types of meetings:
- when an analyst wants to discuss a specific problem with an engineer, for example, to find the optimal solution or decomposition;
- when something is stuck on the board. In these cases, we gathered and walked along the board from right to left, asking the engineers what happened, who could help. It is important that we went from tasks, and did not try to calculate what people were doing;
- when planning tasks for the sprint (cadence for replenishment);
- when they took features;
- Meetings between development teams, for example, when discussing the API format or deciding which events to send.
Key point: we invited to meetings only those people who were directly involved in the subject of discussion, and did not call nominee listeners, as before. Engineers have fundamentally changed their attitude to meetings, before they did not like them, but now it's the other way around, they seem to be necessary and useful to them.
Team Motivation and Engagement
All that we implemented: WIP-limits, evaluation of tasks based on statistics, refusal of useless tasks, etc. described above, led to free up time for engineers. What will they do now? The biggest misconception is that no one will do anything. I myself have repeatedly heard from the guys: "I would have refactored this code, otherwise the damn leg would break there." Yes, at first the engineer really gets enough sleep and rests for 2-3 weeks, and then what? He sits without tasks, begins to approach his colleagues with a proposal of help, helps to complete tasks, then both are already sitting without tasks. “Let's send bugs fix” - the column with bugs was empty. “Send the code we will refactor” - the code has become faster to write, the WIP-limit can be increased. Then they begin to implement CD / CI, write a knowledge base. What happened Engineers begin to do a lot of useful things, to which their hands did not reach. This is the speed that the business wants, but for some reason it cannot get it from anyone. Previously, the engineer was evil, he wanted everyone to be behind him, but now the human paradigm has changed to: “Now how can I help you?” The number of initiatives has grown, and they all went from below, not from above. And in the end, it turned out to be much more useful.
Summary of the results
- We were able to find a bottleneck in the system and understand that we cannot do more than we can.
- They stopped throwing developers useless work and freed up time for more useful tasks.
- When the engineers had nothing to do, they began to better evaluate tasks, rake bugs, began to automate processes, and a knowledge base appeared.
- Engineers stopped experiencing stress and became kinder.
- We were able to 4 times accelerate the release of new features through improvements, optimization of work (increased WIP-limits due to automation and improvements).
- We got statistics for business and a clear understanding of what and how is going on with development.
- We learned to save time (rejection of unnecessary tasks, began to think through tasks in advance in order to avoid additional factors, etc.).
- Meetings and meetings were held when they are really needed (become more flexible).
- Everyone began to think more, the number of initiatives increased. Initiatives that are born in teams are always better than those that come down from above. The process went on constantly, and everyone got involved in it.
conclusions
In this article and report, I wanted to draw attention not only to the tools and approaches that I applied, but rather to the most important aspect, which often goes unnoticed, but, in my opinion, it is no less important. We started this whole perestroika, because we had pains and we wanted to get rid of them.
You can implement something “on the forehead” by reading smart books or listening to a report on flexible methodologies, so it’s even possible to accelerate development or products will work better. But we often forget that people make these products, and the better we make their lives, the better they will make products. For example, I go to the guys and ask: “And what are your pains? What is wrong? ”, Before you start to implement something. And only thanks to this approach, I managed to do what the business wants - speed and quality in development.
PS I was told about one company in Europe, when you come to the office there, it might seem that complete anarchy reigns: developers, like cheese in butter, play consoles, nobody works. But this is only at first glance, there is an atmosphere specially created for people so that they can create and improve. In the interval between tasks for entertainment on the knee, one wrote a solution that was subsequently implemented, and it began to bring profit to the company. I hope our Russian management will move in this direction in the near future. And if for some reason you have something wrong, think about what you are doing. Well, or throw this article to your boss, but what if it helps :)