New agile software development methodology - AIM
As before, the cross post from my main blog.
-
<P mce_keep = “true”> AIM is a good word, but this is not the only thing in this new agile software development methodology. An interesting detail of it is that this is not a notion created in an academic environment, but the result of observation of real successful projects for more than two decades. In some mystical way, all successful managers of software products, with rare exceptions, in one way or another always repeated the same steps, and all unsuccessful managers usually skipped some of these steps. Now this powerful and well-working technique is presented to your attention.
')
<P mce_keep = "true"> AIM stands for Agile Insanity Management. Actually, it should be called Agile Management by Insanity, but marketing found that such a name is unlikely to find support in a corporate environment, besides the abbreviation AIM sounds much better than AMI or AMbI. From where such a kind of name will become clear a little later.
<P mce_keep = "true"> So, AIM. The first step always consists of the same thing - you create a cohesive, motivated team in which everyone does their job. This usually happens at a time when the success of a project is far from obvious and the product is nothing interesting for corporate parasites. The team, united in the name of a great goal, works day and night and creates a base - a product, even with many deficiencies, but something that works, that can be shown to people, that has a face, shape and functionality. And even more.
<P mce_keep = "true"> In this phase, the team is one, all its parts - management, project management, development and test work together for the common goal - product creation. Information flows freely from top to bottom and bottom to top. Virgos and testers know what the management wants from the product, management is aware of all the problems that virgins and testers are experiencing, and pi-ems throw themselves in the chest and close the gaps that someone must still make.
<P mce_keep = "true"> This is the phase on which the DeMarco material works. This is the phase at which the product is actually created, because in the next phase it will be harder and harder to create something ...
<P mce_keep = "true"> After a while it becomes clear that the project will probably work out. In this phase, the team usually expands somewhat, and along with the helpful team members, it also gains a certain number of corporate parasites that are more or less evenly scattered around the team.
Fortunately, at this phase it is not a bad thing, since there are few parasites and, due to their dispersion on the team, there are few of parasites, not cumulatively. Of course, they already interfere, but not much. No more than a fool or even just an inexperienced team member.
But at some point, time begins to tighten, and then the changes begin, which will have to be outlined in a very, very detailed manner, since it is they who are critical. So, when time begins to tighten, there are opposing forces acting on the project. On the one hand, management, who are responsible for the project head, tend to release the product on time, or at least with some reasonable delay, but no more. And they are easy to understand.
On the other hand, developers and testers see terrifying and gaping holes in the product, and often, due to the nature of their position relative to the product, tend to exaggerate their size. But even without exaggeration, any product always has some serious problems. Thus, the “lower floors” of the team are pulling the products “down”, in the direction of delaying the schedule, and for objective real reasons.
Result? As in the mechanical system under the influence of two forces acting on it to break, somewhere in the middle of the team, a stress line appears.
This line is not as smooth as in the picture and not strictly horizontal, but it is. And like any tension line, it attracts the attention of management. And here a very important change in the team takes place - by itself. The fact is that, by its very nature, corporate parasites are burdened by areas that attract the attention of management. What does this mean in this situation? Right! Corporate parasites are pulled from the whole team to the line of tension in the team, because it is to her that the attention of management is riveted.
As a result, the corporate parasites of the team line up along the line of tension in the team, torn into two parts by the hopes of management and the realities observed by people “below”.
<P mce_keep = "true">
<P mce_keep = "true"> Now, imagine two pieces of connected together and torn in different directions with an increasing force? Consider, corporate parasites are not glue, they are grease. Even if they were not enough to completely isolate the two parts of the team from each other, they still work as a kind of perforation on toilet paper. And the tearing force and tension keeps growing - the release date of the product is approaching, and the disgraces in it ... well. not that it did not diminish, but not at the pace that is needed to release it on time.
<P mce_keep = "true"> Result? Quite predictable. Team breaking into two parts - management and the actual team creating the product.
At the same time, corporate parasites, lined up "in two rows" turn into a kind of two "reflective layer." Flows of real information from below are reflected down the parasites and are not passed into the management. The reason is simple - who wants to report unpleasant news to the authorities? And if some of the members of the team below are too persistent, they can be discredited in the eyes of their superiors, so that they simply do not trust them.
But just isolation from the team would not work, since even a very stupid manager may notice a complete lack of information. Instead, the reflective layer “stuck” to management reflects the expectations and hopes of management in the form of fake information flows, data that reflect management's expectations, and not reality. Of course, they usually do not come up with empty air, but are partially based on flows coming from the bottom, but after severe filtering, sometimes in several layers, and with a serious change of emphasis. And often it is frankly “silenced” by fictitious, so-called “process” problems.
In essence, management begins to live in a kind of virtual reality, where the role of receptors and sources of information about reality is performed by corporate parasites of the reflective layer, who are vitally interested in management hearing what they want, and in which the role of people who actually develop and test the product is gradually reduced, if not completely to zero, then to something like that.
It is in this virtual reality that decisions are usually made to release the product and make it successful. The decision itself about the readiness of a product ultimately turns out to be the result of some grand-illusion, a kind of corporate hallucination induced by corporate parasites and a gap in information flows.
Result? Alas, again predictable:
Is it possible to do something with this gap? Bottom - not. That is, it is temporarily possible, but by sacrificing your career. And when you "understand", everything will go again on the grooved track with a slight delay. And on top ... why would you want to prevent it from above? If you are not from the breed of “iron felixes” and “iron ladies” who can shrug their shoulders and release a product with glaring holes ... how else can you create an illusion around yourself that will give you the courage to press the “Release” button?
People are weak.
The chiefs are surprisingly weak.
I suspect that there is some kind of unnatural corporate selection, which allows only those to become the boss, who is weak, who is like clay in the hands of this inhuman disgusting system, who allows to do with himself what a person, a real person, according to Gorky, with a capital letter , never allow to do with yourself. However, it brought me ...
The truth is simple as always. You are the boss. You answer. You are scared. Someone must take the pain relief. Someone must create an illusion for you when you no longer distinguish reality from collective hallucination. In this regard, the bottom guy who mutters about the problems in the products only hinders you. But the corporate parasite in a pressed suit and tie, which hangs you noodles on the ears in the spirit of "all is well, beautiful marquise ..." - this is what you need.
The main idea here is that between the general readiness of the product, the readiness of the product in the head of the chief and the "ideal" readiness of the product there are peculiar "chasms". The second — to the “ideal” product — is simply impossible to cross. Well, there are no products that would make it. Take even not Windows, but Mac OS X or any Linux - no one could cross this second abyss. But the first is completely surmountable. The result is that product release at some point is necessarily carried out for reasons unrelated to the quality of the product or its real readiness, but only for reasons in virtual reality created for the management of corporate parasites. And ultimately it is the result of some grand illusion.
Actually, I suspect that AIM works not only in the development of software, but also in general in the management of anything. As well as the fact that it was invented by no means me, but decades, if not centuries ago. Do not believe? Take a look at this picture here. Looks familiar?
<P mce_keep = "true"> Oh, the last detail. Those readers who are very boring may ask: “So is this a true agile software development technique, or is it you who teased the corporate culture?” Do you know? I myself am not completely sure. No, honestly. It looks like a jokes, but I personally watched AIM successfully operating for more than twenty years in various companies and even in different countries. No, really. Works!
-
<P mce_keep = “true”> AIM is a good word, but this is not the only thing in this new agile software development methodology. An interesting detail of it is that this is not a notion created in an academic environment, but the result of observation of real successful projects for more than two decades. In some mystical way, all successful managers of software products, with rare exceptions, in one way or another always repeated the same steps, and all unsuccessful managers usually skipped some of these steps. Now this powerful and well-working technique is presented to your attention.
')
<P mce_keep = "true"> AIM stands for Agile Insanity Management. Actually, it should be called Agile Management by Insanity, but marketing found that such a name is unlikely to find support in a corporate environment, besides the abbreviation AIM sounds much better than AMI or AMbI. From where such a kind of name will become clear a little later.
<P mce_keep = "true"> So, AIM. The first step always consists of the same thing - you create a cohesive, motivated team in which everyone does their job. This usually happens at a time when the success of a project is far from obvious and the product is nothing interesting for corporate parasites. The team, united in the name of a great goal, works day and night and creates a base - a product, even with many deficiencies, but something that works, that can be shown to people, that has a face, shape and functionality. And even more.
<P mce_keep = "true"> In this phase, the team is one, all its parts - management, project management, development and test work together for the common goal - product creation. Information flows freely from top to bottom and bottom to top. Virgos and testers know what the management wants from the product, management is aware of all the problems that virgins and testers are experiencing, and pi-ems throw themselves in the chest and close the gaps that someone must still make.
<P mce_keep = "true"> This is the phase on which the DeMarco material works. This is the phase at which the product is actually created, because in the next phase it will be harder and harder to create something ...
<P mce_keep = "true"> After a while it becomes clear that the project will probably work out. In this phase, the team usually expands somewhat, and along with the helpful team members, it also gains a certain number of corporate parasites that are more or less evenly scattered around the team.
Fortunately, at this phase it is not a bad thing, since there are few parasites and, due to their dispersion on the team, there are few of parasites, not cumulatively. Of course, they already interfere, but not much. No more than a fool or even just an inexperienced team member.
But at some point, time begins to tighten, and then the changes begin, which will have to be outlined in a very, very detailed manner, since it is they who are critical. So, when time begins to tighten, there are opposing forces acting on the project. On the one hand, management, who are responsible for the project head, tend to release the product on time, or at least with some reasonable delay, but no more. And they are easy to understand.
On the other hand, developers and testers see terrifying and gaping holes in the product, and often, due to the nature of their position relative to the product, tend to exaggerate their size. But even without exaggeration, any product always has some serious problems. Thus, the “lower floors” of the team are pulling the products “down”, in the direction of delaying the schedule, and for objective real reasons.
Result? As in the mechanical system under the influence of two forces acting on it to break, somewhere in the middle of the team, a stress line appears.
This line is not as smooth as in the picture and not strictly horizontal, but it is. And like any tension line, it attracts the attention of management. And here a very important change in the team takes place - by itself. The fact is that, by its very nature, corporate parasites are burdened by areas that attract the attention of management. What does this mean in this situation? Right! Corporate parasites are pulled from the whole team to the line of tension in the team, because it is to her that the attention of management is riveted.
As a result, the corporate parasites of the team line up along the line of tension in the team, torn into two parts by the hopes of management and the realities observed by people “below”.
<P mce_keep = "true">
<P mce_keep = "true"> Now, imagine two pieces of connected together and torn in different directions with an increasing force? Consider, corporate parasites are not glue, they are grease. Even if they were not enough to completely isolate the two parts of the team from each other, they still work as a kind of perforation on toilet paper. And the tearing force and tension keeps growing - the release date of the product is approaching, and the disgraces in it ... well. not that it did not diminish, but not at the pace that is needed to release it on time.
<P mce_keep = "true"> Result? Quite predictable. Team breaking into two parts - management and the actual team creating the product.
At the same time, corporate parasites, lined up "in two rows" turn into a kind of two "reflective layer." Flows of real information from below are reflected down the parasites and are not passed into the management. The reason is simple - who wants to report unpleasant news to the authorities? And if some of the members of the team below are too persistent, they can be discredited in the eyes of their superiors, so that they simply do not trust them.
But just isolation from the team would not work, since even a very stupid manager may notice a complete lack of information. Instead, the reflective layer “stuck” to management reflects the expectations and hopes of management in the form of fake information flows, data that reflect management's expectations, and not reality. Of course, they usually do not come up with empty air, but are partially based on flows coming from the bottom, but after severe filtering, sometimes in several layers, and with a serious change of emphasis. And often it is frankly “silenced” by fictitious, so-called “process” problems.
In essence, management begins to live in a kind of virtual reality, where the role of receptors and sources of information about reality is performed by corporate parasites of the reflective layer, who are vitally interested in management hearing what they want, and in which the role of people who actually develop and test the product is gradually reduced, if not completely to zero, then to something like that.
It is in this virtual reality that decisions are usually made to release the product and make it successful. The decision itself about the readiness of a product ultimately turns out to be the result of some grand-illusion, a kind of corporate hallucination induced by corporate parasites and a gap in information flows.
Result? Alas, again predictable:
Is it possible to do something with this gap? Bottom - not. That is, it is temporarily possible, but by sacrificing your career. And when you "understand", everything will go again on the grooved track with a slight delay. And on top ... why would you want to prevent it from above? If you are not from the breed of “iron felixes” and “iron ladies” who can shrug their shoulders and release a product with glaring holes ... how else can you create an illusion around yourself that will give you the courage to press the “Release” button?
People are weak.
The chiefs are surprisingly weak.
I suspect that there is some kind of unnatural corporate selection, which allows only those to become the boss, who is weak, who is like clay in the hands of this inhuman disgusting system, who allows to do with himself what a person, a real person, according to Gorky, with a capital letter , never allow to do with yourself. However, it brought me ...
The truth is simple as always. You are the boss. You answer. You are scared. Someone must take the pain relief. Someone must create an illusion for you when you no longer distinguish reality from collective hallucination. In this regard, the bottom guy who mutters about the problems in the products only hinders you. But the corporate parasite in a pressed suit and tie, which hangs you noodles on the ears in the spirit of "all is well, beautiful marquise ..." - this is what you need.
The main idea here is that between the general readiness of the product, the readiness of the product in the head of the chief and the "ideal" readiness of the product there are peculiar "chasms". The second — to the “ideal” product — is simply impossible to cross. Well, there are no products that would make it. Take even not Windows, but Mac OS X or any Linux - no one could cross this second abyss. But the first is completely surmountable. The result is that product release at some point is necessarily carried out for reasons unrelated to the quality of the product or its real readiness, but only for reasons in virtual reality created for the management of corporate parasites. And ultimately it is the result of some grand illusion.
Actually, I suspect that AIM works not only in the development of software, but also in general in the management of anything. As well as the fact that it was invented by no means me, but decades, if not centuries ago. Do not believe? Take a look at this picture here. Looks familiar?
<P mce_keep = "true"> Oh, the last detail. Those readers who are very boring may ask: “So is this a true agile software development technique, or is it you who teased the corporate culture?” Do you know? I myself am not completely sure. No, honestly. It looks like a jokes, but I personally watched AIM successfully operating for more than twenty years in various companies and even in different countries. No, really. Works!
Source: https://habr.com/ru/post/15520/
All Articles