Agile analysis. Myths and Reality

I Introduction

The booth must be transferred! Season does not happen, so a couple of not shandarahnulo.
That confused with a toilet, then with a beach cabin ...
(c / f Features of national fishing)

The end of the year, summing up, filling out forms and other pre-holiday tinsel of IT functionaries. I already once again catch the eye of the final questionnaires of IT firms, designed to identify trends in approaches to product development. And every time there is a feeling of some kind of trick when you answer questions like: “You still use the Waterfall method (waterfall model), or you still (like all advanced humanity) practice Agile (flexible methodologies)”. When you start to find out from the author of this survey, and what he understands under Agile, his explanations somehow do not fall much into the outline of the manifesto (Agile Manifesto). He really thinks about many principles for the first time, and these very principles really confuse him. But after a little confusion, heavy artillery is being used with reinforced concrete substantiation of its position:

The very thesis “Flexible methodologies” is so gutta-percha still in its sound that many try to squeeze anything into it, or rather what is most beneficial for them. Gradually, it became a fashionable screen, which can cover all its shortcomings and even sloppiness, in the process of producing IT products, and at the same time, as it were, remain on the crest of a wave, in a trend. They say we are not - and the technique is.

Let's together, once again “strike with analysis” on the topic of Flexible methodologies, try to lay out the main artifacts and principles on the shelves and separate the sacred meaning that was originally included in this concept from what it was converted into by some careless populists. We also compare the approaches of Agile with other methods for a more accurate understanding of the face that separates them, or vice versa - combines. At the same time, we’ll try to figure out where the use of Agile principles is most appropriate, and where it’s not entirely appropriate?

II Background to the emergence of software development techniques

History is like meat pate: it is better not to peer how it is cooked.
Aldous Huxley

For the sake of objectivity, let’s dive into history and feel the circumstances that formed the ground on which various principles and methods of developing software products, including Flexible, have grown.

1. Myths and reality about Waterfall

As already mentioned in the introduction, antagonism (sacrificial offering) for Agile (1) was chosen Waterfall technique, which in its pure form was relevant in the last century, during punched cards and tape drives and presented to the world for the first time in the article by W. Royce ( WW Royce), published in 1970.

Such a comparison undoubtedly helps any other methodology to look fresh and innovative in comparison with it. For the sake of persuasiveness, some speakers represent the Waterfall model not as an iterative, but as a one-time, monolithic flow of work that passes through the phase: requirements analysis, design, implementation, testing, integration and support. I was especially impressed by the phrase about the development methods that was checked up in the article, before the Ajayil period: “Before, products were made entirely at once. To do this, went through the chain: the idea → technical task → design → programming → testing → release ". Excuse me, but Royce used an iterative development model in his approach. So cynically simplifying an idea is simply not ethical, especially considering that there was no vacuum between Waterfall and Agile,

Although in fairness, one must admit that most of what has been said about Waterfall is generally not far from the truth. If the team was aware at some stage that the result did not meet the expectations, then either “finished off” to the logical end not an entirely suitable product, or threw most of the work into the basket, and started the process almost from the very beginning, actually creating a new product. Why, despite some absurdity by today's standards of such an approach, has the technique for a long time remained a popular flagship in the software development world?

In order to comprehend this phenomenon, we immerse ourselves in the atmosphere of the then Computing Centers (EC). Let me remind you that in those far, distant times, the path from the developers' idea to the execution of its computer was long and thorny. He ran through already forgotten data preparation devices that perform mechanical punching of punched cards and affectionately called “barmalia”. This operation was carried out not by the developers themselves, but by specially trained people. Having received a cherished stack of holed cartons, in turn, taking into account the efficiency of the computer, these punched cards were laid in a special device (again, by specially trained people), which read the code and only after that, he had a chance to be executed by the processor. But if one of the punched cards in the deck jams when reading, you should repeat the procedure for reading the entire deck again. And God forbid, there was an error in the code, it was necessary to re-resort to the help of the bogeyman, to kill part of the punched cards and, without confusing them in places in the deck, to repeat the whole procedure once more. Similar delights work of the then programmers was littered all over. Naturally, the rapid changes in the requirements for the product being developed in the course of its implementation, with such an approach, it could be. The quality requirements for the product being developed and the strictly regulated process of its production were for the then teams All. Naturally, the rapid changes in the requirements for the product being developed in the course of its implementation, with such an approach, it could be. The quality requirements for the product being developed and the strictly regulated process of its production were for the then teams All. Naturally, the rapid changes in the requirements for the product being developed in the course of its implementation, with such an approach, it could be. The quality requirements for the product being developed and the strictly regulated process of its production were for the then teams All.

