Flexibility is without a doubt a good thing, and there is a point in the Agile manifest . Compared with the fragile practice called "waterfall", Agile is noticeably better. However, in practice, flexible approaches often cause deep harm, and in reality the Agile / Waterfall dichotomy is hardly appropriate.

I saw how many Agile options, called Scrum, really kill the company. By “kill,” I do not mean “deterioration of culture”, but rather when company shares fall by almost 90% in two years.

What is Agile?

Agile grew out of a web consulting environment where it brought some benefits: when working with fastidious clients who don't know what they want, you usually have to choose from two options. Or overwhelm the customer: set expectations, pay appropriate for rework and maintain an equality, not submission relationship. Or accept incorrect client behavior (as, say, many designers have to do) and orient the workflow around client dysfunction.

Programmers usually do not work well with clients. We are too literal people. We like systems with clearly defined behavior. This makes it harder for us to interact with the humanities because we tend to take every request literally, and not find out what they really want. At the corporate level, flexible methods (outside the consulting environment) go further and suggest that engineers are not smart enough to understand what their internal “clients” want. This means that work is sprayed on “user stories” and “iterations”, which often deprive us of satisfaction with the work done, as well as of any hope for a long-term vision of where things are going.

In general, two types of work are usually created, either within a company or for a contractor. At a high level hired by highly qualified specialists. At the bottom - all the work that they don’t want to do is dumped to the side. Obviously, one class of consultants gains respect, and the other does not. Poorly managed consulting firms often end up becoming garbage pipes for low-skilled work. Scrum seems to have been created for such organizations where customer relations are so bad that engineers need to be monitored on a daily basis because they have become a settling tank for low-grade work that is useless for a career that nobody wants to do (and probably this is not very important , hence low rates and respect).

Violent transparency

There are many trends in the workplace in IT that make programming careers extremely unattractive, especially for creative, intelligent people.

The most glaring example is the open-plan offices. They are not productive. It is difficult to concentrate in them. They are anti-intellectual because people are afraid of being caught reading books (or just thinking) at work. When you make people pretend to be productive, they actually lose productivity. Open-plan offices are generally not for productivity. This is a corporate image. Venture-financed startups use these layouts to show investors how the office looksbusy. (Simply put, an open-planner programmer is more valued as office furniture, and not for the code that writes). For various cultural reasons, this has made the open-plan version cool and dirty, and now it infects the corporate world as a whole.

It is well known that creative people lose their creativity if they are asked to explain themselves while working. The same with software. Programmers often have to work in conditions of one-sided transparency. These Agile systems are often misused and require degrading work transparency, despite the lack of reciprocity. Instead of working on actual long-term projects that a person might get carried away with, they are relegated to working on atomized, functional “user stories” and often prohibit working on improvements that are not related to short-term, immediate business needs (often launched from above). This wrong, but common Agile variant excludes the notion of ownership and regards programmers as interchangeable, identical components.

Scrum - the worst option, with the stupidity of two-week "iterations." This causes an unnecessary concern for the microfluctuations of human performance. There is absolutely no evidence that such an approach really speeds up or improves development in the long run. It just makes people nervous. Many in business think that this is a good approach, because the work "goes faster." I have been in the IT industry for ten years, as a manager and as a working bee. It is not true.

Specific disadvantages of Agile and Scrum

1. Business-oriented development.

Agile often served in comparison with the "waterfall". What is a waterfall?

Waterfall is really terrible. In it, “work rolls down,” where each level of the organizational hierarchy chooses what it considers to be “interesting material,” and passes on. Projects are determined by managers, architecture is designed by architects, personal deadlines are set by middle managers, implementation is performed by top-level workhorses (programmers), and then operations and testing are transferred to lower-level horses. This is an extremely non-functional scheme. When people feel that all important decisions have already been made, they have no motivation to work as best they can.

The waterfall reproduces the social model of a dysfunctional organization with a certain hierarchy. In turn, Agile quite often replicates the social model of a dysfunctional organization without a clearly defined hierarchy.

I have mixed opinions about job titles like “senior” and “director”, and the like. They matter, and I myself probably will not accept a position below the director’s level, but I hate their importance. If you look at Scrum, it specifically deprives the rights of the older, most capable engineers, because here they are obliged to adhere to the established processes (work only on the created tasks, 5-10 hours per week at the planning meetings). These processes are designed for people who started programming a month ago.

Like the failed communist state, which equalizes people by spreading poverty, Scrum in its purest form puts all development on the same low level: not clearly defined, but clearly below the level of business people who have complete power to decide what to work on.

