Comprehensive methods/methodologies ​

We have already mentioned that one of the standards of situational engineering methods (ISO 24744) emphasized the synonymity of method and methodology for naming practices. The term "methodology" has meanings of: 1. a separate method/practice, 2. a method as a set of practices to achieve some significant results "on a turnkey basis", and 3. a "general theory/discipline that studies activities/practices/work methods/labor"). However, the reverse is incorrect, a discipline is called a methodology, but not a method. The method is what methodology studies. But given the synonymity, it can also be said that "methodology studies methodology" (that is, "methodology studies method/practice/activity"). Let's repeat, the same applies to geometry ("geometry studies geometries, for example, Riemannian geometry") and logic ("logic studies logics, for example, modal logic"). So, from the context, it should be clear whether methodology is meant as a general theory of activity or just a practice called methodology.

Popular comprehensive development methods/methodologies, i.e. various agile methodology options (for example, DSDM, SCRUM, SAFe, etc.)^[1], also known as "agile development methodologies" (but there is more than one, there are many variations), quality assurance (for example, six sigma^[2]), enterprise architecture work (TOGAF^[3]), and even social dance methodologies^[4] all turn out to be coherent sets of meticulously detailed practices for creating and developing systems or certain system properties (like quality assurance methodologies), or as previously mentioned, life cycle practices, except not all stages from conception to decommissioning, but only one (most often design, less frequently design and manufacturing, and increasingly practices of operation—combined, it becomes "development," but visionary, architectural, production platform engineering practices are excluded from here, as there are no full methods for them, they are assembled from individual practices "as needed").

Such "comprehensive/heavyweight methodologies" are today in a disappearing class in real work, although the activity of selling certificates for knowledge of such methodologies is still thriving. A "certified professional/specialist" in systems engineering, project management, etc., is precisely the one who passed an exam to confirm that he "knows the methodology". It is not necessary that this specialist can actually work according to this method to achieve the planned method results, but he has learned the bulky volume of the "methodology" and can answer questions about the text. Such "methodologies" often contain three parts:

• An overall discipline description for the many components of the practice methodology. This discipline introduces the alphas of the methodology, and individual practices within the methodology can then work with the sub-alphas of these alphas. For example, agile practices introduce the alpha backlog as a "to-do list" for implementation. Practices of the TRIZ methodology use the concept of the "ideal final result", social dances work with the concept of "connection".
• A multitude of individual practices as instructions on "what and how to do" in each specific case: "if you encounter X, then do Y". There are usually many different practices, they can introduce their sub-alphas, but they are generally dedicated to translating alphas from one state to another.
• Indications on how to combine practices with work in the process of creating systems/life cycle, that is, setting forth the preferred concept/type/model of the life cycle, or the concept of creating and developing a system. Sometimes even the term "development methodology" is specifically used to refer to this aspect (replacing the term "software development methodology" with the term "life cycle model" when referring to agile development methodologies, in which they move away from discussing a single life cycle to a "continuous whole" with potentially endless system development).