2. What if not Waterfall?

But time passed and everything changed. The personal computers gradually replaced the huge digital monsters with a capsule for the digital world. The number of operations performed by processors per unit of time has increased by several orders of magnitude, and the speed of an information I / O operation began to seem simply "cosmic." Programmers got direct and instant access to the execution of the code just typed - by computing resources, on the spot. Now to make changes to the work of the software has become much easier, and to imagine that someone else continues to work on the method of Waterfall in its pure form is simply ridiculous.

Natural selection and the need to adapt, made the methods mutate. However, most of them borrowed from their predecessors an iterative development model. Just execution cycles have been significantly reduced and improved.

But then another attack arose. Unprecedented opportunities have allowed moving from automating individual production areas to automating entire enterprises and even waving fully on the industry. With such volumes of operations and the quantities of resources involved, it was simply impossible to simplify the methods of developing software products. On the contrary, they have become even more sweeping and formalized.

The Rational Unified Process (RUP) has become one of the most well-known methods using the iterative development model. It was developed and implemented in the second half of the 1990s by Rational Software.

The term RUP is not only a software development methodology, but also a set of tools that allow you to manage development processes. Within the framework of the topic under consideration, it is especially interesting to note that the RUP (2) methodology describes an abstract overall process, on the basis of which an organization or a project team can create its own unique software development process that is focused on its own needs. What say this approach is not flexible?

In further analysis and comparisons, it can be noted that some of the key features of RUP were also partially inherited from the Waterfall technique.

1. Cyclic software production approach . The life cycle of the RUP project is divided into 4 phases and 9 workflows.
2. Iterative development process . The RUP project consists of a sequence of iterations with a recommended duration of 2 to 6 weeks.
3. Mandatory requirements development . Use cases are used to describe requirements in RUP. Each use case is a description of the scenario of user interaction with the system, fully performing a specific user task.
4. Incremental approach aimed at incremental increase of product functionality. The basic unit of iteration planning is the use case, which allows you to make the necessary changes to the requirements, design decisions and implementation during the project.

Pay special attention to the last point. It argues that it is precisely the presence of detailed requirements, drawn up in a particular form, that provide the opportunity to effectively make changes to design decisions and product sales during the project. Including in the late stages of the project.

Often, RUP is mistakenly considered a heavy process with a high level of formalism. But this is not quite the case, since the RUP process can (and should) be customized for the specific organization and project. Even if the team takes on a small software product that will need to be refined, scaled or integrated with other systems, then RUP will quite comfortably cope with all arising calls.

3. The overthrow of the foundations

And further more. Having skipped the period of coming to our world of personal computers, let us proceed to the emergence of all sorts of instrumental studios, visualization and modeling tools, automated application builders, etc. In all this variety of helpers, allowing, for example, dragging an element on a diagram with a mouse, and getting automatically changed application code for the final product, began to depreciate the very role of software development methods. Having such advanced tools, with a lack of time or resources, it is possible to abandon some of the working processes of the methodology and at the same time virtually nothing to lose. At least in the short term. These freedoms and, as impunity turned out, with due professionalism of the performers, led the most desperate heads to proclaim a new IT trend - “Flexible development methodologies”.

Here in this place from the red line, I emphasize once again a very important thesis, perhaps the key one - “with due professionalism”! That is, high-class specialists, behind whom there are dozens of large realized projects that are able to sketch a class diagram of a small module in their head for 20 minutes, immediately estimate the processes changing their states, assume critical dependencies, etc. decided that they could, in some cases, do without the mandatory passage of the adopted regulations. At the same time, the project will nevertheless be brought to the expected result with an acceptable quality in a much shorter time frame. Is it bad or good? At first glance, just wonderful. On the second, not everything is so simple. Let us analyze the pros and cons a little later.

