Myths and legends of Agile - from the Pharaohs to the present day

“Everything is poison, everything is medicine; both determine the dose. ”
Paracelsus

It is customary to count the history of Agile from February 2001, when a rather strange document was born - Agile Manifesto . By and large, the text of the document is composed of philosophical evidences (for example, “simplicity is the art of not doing extra work”) and controversial statements (for example, “the best technical requirements, design and architecture are obtained from a self-organized team”). But this document is strange not so much by its content (you never know what might come to mind at a ski resort), as by the epicity of the subsequent changes in the software development industry. In the shortest possible time, many techniques have emerged that implement the methodology of “flexible” development, which marched around the world in a solemn march, capturing the minds of the Performers and the wallets of the Customers. This movement is presented by adepts as a kind of magic pill that solves everything. It got to the point that a noble don honest programmer has become indecent to admit involvement in software development on the traditional orientation of the methodology. Let's try to understand the causes and effects of the phenomenon, using the example of Scrum , as the most common manifestation of Agile.

To begin with, we will try to understand what is really new in the Agile wrapper in general, and Scrum in particular.

Scrum in ancient Egypt

')
I dare to assert that the flexible methodology in general, and the Scrum technique in particular, have always existed, although they were not called. They were not called at all, but were simply the most natural and effective way to conduct their internal projects (the key word here is “internal”).

For example, the ancient Egyptian pharaoh decided to build a pyramid and ... it started. He discussed the idea with the priests (stakeholders) and appointed his butler in charge of the project (product owner). Vinocherp found a competent mason (scrum master). Mason hired assistants (scrum team), and they went to the slave market and recruited slaves (working tools: PC, server, software for development, etc.).

Since Pharaoh ordered him to report to him monthly on the progress of construction, the bricklayer (with assistants) began to hold a monthly demonstration of the construction site (demo) for the butler. During the show, not only what was already done (retrospective) was discussed, but a plan for the next month (sprint) was also drawn up. In order not to miss anything, the clerk spent a whole month discussing with the priests their user stories and writing them into a special backlog, from which the women got into the plan for the next month. Well, and so on. I don’t know what the stickers, scrum board and burndown diagrams looked like then. Any competent manager selects the most convenient tools for managing and controlling the project. Details here are not important, the main thing is that the technique works.

Those. I think that all managers at all times used a flexible method to create their own internal (at their own peril and risk) product because:

• competent enough to design the final result;
• competent enough to monitor the process;
• have enough power over subordinate participants in the process;
• the correlation of the term, cost and quality of work is not a dogma for them and can be revised if necessary (as “one’s own master”);
• and most importantly - the end result and the process of its achievement is in one hand, and pursue one commercial interest.

But for an external Customer, none of the items in this list is applicable, so for external (custom) projects, the flexible method was almost never used (exceptions only prove the rule). After all, the people were simple and intolerant, for the glaring excess of deadlines and estimates could be shortened on the head.

Scrum nowadays

The only novelty of modern Scrum is the fact of its use for the implementation of external (custom) projects. They try not to push this side of the question, because by pulling the thread you can pull out the real motivation of market participants. In fact, the Agile manifesto and the whole Scrum argument are pure propaganda of the Contractor’s interests, for the sake of appearances, veiled under the struggle for all the good against all the bad. That is the genius of the solution, which allows convincing the Customer to donate the result for the sake of the process!

So, what changes if the product owner is an employee of another, and not his own, company? The main difference is that the final result and the process of its achievement are now on opposite sides of the “barricade” and each of the parties pursues only its own commercial interest. The result is important for the customer, and the process is for the Contractor. There can be no other way - after all, “nothing personal, this is just business.”

Agile is beneficial for IT market players, as it provides them with the opportunity to:

• Earn on the process and not be responsible for the result;
• reduce the cost of competent management personnel (they are expensive, but now you don’t need to design anything and do not need to write TK, and the process is now controlled by the product owner of the Customer)

And once it is profitable, right before our eyes, programmer teams with a backbone of highly skilled and system-thinking professionals can turn into farms of rented medium-sized coders.

Try to put yourself in the place of a person who hires a team of builders to repair his apartment and tries to get the time and cost of repair from the foreman, and in response he hears:

• we are creative people, so we will work “as it goes,” but you pay for each hour of the work of the brigade and materials;
• we will not do the general project and plan, we will understand along the way (if we do something wrong, then we will redo it for the additional time paid by you and additional materials);
• we will show the results of our work every two weeks and talk about our problems, and then together we will plan the next two weeks.

It is unlikely that someone would agree with such a proposal, and customers of IT-Schnick agree! That's what makes life-giving propaganda!

Not only are customers convinced to agree to unpredictable time and cost, they also put all responsibility for failures on him. As a rule, the qualification of the Customer does not allow to formalize the requirements for the final result and to professionally control the course of the process. Therefore, one can always confuse him and divert him (in the absence of a common TK) to the solution of many minor issues (which arise most often due to the lack of long-term planning).

The aftermath of agile worship

Do not you think that the quality of software products falls in proportion to the width of Agile distribution in the industry? Where does quality come from if the whole process is focused on solving problems in the simplest and fastest way possible? And thinking ahead is officially forbidden by methodology!

Do not you think that software products are increasingly turning into “quilts” when you notice with surprise that different sections of the same software seem to be made by completely different people? And even on one screen, programs can mix different styles of design, different approaches to ergonomics, and different algorithms for the functioning of similar controls. But after all, TK and the Style Guide for the product are missing, so to whom as usual, he will do so! And the QA-staff, like everyone, is locked within the timing of the sprint.

What is it all about?

From the foregoing it may seem that I am an ardent Agile-hater. But this is not the case at all! And I did not try to offend anyone at all! I just tried to illustrate the words of the great Paracelsus in the epigraph more clearly.

The flexible methodology is quite suitable for internal small and even medium projects. The size of the project is limited only by the abilities of a specific manager “not to lose the forest for the trees”, i.e. ability to keep in mind, as all the details, and the desired result, without systematizing it "on paper".

Flexible methodology is limited and suitable for external projects. In this case, the same requirements apply to the product owner of the Customer as to the manager of the internal project, i.e. this person must be a real IT professional, and not a secretary who pulls a temporary burden in combination. He must be able to verify the qualifications of the hired team and constantly monitor the quality of the product being developed. In addition, the product being developed must allow (in case of force majeure) the replacement of the development team. Only in this case, one can expect that it will not be "insulting and painful for aimlessly lived years."

As you can see, Agile has its place in the sun, but it is very limited in the field of contract-based IT development. What to do if your project does not fall into the category of Agile-suitable?

Doesn't it seem suspicious to you that the flexible methodology has not taken root anywhere except in contract software development? Well, neither submarines, nor airplanes, nor cars do Scrum. The wisdom of the ancestors teaches us that even a normal dog house cannot be put together without a design stage (pencil sketch with dimensions) and preparation of the TK (list of materials and tools). Everything that you see around (from the stool to the spacecraft) is created by the good old "waterfall" (waterfall) . Why don't you do the same? And remember - everything will be fine!

PS

All of the above is based on my personal considerable (19 years) experience in contract web development using both traditional (Waterfall) and progressive (Scrum) approaches. The motive for writing the article was the moral torment of contemplating the next "miracle of hostile technologies", cobbled together according to the precepts of the great Frankenstein for one respected Western company.