Agile in its usual implementation increases the frequency of feedback, still not giving the engineers any real power. This is a losing deal, because it means that programmers are more likely to be pulled or punished when the work takes longer than it supposedly takes. It creates a lot of anxiety and haste, but in fact it has little to do with what really matters: creating great products.

Silicon Valley has made many mistakes, especially in the last five years, but has done something right. Including introduced the concept of "engineering" company. For engineers, it is not always better to manage the entire company, but when engineers manage development and set priorities, everyone gains: engineers are happy with the work they are assigned (or, even better, they assign themselves), and the business gets a much higher quality of development.

But you have a "business company", this is normal. Then do not hire engineers in the state, if you need talent. You can get the best people as consultants (starting at $ 200 per hour and rising sharply from this level), but not as full-time employees of the “business company”. Good engineers want to work in firms that are managed by engineers, where they will be involved in work planning without having to justify themselves to “scram masters”, “product owners” and several levels of humanities managers.

Ultimately, Agile (as practiced) and Waterfall are forms of business-oriented development, and therefore none of them are suitable for developing high-quality software or motivating employees.

2. Subordinate position of the young.

Unfortunately, software development has developed a culture of subordinate position of young people with the (extremely erroneous) concept of programming as “toys of young men”, although almost none of the best engineers are young, and quite a few of the best are not men at all.

The problem with Agile's two-week iterations (or “sprints”) and user stories is that there is no exit strategy. There is no option “We will not have to do this anymore when we reach [X]”. It is assumed that this system is forever: business-oriented meetings will never disappear. Architecture, R & D and product development are leaving the work of the programmer because they do not fit into atomized “user histories” and two-week sprints.

As a result, for more or less experienced programmers, this is uncomfortable to work, because they want to take on the kinds of projects that are ignored in this structure, and such projects are difficult to justify in terms of short-term business value. Technical excellence matters, but it is very difficult to convince people of this fact if they stubbornly don’t want to be convinced.

I once worked at a company where a product manager said that the difference between a senior engineer and a junior engineer is in the ability to give more accurate time estimates. Well, actually not. And it is even insulting. I hate grades because they generate policies and don't actually do the work faster or better (in fact, usually the other way around).

The worst thing about evaluations is that they stimulate the performance of work that can be assessed. This makes programmers give preference to low-level things that the business doesn’t really need (even if clumsy middle managers think differently), but this is “safe.” All that is really worth doing is having a non-zero chance of failure and too many unknown parameters for a reasonable estimate of time. Agile's concentration on short-term business value ultimately pushes people away from the work that the company really needs in order to manage each programmer’s reputation in real time.

Such a culture suggests the idea that programming is childish, which you need to get rid of by the age of 35. I do not agree with this opinion. In fact, I think this is a harmful thought. I'm 30 and a little bit, and I feel that I'm just starting to program well. Harassing senior programmers just because they are experienced enough to know that this flexible / scrum process has nothing to do with computer science and that it does not add value - this is a terrible idea.

3. Too short-term approach, which is stupid and dangerous.

Agile is intended for secondary consulting firms that do not have sufficient credibility to negotiate with clients on an equal footing, and who face tight deadlines, and each client project is an existential risk. He is for "marginal" outsiders. But here's the problem: Scrum is often deployed in large companies and funded startups. But people go to such companies because they do not want to be outsiders . They want security. That is why they work in these companies, and do not create their own. No one wants to be left behind if there is no significant personal gain. Agile in corporation means pain and risk without reward.

When each client project carries an existential or serious reputational risk, Agile may be the appropriate solution, because focusing on short-term iterations is useful when the company is threatened and may disappear in the long run. Aggressive project management makes sense in an emergency. It does not make sense as a permanent arrangement; at least not for talented programmers who have less stressful and more pleasant options.

As part of Agile, technical debt accumulates and is not solved, because the business people who assign the tasks will not see the problem until it is too late or at least too expensive to correct. Moreover, individual engineers are rewarded or punished solely on the basis of the current two-week “sprints”, that is, no one looks at the five “sprints” ahead. Agile is just one meaningless, short-sighted “sprint” after another: no progress, no improvements, just a ticket for a ticket, for a ticket.

People who agree with the shuffling of meaningless tasks can endure it, but really good engineers hate to go to work on Monday morning, not knowing what they will work on that day.

4. He has nothing to do with building a career.

Separate user stories are not good for engineering careers. By the age of 30, you are expected to be able to work at the level of the entire project and that you are at least prepared to go beyond this level into infrastructure, architecture, research or leadership.