Definitely bad here is different. Young and insolent, looking at it from the outside, ask themselves the question: “Well, was it possible?”. They have never seen quality requirements in their eyes, they cannot read diagrams, but now they don’t need it. Everything! requirements are now canceled! Diagrams, modeling process - there in the furnace. Only code, code and chat. As a bonus - they can leave their comments in the code, for future generations of the same bold.

At this, the historical excursion can be completed and go closer to the body so to speak ...

III Analysis of the phenomenon of flexible methodologies

Every entity should be analyzed in terms of logic, before poking into the mouth.
Woody Allen.

1. Definitions of Flexible Methodologies

Since Ajaila has been around for many years, let's use the available information and first, let's review the definitions and opinions that head the top in the network. And having already pushed off from them, let's move on to the main artifact - the Manifest of flexible software development.

The first thing that was found in a search engine for the term Agile:

Agile development (English Agile software development, agile-methods.) - a series of approaches to software development, focused on the use of iterative development, dynamic generation requirements and ensure their implementation as a result of constant interaction within the self-organizing working groups, consisting of experts in various fields.

The following important points can be distinguished from this definition:

1. Using an iterative approach . There is nothing new about software development methods that deny this principle, I personally have not heard;
2. Formation of requirements is carried out in stages, in the course of product development . This is a key difference from many other methods. In some ways it gives an advantage, in some it introduces fundamental limitations. We will discuss this and that later;
3. The use of continuous close interaction of all team members , including the customer. In most other methodologies, of course, attention is paid to teamwork, including with customers, but positioning this communication as an additional project resource, giving an undoubted advantage, is rather exclusive;
4. Self-organizing team . It is assumed that each iteration ends with a debriefing (retrospective) and the introduction of constructive changes in the process, which contributes to the continuous development of the team. Such techniques are most likely borrowed from earlier techniques. For example, it is practicing RUP.

In principle, not much has been found out from this description, so let's move on to the clarifications:

Most of the flexible methodologies are aimed at minimizing risks by reducing development to a series of short cycles called iterations, which usually last two to three weeks. Each iteration itself looks like a software project in miniature and includes all the tasks necessary for issuing a mini-increment in functionality: planning, requirements analysis, design, programming, testing and documentation.

But we have already considered this approach in the good old RUP. That is, there is also nothing radically new.

Most of the definitions I have found are also abstract and vague, very little information allows us to immediately take up and begin to use flexibility. But here another no less important side of the approach opens, bringing clarity to that superficiality, which shows the entire topic under consideration. For example:

Agile does not include practices, but defines the values ​​and principles that guide the teams. Agile is a family of development processes, not the only software development approach, and is defined by Agile Manifesto.

Adjail is a way of thinking with its own value system. It is similar to philosophy, religion, or culture — the same set of attitudes that a person believes in and that influences his behavior.

Apparently for this very reason, there are countless disputes around Flexible Methodologies. Not so much in the very idea of ​​what you can really touch. Apparently for the same reason, it is possible to call something of your own (almost any), unconventional - flexible methodologies and not be found out to be unprofessional. In my opinion, this is acceptable, if you want to be in trend - call your approach to development as fashionably as you like, if only the development process and the final product itself do not suffer.

