Twelve Mistakes in Agile Manifesto
- Transfer
Nowadays, the Agile Software Development Manifesto is the Bible for many development teams. It contains 12 principles that show us how software development should be organized. These principles were invented in 2001. In general, I like them and I agree with all of them. However, in fact, most teams misunderstand them. Consequently, I further summarize what is happening and my interpretation of each principle.
By focusing on “customer satisfaction,” Agile followers completely forget about the “thanks” part. They believe that their true goal is a happy customer , and “continuous delivery” is something that is obviously useful, but not essential. However, everything is quite the opposite: the customer will be satisfied if the software is perfectly created and delivered. If the customer is not satisfied, we are looking for another - this is the true spirit that the software development team must adhere to. I believe that the Manifesto means exactly that. We guarantee that our process is “early and continuous” and this will lead to customer satisfaction. We focus on improving our process, not on customer satisfaction. Satisfaction is a consequence, not a primary goal.
Most Agile teams understand the word “welcome” as permission to forget about any requirements management at all . What is the easiest way to welcome change? Obviously, just get rid of documenting the requirements! In this case, any change will be welcome, since it will not affect anything. It will simply have nothing to influence. But this is not what the Manifesto means! This principle means that our requirements management process is so powerful that it can be changed at any time. However, this is difficult to achieve if the requirements are indeed documented.
This stunning rule is usually understood as a mandatory requirement for the whole team. The team should make releases often, while programmers are free to release almost nothing and who knows when. I think that here the Manifesto emphasizes both individual and group responsibility for frequent releases. I also believe that this frequency should be much higher than “once every couple of weeks”. Today, with modern technologies and tools, we can produce software much faster - several times a day.
“Working together” does not mean “working without clearly defined rules and processes”. However, most teams understand this principle as the legalization of chaos. They believe that since we work together, we no longer need to define roles, we do not need to document requirements , we do not need to take care of responsibilities. In the end, we do not know who does what or the structure of the team. This is not what the Manifesto says! “Working together” means sharper communications and shorter response cycles. This certainly does not mean the absence of roles and responsibilities.
Trust is a wonderful word and concept, but it does not replace another equally important word - control. Most Agile teams believe that trust means just that - the complete absence of any validation, verification, responsibility and control. “We trust our programmers to write perfect code,” I have heard this countless times, and this is simply wrong. This principle means something completely different. It means that when clearly defined tasks are assigned to their performers, we fully transfer responsibility to them. We motivate them to take full responsibility for the final result. However, we do not help them . Instead, we trust them as self-sufficient individuals who are able to independently perform the tasks assigned.
“Direct communication” does not mean “sitting in one office”. The manifest says nothing about co-located or distributed teams. Obviously, in modern software projects, virtual communications (using video calls) are much more efficient than working together in one country, one city, one office, and one room. Therefore, most Agile adepts still promote this style of development, when everyone is in the same place, as evidence using the Manifesto. This is mistake; “Direct communication” means something completely different than 15 years ago when the Manifesto was written.
This does not mean that we no longer have to measure anything. Of course, a working product is the main metric, but there are many others that we can and should use. For example, the number of documented, implemented, and delivered functions; or the number of lines of code added to the project (do not smile - read ); or the number of errors found ; or the amount of money spent . There are many other metrics. Many of them we can use. However, the typical mistake that many Agile teams make is simply to ignore them all. They say: "We measure only the final result." However, this is not what the Manifesto proposes to do.
This does not mean that we have to endlessly burn the customer's money. Yes, we must develop at a certain speed, but we must always remember whose money we spend: customer money. The manifesto says nothing about the cost of development, and this is apparently due to the fact that it was written by those who make money (programmers), and not those who spend them (customers). Therefore, we must remember that any project is primarily a machine for burning money. That is why the team should always measure its “ burning speed ” and make sure that it matches the amount of business value that the team delivers. Just being a happy team is not what the Manifesto proposes, but that’s how many understand this principle.
This is an ideal principle that says so much at the same time and says nothing. What exactly does “attention” mean? I can explain. It means rules and policies . Any policy primarily means punishing those who break the rules. Thus, if an Agile team really means constant attention to technical excellence, it must have a quality policy . This policy should clearly define which design is good and which is bad, which piece of Java code is excellent, which is ugly, etc. In addition, the policy should indicate what happens to those who violateprinciples of excellence. However, most Agile teams understand “quality” as an excellent flag that can be hung on the wall, but they get scared when I ask: “What happens if someone delivers poor quality?”
This is a great rule that most Agile teams don't follow at all. This principle means that our tasks are small and simple enough to ensure their feasibility or cancellation. Huge tasks are the biggest threat to the manageability of any team, whether it is Agile or not. This principle encourages us to set small tasks for programmers that they can easily accomplish. However, most agile adepts equate simplicity with stupidity. This is not the same thing. “Simple task” does not mean “stupid” or “unimportant”. A simple task is a well-defined little executable instruction.
“Self-organizing” does not mean “unorganized”. This rule is often interpreted as the legalization of anarchy . We don't need any project managers, processes, discipline, rules, or policies — instead, we have a holacracy ! We don’t need an architect either - our programmers can make all technical decisions at regular meetings ! In addition, we do not want our programmers to be personally responsible for anything — they are always together for any risks and problems. Stop this madness! This is not what the Manifesto means. A self-organizing team is a team that does not need external supervision; a team with clearly defined roles inside; a team with perfect inner discipline; team with professional management. Not with the lack of it all.
This is a remarkable principle, which is embodied in the so-called "retrospectives". They work great, as long as decisions make the team better. Unfortunately, in most cases, programmers in Agile teams try to survive , rather than make the team more efficient. Although the principle says that a team should become more effective, these “retrospectives” help programmers to become more effective (read: safer) in a team. This is natural for people, but leads to a general degradation of the team. It is well known that the best team is the one that is able to quickly and inexorably rejectbad items. Does your team do this effectively? Do “retrospectives” help in this? I doubt it. Therefore, I believe that here the Manifesto does not mean meetings. He means that the team should have an effective mechanism of self-regulation and self-improvement. In addition, retrospective meetings simply cannot be such a mechanism, because they prevent the team from making difficult disciplinary decisions.
Principle No. 1: "The highest priority for us is to meet the needs of the customer through regular and early delivery of valuable software."
By focusing on “customer satisfaction,” Agile followers completely forget about the “thanks” part. They believe that their true goal is a happy customer , and “continuous delivery” is something that is obviously useful, but not essential. However, everything is quite the opposite: the customer will be satisfied if the software is perfectly created and delivered. If the customer is not satisfied, we are looking for another - this is the true spirit that the software development team must adhere to. I believe that the Manifesto means exactly that. We guarantee that our process is “early and continuous” and this will lead to customer satisfaction. We focus on improving our process, not on customer satisfaction. Satisfaction is a consequence, not a primary goal.
Principle No. 2: “Changing requirements is welcome even in the later stages of development. Agile processes allow changes to be used to provide customers with a competitive advantage. ”
Most Agile teams understand the word “welcome” as permission to forget about any requirements management at all . What is the easiest way to welcome change? Obviously, just get rid of documenting the requirements! In this case, any change will be welcome, since it will not affect anything. It will simply have nothing to influence. But this is not what the Manifesto means! This principle means that our requirements management process is so powerful that it can be changed at any time. However, this is difficult to achieve if the requirements are indeed documented.
Principle number 3: "A working product should be released as often as possible, with a frequency from a couple of weeks to a couple of months."
This stunning rule is usually understood as a mandatory requirement for the whole team. The team should make releases often, while programmers are free to release almost nothing and who knows when. I think that here the Manifesto emphasizes both individual and group responsibility for frequent releases. I also believe that this frequency should be much higher than “once every couple of weeks”. Today, with modern technologies and tools, we can produce software much faster - several times a day.
Principle number 4: "Throughout the project, developers and business representatives should work together every day."
“Working together” does not mean “working without clearly defined rules and processes”. However, most teams understand this principle as the legalization of chaos. They believe that since we work together, we no longer need to define roles, we do not need to document requirements , we do not need to take care of responsibilities. In the end, we do not know who does what or the structure of the team. This is not what the Manifesto says! “Working together” means sharper communications and shorter response cycles. This certainly does not mean the absence of roles and responsibilities.
Principle 5: “Motivated professionals should work on the project. To get the job done, create the conditions, provide support and trust them completely. ”
Trust is a wonderful word and concept, but it does not replace another equally important word - control. Most Agile teams believe that trust means just that - the complete absence of any validation, verification, responsibility and control. “We trust our programmers to write perfect code,” I have heard this countless times, and this is simply wrong. This principle means something completely different. It means that when clearly defined tasks are assigned to their performers, we fully transfer responsibility to them. We motivate them to take full responsibility for the final result. However, we do not help them . Instead, we trust them as self-sufficient individuals who are able to independently perform the tasks assigned.
Principle number 6: "Direct communication is the most practical and effective way to exchange information with the team itself, and within the team."
“Direct communication” does not mean “sitting in one office”. The manifest says nothing about co-located or distributed teams. Obviously, in modern software projects, virtual communications (using video calls) are much more efficient than working together in one country, one city, one office, and one room. Therefore, most Agile adepts still promote this style of development, when everyone is in the same place, as evidence using the Manifesto. This is mistake; “Direct communication” means something completely different than 15 years ago when the Manifesto was written.
Principle number 7: "Working product - the main indicator of progress."
This does not mean that we no longer have to measure anything. Of course, a working product is the main metric, but there are many others that we can and should use. For example, the number of documented, implemented, and delivered functions; or the number of lines of code added to the project (do not smile - read ); or the number of errors found ; or the amount of money spent . There are many other metrics. Many of them we can use. However, the typical mistake that many Agile teams make is simply to ignore them all. They say: "We measure only the final result." However, this is not what the Manifesto proposes to do.
Principle number 8: “Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps build such a sustainable development process. ”
This does not mean that we have to endlessly burn the customer's money. Yes, we must develop at a certain speed, but we must always remember whose money we spend: customer money. The manifesto says nothing about the cost of development, and this is apparently due to the fact that it was written by those who make money (programmers), and not those who spend them (customers). Therefore, we must remember that any project is primarily a machine for burning money. That is why the team should always measure its “ burning speed ” and make sure that it matches the amount of business value that the team delivers. Just being a happy team is not what the Manifesto proposes, but that’s how many understand this principle.
Principle No. 9: "Continuous attention to technical excellence and design quality increases project flexibility."
This is an ideal principle that says so much at the same time and says nothing. What exactly does “attention” mean? I can explain. It means rules and policies . Any policy primarily means punishing those who break the rules. Thus, if an Agile team really means constant attention to technical excellence, it must have a quality policy . This policy should clearly define which design is good and which is bad, which piece of Java code is excellent, which is ugly, etc. In addition, the policy should indicate what happens to those who violateprinciples of excellence. However, most Agile teams understand “quality” as an excellent flag that can be hung on the wall, but they get scared when I ask: “What happens if someone delivers poor quality?”
Principle number 10: "Simplicity - the art of minimizing unnecessary work - is essential."
This is a great rule that most Agile teams don't follow at all. This principle means that our tasks are small and simple enough to ensure their feasibility or cancellation. Huge tasks are the biggest threat to the manageability of any team, whether it is Agile or not. This principle encourages us to set small tasks for programmers that they can easily accomplish. However, most agile adepts equate simplicity with stupidity. This is not the same thing. “Simple task” does not mean “stupid” or “unimportant”. A simple task is a well-defined little executable instruction.
Principle number 11: "The best requirements, architectural and technical solutions are born from self-organizing teams."
“Self-organizing” does not mean “unorganized”. This rule is often interpreted as the legalization of anarchy . We don't need any project managers, processes, discipline, rules, or policies — instead, we have a holacracy ! We don’t need an architect either - our programmers can make all technical decisions at regular meetings ! In addition, we do not want our programmers to be personally responsible for anything — they are always together for any risks and problems. Stop this madness! This is not what the Manifesto means. A self-organizing team is a team that does not need external supervision; a team with clearly defined roles inside; a team with perfect inner discipline; team with professional management. Not with the lack of it all.
Principle number 12: "The team should systematically analyze possible ways to improve efficiency and adjust their work style accordingly."
This is a remarkable principle, which is embodied in the so-called "retrospectives". They work great, as long as decisions make the team better. Unfortunately, in most cases, programmers in Agile teams try to survive , rather than make the team more efficient. Although the principle says that a team should become more effective, these “retrospectives” help programmers to become more effective (read: safer) in a team. This is natural for people, but leads to a general degradation of the team. It is well known that the best team is the one that is able to quickly and inexorably rejectbad items. Does your team do this effectively? Do “retrospectives” help in this? I doubt it. Therefore, I believe that here the Manifesto does not mean meetings. He means that the team should have an effective mechanism of self-regulation and self-improvement. In addition, retrospective meetings simply cannot be such a mechanism, because they prevent the team from making difficult disciplinary decisions.