The reverse side of Agile

I want to share a story, well, at the same time to hear the views of other participants of the habrassoobschestva. This is a small story about how the aggressive introduction of the Agile (Scrum) development methodology into a single Russian IT company served as the beginning of the exodus from the company of the best developers. Usually in articles about Agile they tell you what a cool and useful methodology it is, and in general is the best thing that was thought up in this direction. Perhaps this article will help to look at Agile from the other side, because any coin, as it turned out, has two sides.

In general, in 2010, a Russian company was founded (there is no point in specifying a company), it worked in the field of IT development (software for banking products).

As usual, at first everything worked almost in a startup mode, but, nevertheless, the company stood on its own feet and quickly paid for itself. Gradually, the number of employees of the company grew, managers, front and web developers, they have already exceeded 50 people and the first representative offices opened abroad.

As the number of developers grew, the project attracted investment and hired new management personnel; technical directors, HR departments, a bunch of administrative staff, and a countless army of managers of all stripes appeared.
')
The developers did their job, the project has been debugged to the smallest detail; everything seemed to be fine and nothing foreshadowed drastic changes. The tasks were set and carried out, for five years the composition of the developers did not change much, 5 years after the foundation of the company, almost no developer who was at the beginning of the company left it. And this, as for me, is an indicator that people were comfortable working in the company.

At one point, the company's management decided to try a new-fashioned development methodology for Russia. Agile (Scrum) was selected, a scrum master was hired by the company, all developments were transferred to TargetProcess. From the point of view of management, this was done in order to improve the speed and quality of development, as well as to gain an understanding of what developers spend time on. By the way, about the developers. These are really brilliant people who own a truly not small stack of technologies and really worry about their project, knowing about the essence of the project itself much more than management.

Of course, I understand perfectly well that times are changing, and earlier, perhaps, the development of a project was something like creativity. Now it is a streamlined business process whose goal is to make money. But brought to apotheosis, this process can suppress in developers craving for creativity and interest in the development of the project.

At first, after the introduction of the new-fashioned Skram, everyone rejoiced at its consistency and external simplicity. Everything is clear, we divide the development process into sprints, we get user-story managers (tasks, what to do), we include them in some sprints, at the end of the sprint we do a retrospective (we look what we have done and what went wrong) and we loop through this process.

But then everything turned into the fact that the development department turned from the core of the company, bringing money, just into a tool like a screwdriver or a hammer. Managers invented the task, threw off in the IT-department and waited for implementation, simultaneously counting the time spent on development and testing. Developers and testers were told to write off the time to complete the task in TargetProcess. Management began to convert tasks during their execution and of course into cost. Here, as usual, a misunderstanding immediately arose between management and developers. How can transferring a project from Symfony 2.6 to Symfony 3.0 take almost a week to the developer, because this is just an upgrade from one version to another? Perhaps, from the business point of view, the development department always looks like lazy employees, who are good if they could work three times and, preferably, five times faster to reduce development costs and increase its speed.

From their point of view, of course, everything is logical: they did it faster, which means they incurred less expenses, they fulfilled the contract more quickly, received money and bonuses. But, from the point of view of the developers, a slightly different picture emerged, the developers were not deprived of work anyway, working on three to five projects in parallel each time, as pressure from the management and report for each hour of working time appeared. Questions began to arise in the spirit of "why did you spend the whole day developing or testing this one"?

After a month of indignation, the passions subsided a bit, and the development department gradually got used to the fate of the “screwdriver”.

Software development is a craft that is closely connected with creativity, one and the same task can be done either well, or you can get creative and do it very well.

This is a bobuk talk about how to deal with developers. Answer: as with children. Of course, I do not think that this is the way to treat everyone in a row, but it must be borne in mind that not everyone can like a sharp change in the rules of the game in a company.

The result of the introduction of such a methodology was the fact that the enthusiasm of the developers subsided. Began to perform only tasks (User Story), coming from managers, on any imperceptible, but useful activity of the developers did not remain. It got to the point that when a bug was found somewhere in the production, the developers could not fix it, because this requires a task to write time there. And the developers themselves were inundated with their tasks. Tasks began to assign priorities. Managers began to clash with each other, trying to assign their userStory top priority, because they have obligations to customers and no one cares about the employment of developers.

As a result, the whole system began to lead to a small local collapse. The developers have lost all enthusiasm and began to treat the development formally. There is a task - we do it, no task - we do not. In addition, the hourly time report left a hint of the fact that behind your back someone constantly stands and watches you press the buttons.

Naturally, from the point of view of the Management, the situation was more rosy, they received a full report on the time spent on the development of any project, and an understanding of who does what in almost real time.

But the developers - the same people, and began to not stand. Within a month, 3 core kernel developers left the company. Replacement that currently simply take nowhere. They have worked for the company since its inception and actually made the company what it is now. The load on other developers began to increase exponentially; the development department reeled as a house of cards, the developers who worked in the company for 5 years, began to leave, because ceased to feel part of the company, becoming a "screwdriver".

Summary

Methodology Scrum, which turns the development process into a pipeline, does not take into account primarily human relationships in a team, does not take into account the fact that some things in a company can be done only because of the enthusiasm of employees, and cannot be wrapped in UserStory.

An aggressive transition to such streaming development methodologies leads to the "formalization" of relations within the company. The result of the abrupt introductions was that management now sees better what is happening in the company, but there are already no key developers in the company.

To say that these employees are guilty themselves, because they could not adapt, or acted arrogantly - as for me, this is a mistake. Perhaps the Agile implementation process itself was organized incorrectly, but, anyway, this process had its black side.