I recall a case from my own practice, when a large IT company decided to improve its technological processes before a large-scale project. To this end (as recommended), a specialist in flexible methodologies was invited, on whose shoulders this responsible mission was assigned. After reading a very short lecture on the way of thinking and the Ajayl system of values, he began to find out what the actual situation with the production of software in the enterprise was. Finding flaws and inconsistencies in existing processes, together with the team of the enterprise, selected the most appropriate ways and methods to solve them. Fortunately, these shortcomings were no secret to anyone, but a number of reasons interfered with overcoming them. For example: lack of time, contradictions between teams subordinate to different management verticals, fear of taking responsibility, etc. Since all this event was patronized by the top management of the company, and the invited specialist was really a high-class IT professional, the innovations developed were brought to life, almost on time and with a very sensitive, positive effect. But they had nothing to do with the Manifesto of flexible methodologies. As a result, most of the company's employees remained confident that now they completely switched to Adjail, abandoned everything else. All this is very reminiscent of a fairy tale about how a soldier made porridge from an ax, cunningly drawing out from the owners the ingredients he needed and improving the taste of the dish. That's just the ax is not boiled down. almost in time and with a very sensitive, positive effect. But they had nothing to do with the Manifesto of flexible methodologies. As a result, most of the company's employees remained confident that now they completely switched to Adjail, abandoned everything else. All this is very reminiscent of a fairy tale about how a soldier made porridge from an ax, cunningly drawing out from the owners the ingredients he needed and improving the taste of the dish. That's just the ax is not boiled down. almost in time and with a very sensitive, positive effect. But they had nothing to do with the Manifesto of flexible methodologies. As a result, most of the company's employees remained confident that now they completely switched to Adjail, abandoned everything else. All this is very reminiscent of a fairy tale about how a soldier made porridge from an ax, cunningly drawing out from the owners the ingredients he needed and improving the taste of the dish. That's just the ax is not boiled down. He needs the ingredients and improving the taste of the dish. That's just the ax is not boiled down. He needs the ingredients and improving the taste of the dish. That's just the ax is not boiled down.

But since we have gathered here to analyze the Agile phenomenon impartially, we will therefore continue our research. Let us turn to the original source - Manifesto Ajail:

2. Let's analyze the main ideas of Agile Manifesto

Key ideas:

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

Let's start with a fly in the ointment. For me personally, all points are controversial. Let's go in order:

Item 1 . In my opinion, one of the key reasons for the emergence of Ajail, as I wrote above, was the rapid development of automation systems for software development processes that made it possible to neglect the regulations. That is, it is just the displacement of monotonous human labor by robotized processes and allows to produce more reliable and predictable results, including maintaining high-quality interaction of the processes themselves. Therefore, about “People - most important of all,” in my opinion, this is just a slogan helping to amuse the human pride of the most sentimental team members.

But in fairness, I note that the young employees have these slogans, clapping their hands in retrospect and other sentiments, are quite effective and even (at first) raise the team spirit. It is important that there is no emptiness and disappointment when the understanding of the holiday leaves.

Item 2 . Development is only a short moment in the life of an automated system, and then begins the harsh everyday life of its operation, modernization and expansion of opportunities. Have you ever tried to maintain a good software product, completely devoid of documentation? What is happening in it and why it is this way, and most importantly, how can it be corrected so that it starts working a little differently? And if it interacts with other software, then what can be changed in it at all, and what cannot be touched? All this is reminiscent of walking on a minefield.

And here we add the principle of phased development. Without documentation, it will still be necessary to determine at what stage of development the product is in general.

But for the sake of objectivity, it should be noted that when a team delivers an already finished product to a customer, assembled from a heap of modules, installed on a heap of various equipment, and also under a “non-child” load, then it is highly likely that it will be necessary to modify or change the code. Sometimes changes can be numerous and profound. And here it is definitely not up to the formalism, it is necessary to save the face of the team. During this period, you can postpone documentation until better times and rush to edit the code. I want to note that it is much more comfortable to do when there is decent documentation at hand that was compiled during the development stage, with a description of how everything worked at the time of the introduction.

Point 3. Well, for starters, the point is not clear in itself the opposition Is not agreement negotiation a collaboration with a customer? If the customer, as a result of clarifying the terms of the contract with the development team, will be able to understand the scope of work, approximately realize the cost of their implementation, and most importantly imagine the result that he can get in some tangible indicators (automated business functions, form layouts, etc. .). After all, it will be easier for him to make a decision: does he need this particular product, is he ready to finance its production, etc. Isn't that a collaboration?

