Agile: the biggest ideological issue in IT

In 2001, a group of technologists and programmers who shared non-trivial theories about how to manage software development, met at the Snowbird ski resort to spell out some of these concepts in writing. This is how the Agile Manifesto was born - a deceptively simple document designed to revise software development dogmas. Software development in the style of Agile has become a new standard for the organization of the work of programmers in the organization. Companies such as Facebook , Amazon , Apple , Google and Netflix have built their internal development processes in accordance with the basic provisions of this manifesto. Given the absolute scale of Agile and its public resonance among supporters, it is easy to see that Agile is the most influential of all formalized software development. However, Agile is an ideology. Regulatory system of values ​​and beliefs, almost completely absorbed into the business of software development. Thus, the software industry today provides an interesting opportunity to assess how the nominal goals of some ideology are consistent with its implementation in practice.

In essence, Agile was a riot against corporate dominance in software development. For the first time, it was recognized that software development is a complex and often mysterious process that must be protected from corporate bureaucracy. Changes, reinvention, flexibility, dynamism - these are the red threads passing through the Agile manifest. They proved to be infinitely attractive: according to one global study , about 97% of all organizations in one form or another practice the principles of Agile. Thanks to such ubiquitous distribution, Agile achieved total nominalization in the theory of software development management: today the term "agile" refers to the ideology, working methods and even the systems used for software development in a modern organization. Agile even extends beyond programming teams and is increasingly practiced in other teams that are responsible, for example, for finances or human resource management. Agile, interpreted as a universal management theory, turned out to be extremely accessible and popular - despite the scarcity of empirical evidence of its effectiveness and usefulness.

Interestingly, the Agile manifest does not attempt to articulate any specific working methods, rules, processes, systems, or structures that would help develop Agile-style software. This is not surprising: after all, the Agile manifesto has never claimed a detailed description of how to achieve the goals of this manifesto. Such a clear blur did not diminish Agile's popularity: in fact, the rapid growth in demand for specific Agile methods and tools led to the emergence of a meta-industry based on Agile resources. This interest has stimulated the introduction of Agile, the penetration of the ideology of Agile and its derivatives into new industries. The most clearly defined are Agile's carefully defined methodologies (for example, Scrum and Kanban — that is, detailed descriptions of the processes that must be followed to embody the principles of the Agile manifest) and specialized software platforms specifically designed to support Agile development. Australian technology company Atlassian sells a range of such products designed to support Agile-style software development processes; Special mention should be made of Confluence and Jira, which have already become de facto standards in the industry. For those who are not brewed in the technology community, such products seem very mysterious. A number of explanatory articles appeared before Atlassian got on the NASDAQ lists and immediately after that. The articles were intended to explain exactly what Atlassian sells, and why the company achieved such high market capitalization.
')
Like the Atlassian software, the vocabulary of Agile processes and everyday work techniques have also become increasingly impenetrable to the uninitiated. Agile practitioners talk about sprints, Kanban boards, task combustion diagrams, speeds, user stories, epics, and retrospectives — all of these words often vary depending on the context, and these terms can be affiliated with one or more of the clearly defined Agile methodologies. Is it any wonder that, as the Agile methodology becomes more complex, the cohort of specialist consultants who help comprehend all this is multiplying. At Bain & Company, around 1,000 Agile practitioners are available to clients. This is probably the most reliable indicator showing how profitable the Agile-consulting industry has become. However, if the Agile manifesto is as simple as it seems at first glance, then why are there so many consultants? How significantly does the service of any of them affect the quality and efficiency of work in a typical technology company?

Despite the vocabulary, specialized tools, and a colossal corpus of resources available to anyone who wants to practice software development in their company in the style of Agile, it is often difficult to track how accurately Agile is implemented in practice - that is, it corresponds to the letter and spirit of the authors. Agile. The Agile Manifesto is intentionally and inevitably made abstract. Probably, this led to a gradual distortion of the methodology of Agile and, as a result, the whole culture of management in the software industry as such. On a seemingly simple basis, something colossal was built - a mechanism that extremely disappointed those who laid the foundation for its first iteration. Moreover, due to the long popularity of Agile, specialists who do not have formal Agile qualifications began to lose the competition to their colleagues, who allegedly professionally understand Agile. Many career bonuses are waiting for those who claim to understand the Agilr device and know how to use it. Such a reality stimulates conformism and drowns any attempts to doubt the dominance of Agile or to raise the question of its effectiveness.

Andy Hunt, one of the founding authors of the Agile Manifesto, complains that, because of the abstract wording of the original Manifesto, endless rules have appeared and spread that are used out of context and supposedly form the basis of Agile development. Over time, such rules are codified in the form of specialized methodologies that need to be thoughtlessly followed, while forgetting about the original guidelines of the Manifesto. In other words, the ideology of Agile turned out to be extremely difficult to learn, learn and practice. Therefore, some characters rely on rigidly defined rules or heuristics, which are issued as Agile, and then continue to replace these rules (often taken out of context) with the practice of Agile, which corresponds to the goals of the Manifesto. In most organizations, there is no gradual refinement of the development process; instead, managers fall astray, believing that the process does not allow changes, refuse to step-by-step product improvements, and seek to tear off three skins from developers, operating with mostly canons taken from the ceiling and rigidly fixed. Organizations that fail to extract any real value from Agile (and there are many) regularly trace to the implementation of a certain Agile process, while ignoring the more vague, but at the same time more important process results - that is, the delivery of workable software.

The heyday of Scrum and Kanban is, at best, an attempt to formalize and spread the ideology of Agile. In the worst case, all these methodologies are nothing more than an additional bureaucracy, generating all the new unsubstantiated rules and metrics that developers must follow. All this is imposed for reasons that are often completely unsupported empirically. Mediocre managers, consultants, developers, and even entire organizations in such conditions prosper: it becomes easier to dwell on the nominal rules of ideology, and gradually it turns out to be more important than achieving real goals. In principle, in the software development industry, there is a mania with the measurement of “contribution” and “return” from Agile at the level of individual employees. Such a mania led to disregard of Agile's initial ethics, a shift in priorities to collecting statistics for each individual employee, while in fact you need to gradually improve processes at the level of the entire organization.

The greatest irony of this degeneration is that the original Agile philosophy was designed to free the average programmer from the tyranny of micromanagement and unnecessary bureaucratic oversight. Instead, the very essence of this ideology in its current form is already hardly recognizable to those who created it. More generally, the fate of Agile as a software methodology is a bitter example of how the laconic and abstract ideology is gradually twisted and distorted as its influence grows, and new attempts are being made to put it into practice.