The current trend is the disassembly of the few remaining large/heavyweight methodologies into individual small practices (a countercultural trend of anti-perfectionism/lean/elegance/minimum action. We must remember that today's counterculture is often tomorrow's culture, it's just that at the moment of cultural change, the new is perceived as a denial of the old). The few remaining—it's because most of these exhaustive methodologies (sometimes referred to as "monstrous", impossible to fully implement, inherently utopian, and redundant) have already been rejected, i.e., they are not being attempted to be implemented in some enterprises. Such methodologies are used only for purchasing various certificates, to participate in competitions (whether a company participates or an individual—the principle is the same), and to attach a certificate to competitive documentation to increase chances, claiming "I know a complex method, I read the books".

If ten years ago it was considered necessary to use all the components of a methodology in work, described by some methodology, and that without any of the practices described in a heavyweight method, the result would be poor, "imperfect," unfinished, today this is no longer the case, and such an approach is heavily criticized.

For development methodologies, Ivar Jacobson (one of the leading co-authors of the standard for describing methods/processes for creating and developing systems OMG Essence) calls to "free practices from methodologies", as they are excellent units of experience accumulation—his presentation at SECR'17 is titled "Kill All Methods—Free the Practices"^[5]. There is no method as a complete set of practices to achieve a result "on a turnkey basis", we work with culturally conditioned individual practices that we choose not from methodologies, but directly from the culture. And if this practice turns out to be too large (like a method!), then it is broken down into sub-practices and it—and always only a small part of known practices are used, rather than working with meticulously detailed hundreds of practices from some heavyweight all-encompassing methodology.

The shift from heavyweight methodologies (documented hundreds of pages and requiring strict compliance with all the requirements of these hundreds of pages at once) to lightweight methodologies (described in short documents, emphasizing very compact sets of principles, without lengthy instructions on what and when to do and without mandatory consideration of all these principles as an indivisible whole) reflects the modern culture of anti-perfectionism, the desire to get rid of unnecessary work in favor of only the minimal necessary work. This is a very serious cultural change, which has taken place over the last twenty years. In 2000, lightweight methodologies, where practices are broken down almost into individual independently applicable principles of their disciplines, looked very unserious, and people used to laugh at them. Today, on the contrary: it turns out that this is serious, while heavyweight methodologies are no longer even considered. Statements like "your SCRUM practice is bad because you did not meet all the requirements of a 600-page document describing it" were good in 2000, but today they evoke a smile. However, adherence to a few principles is monitored much more strictly than compliance with the universally unworkable hundreds of pages of heavyweight methodologies, and today it is clear that there is more order in following lightweight methodologies compared to following hopelessly unworkable formations of hundreds of pages in heavyweight methodologies.

The disassembly of large methodologies into individual practices is also happening in dance methodologies, there is a universal transition to fusion dance^[6] as an alloy of practices from different dance styles, defined by different methodologies of these styles. For example, in social dances, it can be a mix or fusion of practices of dance styles like tango, kizomba, forro, salsa. We understand that practice in the stack of dance practices is supported not only by the discipline/theory/canon of a dance style but also by the instrumentarium in the form of body and sounding music. Let's remember the stack of dance practices (it was discussed in more detail in the systems thinking course)^[7]:

Combining practices of different styles of dancing requires additional body development to perform movements of multiple styles. Often, the music must also be adjusted to include the musical accents of two rhythms. If you want to mix practices from the hip-hop methodology and the kizomba methodology, and you have mastered dancing only one style, you will have to develop your body further and select suitable tracks. But it is possible! The approach with heavyweight practices almost precluded such mixes—multidisciplinary work was extremely difficult—in dancing, engineering, and management. This was contemptuously called "eclecticism." But it turns out that this is the secret to obtaining new methods, it is the manifestation of evolution, the path to development.

One should think about such a blend roughly the same way as about preparing food: when you mix different products, you get emergent properties in the result—borscht in taste is not equal to the sum of the tastes of the products in it, and vinaigrette in taste differs from the tastes of the products in it. And such a result is remembered, replicated if it turns out successful (however, buckwheat with chocolate does not replicate, the taste is not very good).

The same goes for practices: it turns out that if you mix individual practices, very elegant and well-functioning methods can be obtained, while individual heavyweight methods are not easily mixable (you can make borscht and vinaigrette from beets, but borscht with vinaigrette—it doesn't turn out so well to mix—though this is just a metaphor, it conveys the main message of isolating important individual practices, from which various methods will later be composed, understanding what are the original products from which everything else can ultimately be prepared, if the need arises).

In real projects of creating various types of systems, in combining practices taken from different methodologies, not only do people need to be trained in necessary parts of the disciplines of these methodologies, but also the tools must be enhanced to support different disciplines simultaneously (for example, modern issue trackers support both the construction of Gantt charts at the highest level: case management and project management practices are mixed—directive graphics are taken from project management, and the real work in its fine granularity is done in the order of case management).

The methodologies themselves do not necessarily limit themselves to practices taken from some specific sphere of human activity. For example, agile methodologies emerged as a fusion of classical engineering (mainly software engineering) and managerial practices, although over the last decade, there are almost no engineering practices left for creating the target system, only engineering and team development practices—they are more managerial^[8]. On the contrary, project management methodologies began with operational management, but now more and more attention is being paid to the system engineering of the target system (in recent years, even partial practices of requirements engineering have appeared in them, although these descriptions are completely insufficient for full engineering work, and moreover, requirements development is already outdated as a practice—systems engineering has changed in the last five years, but project managers have not kept up with this).

A fundamental discipline (transdiscipline) of the methodology allows thinking similarly about structuring projects from practices of creating various systems (material, cyber-physical systems, entities, personalities, organizations, communities, societies). Moreover, of course, fundamental disciplines of the intellect stack are used. Considering that the development of agents/IPUs/creators is the mastery of carrying out new practices, then methodology as a discipline along with other disciplines of the intellect stack allows discussing organizational development: discussing the execution of new practices by creators (people, groups of people with their computers) and also consciously refraining from executing certain old practices.