What is cooperation then? Just warm talk for a life without any commitment? How not cool if the project is commercial, all parties first need to achieve their goals in the project. And the terms of the contract - just fix these very goals and how to achieve them. At the time of working out and agreeing on a contract, both parties begin to realize that it is from them that the partners are expected to receive and the degree of responsibility in the event that the agreed result is not achieved. The contract in this case is a motivator and a means of settling differences, for those and others. After all, it is not extremes that are most terrible, but uncertainty.

There is no contract - there is no responsibility, there is no complete understanding of what should result from the completion of the project. This approach suits you - good luck.

Point 4. We have already said above that, given the availability of modern software design and development tools, there is no particular difficulty for a team of professional developers to make changes to the implementation of a product at almost any stage. This is a normal process, depending to a greater degree on the team’s depth of understanding of the product they are developing. Therefore, in this case, the question is not so much about the readiness of the team to make changes, but about who will pay for all these excesses. This is where the high-quality contract that comes to the fore, which determines who and in what cases incurs material losses from the reformation. Whether the developers rework at their own expense, what they misunderstood or the customer, who did not correctly explain what he needed.

3. Discuss the principles of Agile Manifesto

Since we want to understand the topic in an unbiased way, let us at least briefly touch upon the principles explained by Agile Manifesto:

• customer satisfaction with the early and uninterrupted supply of valuable software;
• welcome changes in requirements even at the end of development (this can increase the competitiveness of the product received);
• frequent delivery of working software (every month or week or more often);
• close, daily customer communication with developers throughout the project;
• The project deals with motivated individuals who are provided with the right working conditions, support and trust;
• The recommended method of transmitting information is face-to-face conversation;
• working software is the best measure of progress;
• Sponsors, developers and users should be able to maintain a constant pace for an indefinite period;
• constant focus on technical excellence and user-friendly design;
• simplicity is the art of not doing extra work;
• the best technical requirements, design and architecture are obtained from the self-organized team;
• constant adaptation to changing circumstances. The team should systematically analyze possible ways to improve efficiency and adjust the style of their work accordingly.

Most of the above does not contradict other methods and is very appropriate.

But not always these principles can actually be used in practice. For example, the customer can not always cooperate with the team when discussing solutions. He often has a banal no time, and sometimes a special desire. Then you need a pro - analyst who is capable of compressed lines, unobtrusively, rubbing in trust and using all his psychological “tricks” to draw useful information out of it and already combing it smoothly, smoothly, convey to the team of developers in the form most suitable for implementation. I wonder if this happens, the work of the team ceases to be considered flexible?

For the same reason, it is not always possible to organize frequent deliveries. And this process can be seriously influenced by a certain number of integrable modules developed by different teams, which can be assembled at the same time (modules) on one piece of equipment. Yes, and specific equipment, it so happens that comes directly closer to delivery. This also needs to be considered.

And I feel dissonance in the statement about the "best technical requirements, design and architecture," despite the fact that the principles of Agile, in principle, do not welcome documentation and all that jazz. If you “offend” the formal approach to documentation, it is unlikely that it will turn out to be the best (popular wisdom).

Also, from my point of view, there is a censure - raising to the rank the best method of transmitting information - “personal talk (face to face)”. In my opinion, transmitting information in a project is much more efficient, for example, using a task tracker or a wiki system, and of course personal communication is not excluded.

IV Application of flexible methodologies

In innovation, you must be both stubborn and flexible.
If you are not stubborn, you will abandon experiments too early.
If you are not flexible, you will bang your head against the wall and you will not see another solution to the problem that you are trying to solve.
Jeffrey Preston.

If during review there were so many critical evaluations, how does all this work?
The success of Agile, apparently contributes to the effectiveness of the use of methods in small projects and the generality (simultaneity) of the use of all the above points.

1. The benefits of using Agile

Through the use of User Stories, the development team manages to achieve the necessary level of understanding in discussions with the customer. For the customer, the threshold for entering the topic is reduced, it is easier for him to operate with the project content, setting priorities, correcting inaccuracies, etc. Moreover, even project managers, product managers, and other team managers, who are straining to understand specifications of requirements, based on simple User stories, can make it much easier to juggle tasks in a project and understand customer expectations.