In an emergency, whether it is a consultation seeking to calm an important client or a corporate “war room”, thoughts of a resume can wait. Few people will give up a couple of weeks of unpleasant or other work unrelated to career development, if this is really important for the company. The importance of working here is a priority. If you can say, “I sat in the headquarters and talked with the CEO for 20 minutes a day,” this justifies doing stupid work.

But if there is no emergency, programmers expect their career growth to be taken seriously. Otherwise they will leave. “I was on the Scrum team” means that you are a whipping pear. It's one thing to do a stupid job, because the CEO admitted that the unpleasant task would add millions of dollars in cost (and he would reward her accordingly). But if you were simply assigned “user stories” and Jira tickets, then you are considered as a loser.

5. The goal is to identify low rates, but the level of false-positive results is unacceptably high.

Scrum is offered as a good way to identify "lagging employees." The problem is that it creates more inefficiently working programmers than it detects. This is a total surveillance system in which individual engineers show in detail the progress of their work, with an assessment of productivity.

A common mistake is often mentioned in the debate on civil liberties: the “nothing to hide” argument. Some people like to say that invading privacy, say, by law enforcement, is not a problem, because they are not criminals themselves. These people miss a few key things. For example, that the laws are changing. Ask anyone who was Jewish in Central Europe in the 1930s. Even for respectable people, a state of surveillance is a state of alarm.

The fact of observation changes the way people work. In creative areas it hurts. It’s almost impossible to work creatively if you need to report on work every day.

Another theme comes to mind: status sensitivity.. Programmers love to pretend that they have overcome several million years of evolution of primates associated with social status, but the fact is that social status matters, and it is not a shame to admit this fact. Older people, women, racial minorities and people with disabilities are usually sensitive to workplace status, because for them it is a matter of survival. Constant monitoring of work indicates a lack of trust and low social status, and the most sensitive to the status of people (even if they are the best workers) are the first to suffer from increased observation. If they feel that they are not trusted (and what else is transmitted by the culture, where each element of work needs to be approved?), Then they will quickly lose their motivation.

Agile and especially Scrum are vulnerable to the “nothing to hide” error. If you're not a “bad worker,” you're not against daily planners, right? The only people who will object to daily reports about their work in terms of short-term business value are “idlers” who want to steal money from the company, right? Well no. Obviously not.

The culture of violent transparency is designed for the most insensitive to the status of people: young, usually white or Asian, privileged men who have never been pressed at work. For those who think that HR and management is a waste of time, and the employee should just swallow humiliation and insults.

Often, the best employees suffer from the implementation of Agile / Scrum because R & D is effectively eliminated. Obsession with short-term “iterations” or sprints means the inability to try something new, risky.

The truth about lagging employees is that you can identify them without Agile. People know who they are. The reason why some teams are filled with idlers, incompetent or toxic people, is that nobody does anything with them. This is a management problem at the staff level, not at the workflow level.

6. Drunk effect.

It seems that aggressive management may make some slightly incompetent people quite able-bodied. I call it a drunken effect: when so-so girls become suitable, but really nice ones no longer want to have anything to do with you. In terms of staff - the best programmers leave because they do not have enough air for creativity in the system, where everything corresponds to the rules of short-term business profits.

From the point of view of a manager who doesn’t know how the software works, this may seem like an acceptable compromise: a few level 7+ “prima donnas” will leave the ship sailing at the Wonderful New Scrum, but 3 and 4 will become quite acceptable 5. The problem is that the difference between programmers 7 and 5 is significantly more than between 5 and 3. If you lose your best people and your leaders (who are not necessarily in leadership roles), then a small increase in the level of incompetent for whom Scrum is not brings benefits.

Scrum and Agile play what I call bias in changing status. In fact, many people judge their successes or failures not objectively, but on the basis of subjective changes in status. Convincing a programmer of level 5 to agree on the salary of a programmer of level 3 in a startup (in exchange for a share in a startup) is psychologically regarded not as a loss of money, but as a serious increase in status.

Agile / Scrum and the Age Discrimination Culture in general relate to obtaining the most impressive status profit, not actual economic profit. It can be achieved, as a rule, by hiring people who will bring the greatest value (even if you offer 50% higher than the market rate, because the best programmers are 10-30 times more than their market rate).

People who are least aware of what social status they “should” have are young people. You will find a 22-year-old level 6 programmer who thinks he has a level 3 and who agrees to Scrum, but the 50-year-old level 9 probably knows that he has 9 and may reluctantly accept the conditions of level 8.5, but for sure will not fall to 3 or even 6. The search for status profit is of course useless. These items mean nothing. You win in business on the difference in income and expenses, and not on the difference in meaningless status points. Maybe there is a whole industry in attracting engineers of the 5th level, regarding them (and paying for them) as 4, but in the current market conditions it is much more profitable to hire 8 and treat it as 8.

