6 Ways to kill Agile
Initially, I was going to write an article on how to properly and effectively organize the development process using Agile methodologies. However, after sitting for a while over the editor’s empty window, I realized that I myself did not know how to do it. And not because it is impossible. Each project is unique and you can not create a common recipe that will work everywhere and always. At the same time, in the process of thinking about the article, I remembered a few typical mistakes in introducing flexible technologies, which, if not destroyed, are guaranteed to spoil the result. Therefore, acting according to the principle of the reverse, I decided to write about them.
Before you begin, it is worth recalling what Agile is. In its pure form, Agile is a development methodology based on Agile Manifesto principles. In short, the gist of these principles is to focus on results through effective communication, the lack of unnecessary, high flexibility and constant readiness for change (for more information, see Wikipedia ). Agile itself is not implemented in its pure form, for this purpose such practical methodologies as XP , Scrum , Lean and others are used, which are built on the basis of Agile principles and explain how to implement them. This article will look at Agile as a whole, without a bias towards a concrete implementation.
Well, now, in fact, you can move on to considering how to “kill” Agile.
')
Suppose a certain manager has read a lot of Agile literature and is now eager to put this knowledge into practice. His spirited speech might look something like this:
From today, we start working 100% on Agile. We will have daily, appraisal, interim, final, retrospective, weekly and monthly mandatory meetings. Each task must be in one of the 46 approved statuses that take into account all possible options, including finding a developer for a smoke break, at lunch or in the toilet - do not forget, by the way, to change her status when you are going to one of these places . In addition, I read that some guys offered a prayer to Alan Turing every day and everything was good for them - so we will do that too.
But not everything is so simple. Each Agile-method has its own specific area of ​​application and it is not at all the fact that it will be in demand in a specific team on a specific project. Accepting a new technique, it is important to see its not formal, but practical side: what is its purpose, how does it work and what effects does it have. In addition, we should not forget about the constant analysis: does it still work, does it require any changes, how can its positive effects be strengthened and the negative effects removed?
But such thoughts are people who have decided to work on Agile. At the beginning:
Well, everything, we have Agile and now we will live!
In a month:
We still have to wait, now for sure everything will go.
After two months:
To hell with this Agile! Tried it - nothing works! This is all the consultants have come up with to row the money.
Any methodology implemented by people. You should not expect Agile to work, just because you decided to use it. Even the support of Agile requires some effort, not to mention the implementation. Each member of the team, and especially the managers, should be actively involved in the preparation and organization of development processes. In addition, Agile does not provide the final point of development - the process of introspection and improvement can go on forever.
Typical situation. We have a cool and experienced programmer Peter. He has no time to play these newfangled things - he writes a severe code. And he doesn’t like to communicate with colleagues either - anyway, they will not understand the whole genius of his harsh code. Therefore, Petya is not touched, even if he continues to work on his own, especially since he comes to work at night and is rarely seen. Petya is an experienced programmer, he knows what to do and how to do it.
However, Agile is a team game. And when one player plays by the rules, it affects the result of the whole team. As a result, the seemingly high individuality of the lone programmer’s effectiveness can be completely offset by the negative effect it has on the entire team.
Sometimes you can hear something like this from executives:
So, guys, the customer now requires an urgent release from us, so we drop all the methodologies and start hard coding. Well, and then, as it becomes quieter, we will continue again.
And then it does not become calmer. First, you have to urgently repair what was broken by the urgent release, then what was broken by urgent repair, then there is a fix, etc.
It is wrong to think that Agile is a methodology for a quiet development period, when there is a lot of time for all sorts of optional activities (although, of course, it is better to implement it during such a period). On the contrary, the main purpose of Agile is to make development controlled and effective at any time, which is especially important in difficult periods. And by abandoning flexible methodologies at the end of development, you can easily destroy all the effects obtained from them earlier.
Once I heard about such a thing as pair programming, and after a while I had the opportunity to try it in practice. After several days of working in pairs, I was frankly disappointed. The work went slowly, my partner and I constantly argued over trifles, even before formatting the code, and eventually made compromise decisions that none of the two of us liked. There was an unpleasant aftertaste from work as a couple, and one day, by a mutual tacit decision, we returned to work one by one. After some time, we again tried to work in a pair, then again returned to independent work, and then again to pair programming ... And suddenly, at some point, I realized that I like working in pairs much more than alone! My partner and I were able to adjust to each other, we understood and accepted certain rules of behavior in a pair, after all, we just got used to the foreign programming style. As a result, the work has become much more efficient, and the results obtained in a pair, brought more pleasure than individual achievements.
Virtually any new methodology does not begin to work immediately at full power. Rather, the opposite is true - usually there is always a certain period of habituation and run-in, when the efficiency of work decreases (sometimes significantly!) In comparison with the previous methods. And only those who were able to overcome this period, were not afraid and did not stop in the middle of the path, will eventually get the desired effect.
Well, everything seems to be working out, the process is verified to the smallest detail, the releases are stable, the customer is happy. Seems to find the ideal Agile working formula? Now it can always be used!
Then new people come to the team, the goals and objectives of the project change ... the phase of the moon changes, finally. And the ideal formula stops working and even begins to interfere. Unfortunately, there is no single ideal recipe for Agile. Each of them can only be good in one particular setting and harmful in all others. Moreover, willingness to change and continuous self-improvement are among the core principles of Agile. Maybe it is even good - a predictable and linear world would be quite dull.
Of course, not all possible ways are described here, but only those that I have met and which seemed typical to me. I think there are still many options for how not to implement Agile or significantly reduce efficiency. If you know more typical or interesting ways, please write about them in the comments.
What is Agile
Before you begin, it is worth recalling what Agile is. In its pure form, Agile is a development methodology based on Agile Manifesto principles. In short, the gist of these principles is to focus on results through effective communication, the lack of unnecessary, high flexibility and constant readiness for change (for more information, see Wikipedia ). Agile itself is not implemented in its pure form, for this purpose such practical methodologies as XP , Scrum , Lean and others are used, which are built on the basis of Agile principles and explain how to implement them. This article will look at Agile as a whole, without a bias towards a concrete implementation.
Well, now, in fact, you can move on to considering how to “kill” Agile.
')
Turn into a formality
Suppose a certain manager has read a lot of Agile literature and is now eager to put this knowledge into practice. His spirited speech might look something like this:
From today, we start working 100% on Agile. We will have daily, appraisal, interim, final, retrospective, weekly and monthly mandatory meetings. Each task must be in one of the 46 approved statuses that take into account all possible options, including finding a developer for a smoke break, at lunch or in the toilet - do not forget, by the way, to change her status when you are going to one of these places . In addition, I read that some guys offered a prayer to Alan Turing every day and everything was good for them - so we will do that too.
But not everything is so simple. Each Agile-method has its own specific area of ​​application and it is not at all the fact that it will be in demand in a specific team on a specific project. Accepting a new technique, it is important to see its not formal, but practical side: what is its purpose, how does it work and what effects does it have. In addition, we should not forget about the constant analysis: does it still work, does it require any changes, how can its positive effects be strengthened and the negative effects removed?
Hope everything goes
But such thoughts are people who have decided to work on Agile. At the beginning:
Well, everything, we have Agile and now we will live!
In a month:
We still have to wait, now for sure everything will go.
After two months:
To hell with this Agile! Tried it - nothing works! This is all the consultants have come up with to row the money.
Any methodology implemented by people. You should not expect Agile to work, just because you decided to use it. Even the support of Agile requires some effort, not to mention the implementation. Each member of the team, and especially the managers, should be actively involved in the preparation and organization of development processes. In addition, Agile does not provide the final point of development - the process of introspection and improvement can go on forever.
Incomplete team involvement in the process
Typical situation. We have a cool and experienced programmer Peter. He has no time to play these newfangled things - he writes a severe code. And he doesn’t like to communicate with colleagues either - anyway, they will not understand the whole genius of his harsh code. Therefore, Petya is not touched, even if he continues to work on his own, especially since he comes to work at night and is rarely seen. Petya is an experienced programmer, he knows what to do and how to do it.
However, Agile is a team game. And when one player plays by the rules, it affects the result of the whole team. As a result, the seemingly high individuality of the lone programmer’s effectiveness can be completely offset by the negative effect it has on the entire team.
Selective application
Sometimes you can hear something like this from executives:
So, guys, the customer now requires an urgent release from us, so we drop all the methodologies and start hard coding. Well, and then, as it becomes quieter, we will continue again.
And then it does not become calmer. First, you have to urgently repair what was broken by the urgent release, then what was broken by urgent repair, then there is a fix, etc.
It is wrong to think that Agile is a methodology for a quiet development period, when there is a lot of time for all sorts of optional activities (although, of course, it is better to implement it during such a period). On the contrary, the main purpose of Agile is to make development controlled and effective at any time, which is especially important in difficult periods. And by abandoning flexible methodologies at the end of development, you can easily destroy all the effects obtained from them earlier.
Expect instant results
Once I heard about such a thing as pair programming, and after a while I had the opportunity to try it in practice. After several days of working in pairs, I was frankly disappointed. The work went slowly, my partner and I constantly argued over trifles, even before formatting the code, and eventually made compromise decisions that none of the two of us liked. There was an unpleasant aftertaste from work as a couple, and one day, by a mutual tacit decision, we returned to work one by one. After some time, we again tried to work in a pair, then again returned to independent work, and then again to pair programming ... And suddenly, at some point, I realized that I like working in pairs much more than alone! My partner and I were able to adjust to each other, we understood and accepted certain rules of behavior in a pair, after all, we just got used to the foreign programming style. As a result, the work has become much more efficient, and the results obtained in a pair, brought more pleasure than individual achievements.
Virtually any new methodology does not begin to work immediately at full power. Rather, the opposite is true - usually there is always a certain period of habituation and run-in, when the efficiency of work decreases (sometimes significantly!) In comparison with the previous methods. And only those who were able to overcome this period, were not afraid and did not stop in the middle of the path, will eventually get the desired effect.
Do not change
Well, everything seems to be working out, the process is verified to the smallest detail, the releases are stable, the customer is happy. Seems to find the ideal Agile working formula? Now it can always be used!
Then new people come to the team, the goals and objectives of the project change ... the phase of the moon changes, finally. And the ideal formula stops working and even begins to interfere. Unfortunately, there is no single ideal recipe for Agile. Each of them can only be good in one particular setting and harmful in all others. Moreover, willingness to change and continuous self-improvement are among the core principles of Agile. Maybe it is even good - a predictable and linear world would be quite dull.
Conclusion
Of course, not all possible ways are described here, but only those that I have met and which seemed typical to me. I think there are still many options for how not to implement Agile or significantly reduce efficiency. If you know more typical or interesting ways, please write about them in the comments.
Source: https://habr.com/ru/post/162851/
All Articles