Due to the frequent deliveries of prototypes, it is possible to avoid large discrepancies between the customer's expectations and the options proposed by the implementers of the solutions. With each new release, more and more bringing them closer to each other. Drawdowns in the time of execution and, accordingly, financial losses are also not large and predictable; they can be laid directly into the project plan.

It looks like this: The customer expects to get some new functionality, the capabilities of which he himself does not fully represent. There is a “close cooperation”, as a result of which the contractor offers a pilot solution, usually not completely satisfying the customer's expectations, which he notifies the team. This episode leads to a new “close cooperation”, as a result of which the performer makes adjustments to the prototype and again presents the product to the customer. And so in a circle until the complete victory of a certain functionality over the customer’s mind, or until the cooperation becomes so “crowded” that it will no longer be comfortable to remain in it. If the complexity of the product and the number of automated functions allows you to perform 3-6 such cycles for complete and unconditional customer happiness, then why not,

The only thing I want to emphasize is the principle point, which often remains without proper attention - the need to be fixed in documents (at least after the fact), the technical solution of which was achieved as a result of trial and error. This is important, as the customer, who may then hire a new team to refine or scale the product, and for the team itself, which, firstly, will be able to replicate the solution or part of it, and secondly, if it is re-engaged to upgrade the product, faster and better to join the process.

2. Small projects - a comfortable environment for Agile.

For small projects, the use of User stories, instead of full-fledged requirements for the product being developed, makes it easier and more comfortable to communicate with the customer. Due to the frequent interaction with the client and the simplicity of the form of communication, the team does not wash, as skating develops acceptable requirements for the functionality of the product. In the absence of complex algorithms and integration with other software, this can occur without significant losses. The level of the domain of problems - close User stories, and the domain of solutions - comments in the code.

Using a team of professionals, you can not bother to work out the solution architecture and specifications of product requirements. Surely something like this team or its members have already decided, and they have suitable templates and developments behind them.

If this product is a one-time product and is not planned to be developed, then this is quite enough.

3. How can Agile be used in medium projects

Using Agile in medium projects can also be very effective.

In larger projects, various automation platforms can be used, equipped with ready-made templates, practices, self-documentation tools, etc. This greatly simplifies formal processes, including design, modeling, and documentation. The solutions presented in such cases are most often replicated, with a limited number of modifications and changes.

The greatest effect can be obtained if previous similar decisions are documented. Having repulsed from this basis, one can spend more time not on designing and modeling, but on selecting, together with the customer, the necessary prototype. “Try it on, put it on - and go. Do not press? ". It is important that new, implemented solutions are also well documented. In this case, the team receives a set of cubes and instructions for assembling various models from them that can be offered to future customers.

In this work model, it is important to understand that Agile does not deny the importance of the documentation process, it simply allows you to delay its formation, giving priority to the construction of the product itself (if this is possible in the current situation). Documentation can be formed after receiving a sustainable product, consolidating the achieved results and, as noted above, helping not to lose further the thread of understanding the rules of the system.

4. How to effectively use Agile in large integration projects

In large and complex projects in which quality documentation is conducted, there is an architectural representation of the product and the process of its production, “pieces” of the product can be outsourced to small teams. This transfer occurs after a detailed study of the overall architecture and the compilation of high-level requirements for new subsystems. And now these relatively small parts can be quite effectively implemented using Agile.

The same scheme is applicable for small modifications or the gradual development of a large complex system, especially if some research work is required.

Another option to use Agile in large projects can be effectively applied when rush delivery of the product to the customer. In view of the critical shortage of time and resources for its refinement and correction, to help prevent a fiasco, it can be flexibility in the approach. In such situations, in my opinion, it is this methodology that is optimal.

In this section, it is worth mentioning the existing methods, based on Agile, but aggravating to the solution of large-scale tasks.

Flexible Unified Process (AUP, Eng. Agile Unified Process) is a simplified version of the Unified Process (UP) developed by Scott Embler. This software development methodology combines elements of flexible methodologies and a unified process. In particular, AUP involves the development through testing (TDD), the use of flexible modeling (eng. Agile modeling) and database refactoring, flexible change management.