7. Unfair advertising.

Here I will focus on Scrum. Some argue that Scrum is an “extremist version of Agile,” while others say it is the furthest version of true Agile. (Perhaps, one of the problems manifests itself here: we cannot agree on what Agile is and is not).

Solutions like Scrum have their place: very limited, temporary. It is not fair to say that it works everywhere and on an ongoing basis.

What is Scrum good for

Before the fad of Agile made it an ongoing process, Scrum meant something like a “red code” or “emergency”. If an unexpected, rapidly developing problem arose, you would have gathered your best people and formed an emergency team.

This team will not have a clear manager, so you choose a leader (for example, “Scrum Master”) and give him authority. You do not want him to be the official “manager of the people” (as he should be as impartial as possible). Since the crisis is short-term, the career goals of individuals may be suspended. This is considered a “sprint” because people have to work as fast as they can to solve a problem, and because they will be allowed to return to their regular work as soon as the sprint ends. In addition, in such an emergency you need to make it clear that no one is assessed individually . The focus is on mission and mission only.

When you impose a process and demand the one-sided transparency of all workers, people feel that they are being watched. They understand that they will be labeled as “weak performers,” if week after week individual indicators go wrong. This offends people. It is dysfunctional. On the other hand, if you gather a group of proven specialists to cope with a specific and time-limited crisis, they do not object to frequent reports, if they understand that this is the urgency of the situation, and not their own low social status, caused this.

There are two scenarios that must come to mind. The first is the corporate “war room”. But if specific individuals (with the exception of top managers) spend more than 4 weeks per year in this mode, then something is wrong with the company, because emergency situations should be rare. Secondly, consultants who try to prove themselves or do poorly in customer service and establishing an independent reputation, and therefore must work in a permanent state of emergency.

Two problems

Thus, Scrum recognizes the idea that sometimes the authorities need to be delegated to “emergency” leaders: they will do everything they consider necessary to do the work, leaving the disputes for later. It's ok. Sometimes it should be that way.

The time-tested problem with emergency powers is that they often do not go away. In many cases, those who are authorized to lead during an emergency, consider it necessary to extend it. This is certainly a management problem. Dysfunction and emergency require more management effort than a well-managed company in peacetime. As a result, many managers, especially in the area of ​​technology, are seeking opportunities for emergencies and emergency powers.

An ambitious demagogue (Scrum Master?) Is easier to prove himself in a fight with dragons than to avoid them. The problem with Scrum’s aggressive insistence on business-oriented engineering is that it makes it worth it (“working with customers”) to attract and kill dragons (known as “requirements”) when it may be more sensible not to lure out of those caves.

Agile and Scrum glorify emergencies. This is their main problem. Some version of what the video game industry calls "show time." This does not allow stable work. Aggressive emphasis on individual productivity, lack of care for people’s career goals in the distribution of work and the mandate that people work only on the stated highest priority - all this gives great benefit in a short-term emergency, but becomes toxic and demoralizing in the long run. People will suffer a short-term loss of autonomy, but only if there is a clear point ahead when they return it.

The second problem is that this practice is dishonest.. There is a whole artisan industry that has grown around learning companies for "flexible" software development. The problem is that most basic ideas are not new. The terminology is fresh, but the concepts are mostly outdated, unsuccessful "scientific management" (which was far from scientific and did not work). Again, these processes sometimes work to achieve well-defined goals in emergency situations, but a permanent Scrum is a disaster.

If I get rid of the problems of Agile and Scrum, then I will not have such a strong problem with the concepts. If a company has a team of only junior developers and needs to quickly release functions, it should consider using these methods for a short time, with a plan for moving away from them as people grow and time frames become less rigid. But if Scrum is filed for what it is - a set of emergency measures that cannot be used to continually improve performance - then there will be far fewer “buyers” for it, and the Agile consulting industry will cease to exist. Only through unfair advertising of these methods (the famous “show-time”, packaged as permanent fixes), they become available for sale to the corporate world on a large scale.

Future

This culture of the subordinate position of the young, low autonomy and aggressive management, it is time to leave. These are not just bad ideas. There is a more serious danger here, because a generation of software engineers has grown up, who absorb them, not knowing anything better. There are too many young programmers who are doomed to be mediocre because they are convinced that business-oriented development and “user stories” have always worked this way. This should be prevented: the future of our industry depends on it. Agile, at least, and such a perverted implementation, like everything I've seen, is complete nonsense, which has nothing to do with programming and, of course, has nothing to do with computer science. Overall, business-oriented development is a dead end. She should be thrown back into the dirt from which she came out.