O'Zhal: What's wrong with flexible methodologies

Using the term Agile, people often mean not something specific, but that they are right. For example, I did not write tests - not Agile, did not hold a meeting with the team - not Agile, did not fill in time-tracking - again, not Agile. The fact that everyone interprets the term Agile in its own way, there are objective reasons related to its origin.

Words on the board

It is no secret that the rally that occurred in February 2001 at a ski resort in the state of Utah was the source of all Agile movements. As Robert C. Martin, the instigator of the event, put it, a group of smart people gathered there who had never met before and did not plan to meet in the future. The purpose of the meeting was one - to express something in common that would unite all those present.
')
There are many articles written by the participants of the process themselves [ 1 ], [ 2 ], [ 3 ] about how the Agile manifest was created. The essence of what was happening was as follows: each of the participants wrote out ideas on cards that expressed his point of view, and after the cards were organized into categories, four points became obvious, in which everyone was unanimous . Further, they were beautifully formulated:

• People and interaction are more important than processes and tools.
• A working product is more important than comprehensive documentation.
• Cooperation with the customer is more important than agreeing the terms of the contract.
• Readiness for change is more important than following the original plan.

That is, without denying the importance of what is on the right, we still value more of what is on the left.

The document had to come up with a name for which the word Agile was chosen by vote, as Martin Fowler admits is not a very suitable word.

Insignificant addition

Further, the Agile manifesto was extended by 12 principles , but it took several more months of e-mail correspondence to finalize them , which suggests their secondary importance.

By the way, one of the principles is a release with a frequency of two weeks to two months, which, compared with modern norms - a couple of releases per day - sounds archaic.

With other points, too, not everything goes smoothly, here is another example: “ Work software is the main measure of project progress ”. This is a dubious metric just because a tested and released application doesn’t mean that it will be useful to anyone.

Unexpected consequences

Seventeen far from ordinary people took part in the event. A short list of their achievements and contributions to the industry can be viewed.


If you visualize the list of Agile creators by their relation to technologies and methodologies, you get a curious picture:



In general, participants can be divided into three categories:

1. Engineers: Robert C. Martin, for example - those who primarily influenced the development of technology.
2. Managers: Ken Schwaber, Jeff Sutherland - made a significant contribution to the development of methodologies, but not to technology.
3. Management Engineers: Kent Beck and Ward Cunningham - influenced both technology and methodology.

Surprisingly, but it was managers who benefited most from Agile.
Engineers with XP and other similar methodologies lost, a little more on that later.

The most interesting thing is that, as a result, engineers stood up in opposition and even began to fight Agile. For example, despite the fact that Robert C. Martin was one of the main organizers of the event, now he not only opposes, but also compiled his Software Craftsmanship Manifesto . Flexibility is flexibility, but we are professionals and should work as befits professionals, without slipping into trash and haste.

XP and other outdated methodologies

There are many good reasons why XP, ASD, or Crystal have failed. These methodologies have a lot in common, so let's see what is wrong with them on the example of XP, because unlike the others, it at least still pops up in memory.

Perhaps the main problem with XP is that it is too detailed. The book on XP contains 160 pages : it is difficult to imagine that such a guide can be fully implemented in mass development, because each project has its own specifics.

In addition, in addition to the principles of organization of work, XP imposes a huge number of ways to carry it out , and expensive ways. Pair programming is quite a sensible technique, but it is only a means to achieve a certain level of quality and ownership of the code. What if you can achieve the same results with less effort? And what if working in another way, for example, by quickly correcting problems, can we achieve more?

But the individual technical concepts presented in XP have become industry standards. Now you will not surprise anyone Continuous Integration or Daily Deployment. But the fact of the matter is that everyone has this.

All scrum

Of all the Agile methodologies, only Scrum was included in the broad appeal, and its prevalence is largely justified. Yes, this is a complex methodology. Yes, very often Scrum is implemented incorrectly, it turns out that hell. Yes, work on Scrum tends to lead to an increase in technical debt. Yes, a lot of things. But still Scrum is the best thing on the market. If you apply it intelligently and purposefully, the result will be.
The problem is that there are no good alternatives for Scrum, there is no competition. And this is an unhealthy situation for the industry as a whole, and for the Scrum community in particular.

O'zhal

Under the flag of Agile, many private methodologies have been invented, and they probably work well for authors , but are they applicable to the industry as a whole? Why are there no good alternatives for Scrum? While Scrum appeared before Agile, are there any reasons to expect that methodologies of the same level will be created on the basis of Agile?

Agile - these are four statements expressing the common thoughts of several smart and successful people. But each of them has a significantly larger picture of values, and this is only the minimum in which they came together based on their personal experience at that time. Not surprisingly, there are many problems in the manifesto.

Incompleteness - if out of two good ideas, say, “go to the cinema” or “go to the theater”, try to mechanically isolate the general, it will turn out to “go somewhere”, which no longer seems like a good idea. In their work, each of the participants was guided by a large number of principles, so it is quite reasonable to assume that everyone agreed with the minimum is not enough to achieve success.

Superficiality - the code is more important than the documentation, it is immediately clear that engineers have gathered. Solving the client’s tasks is more important than observing bureaucratic formalities; perhaps it would be more correct.

Uncertainty - only at first glance everything seems clear, but once these principles fall into a concrete situation, the right decision becomes far from obvious. Moreover, if you wish, you can find an article confirming any of the emerging points of view.

Naive altruism - cooperation is more important than agreeing on conditions only until penalties come. The requirement to sign under the manifest implies that you need to agree with all four statements. But what if circumstances do not allow? Can I follow only three of them without too much guilt for not following the fourth?

A narrow audience - the manifesto goes to development, but what about the customers? It would be naive to hope that the rules can be changed only from the side of development, if clients continue to work in the old way.

The key goal of the manifesto was to show the development industry that the processes, methodologies and development itself can be conducted differently, make people think about it. In this sense, the manifesto should be recognized as a complete success. As for the content, this is rather a curious document, reflecting the sore problems of developing the beginning of zero, rather than the fundamental principles that we all should follow.

Yet Agile

The main achievement of the Agile-initiative was the promise - you can work differently. You can look for other ways to achieve goals, try non-standard solutions to problems, creatively approach the organization of work, look at things more widely than your specialization, try, make mistakes.

All this could have been done before Agile, but it was necessary to have great courage and authority in order to offer something new. Agile allowed us to openly talk about problems and discuss unofficial solutions.