OpenUP is an iterative-incremental method of software development. Positioned as a light and flexible version of RUP. OpenUP divides the project life cycle into four phases: the initial phase, the refinement, design, and transfer phases. The project life cycle ensures that stakeholders and team members get to know and make points throughout the project. This allows you to effectively control the situation and make decisions about the acceptability of the results in time. The project plan defines the life cycle, and the end result is the final application.

5. How not to use Agile

Not less important section, perhaps for the sake of which the whole analysis was started.

1. The leader in my anti-rating is the situation when Agile, or rather some of its principles, are trying to use not to achieve any specific goals that they allow to ensure, but simply # POTOMUSTO. Because it is a trend, it is on everyone’s lips. For example, someone shared positive feedback on the IT party, a bit ephemeral and even arrogant, but the rumor went, an entourage appeared. And now they called themselves followers of Agile, feel in communication with the others - belonging to a certain elite club. All this is facilitated by the seeming simplicity of the methodology and the hazy outlines of its borders. Implementation on this principle is thoughtless and formal. People formally and unprincipledly implement principles designed to reduce formalism.
   
   For example, one of the most recent cases. In one company, conducting retrospectives, they were forbidden to visit them with timlides. Here's a chip. Suddenly. The first thought: well, maybe they are right, so that there is no such thing as pressure from authorities on the team when discussing problems, etc. But the Timlids are offended, they are at a loss and want to understand. I tried to convince everyone that they say it could be better, the main thing is that they give you a wish list, a list of what needs to be changed, what to improve, and so on. And it was here that a terrible secret was revealed. And what outcomes and wishes for the improvement of processes do not arise as a result of these gatherings. IT_shniki gentlemen, but why then such a retrospective? Just praise each other and raise the team spirit? They said A, say and B. After all, the main purpose of this methodology process is that:
2. The second situation in my ranking is when teams decide to save on the preparation of requirements in projects with complex behavioral or logical algorithms. That is, when the user story is only a small tip of the iceberg of the problem, and its main part is not visible and requires detailed, careful analysis and design for implementation . What happens when this happens?
   
   Before starting work, neither the customer nor the developers even approximately understand the amount of work they need to do. And accordingly: either the customer will pay, pay and pay, every time he will be explained that everything turned out to be much harder and now there’s no end to the edge of the work. And after all, it will be a pity to quit and gradually begin to put in a stern understanding that this “golden” product will never pay off. Either the developers, having contracted to perform work for a certain amount / time, will at their own expense (free of charge) finish and redo the product until the customer's imagination runs out, or he takes pity on the victims of the flexible approach.
3. The honorable third place is taken by the situation when the team decides to save on the elaboration of the solution architecture in a large multifunctional project (and suddenly also an integration project) and to implement individual user stories in short iterations. It is very likely that after 3-5 iterations, when trying to create a new functional, it turns out that it is necessary to redo all the previous ones, since they did not take into account the fundamental principles on which this functional should be based. Even worse, even after the 10th iteration, it turns out that the selected technologies do not allow to satisfy all the needs of the customer and we must start all over again. Perhaps changing the command.
4. The situation in which a sharp and incredibly flexible start-up breaks into the open spaces of the sluggish market segment has not hit the top three. A startup, he is a startup, that there are no foundations, braces, attachments, and at the same time, stability and stability. To put it simply, there is almost no documentation, the team is not harmonious and often changes. The market is literally tearing up the team, demanding more and more new solutions in the sticking area, and all subsequent projects just fall apart before our eyes. Most often, everything is explained by the fact that the team does not have an understanding of the processes of industrial software production , organizing the delivery and support of the product.

Let's sum up

In preparing this article, I tried to help teams interested in the Agile approach to highlight and formalize the challenges they have to face in one way or another, as well as to find possible solutions to overcome them. I tried to consider the topic as tolerantly as possible, both for apologists for introducing one or several methodologies from this group, and for opponents who want to debunk the aura of flexibility and are motivated to refuse to use it.

I hope that the analysis will help the teams using other methodologies, if necessary, to apply the advantages of the Agile approach.