Do not get me wrong, I am all for the principles of agile development and fully convinced that:
- A short feedback cycle and good communication within the team is essential, and a team of average engineers who communicate well will achieve better results than a team of brilliant engineers who work in isolation on their own turf.
- Prototyping, frequent deployment and intensive involvement of the customer (both business and IT staff) from the beginning prevents unpleasant surprises in later phases of development and usually leads to higher customer satisfaction with the final product. It is not necessary (or even possible) to have detailed specifications set in stone at the beginning of the project. Gradual refinement and changes to the requirements and their analysis take place throughout the entire development cycle.
What really bothers me is that the term agility has become today’s holy cow, anticipated to cure all the ills of our world. Writers, consultants and various wizards who have never written a single line of source code and whose education, if any, is more often in the fields of philosophy and the arts than in technical sciences have appropriated that word. Unfortunately, these people do not have the knowledge necessary to understand and appreciate the key ideas of agile software development. Instead, they self-confidently promote their own absurdities and, for reasons incomprehensible to me, they are often taken more seriously by top management than those “coders” who are considered a hindrance to progress. This leads to totally unrealistic expectations for software projects. I personally have heard people say that:
“For agile projects, we do not need a project plan.”
All agile methodologies involve planning. The agile approach inherently requires frequent re-planning and refinement of the plan. Agility is not a synonym for chaos.
“The requirements will be specified by the team, so there is no need to consolidate the business’s requirements, anyone can submit any requirement.”
Fundamental misunderstanding! If you have used the popular Scrum framework, you know that the role of the product owner is absolutely indispensable for capturing user stories and formulating and prioritizing requirements. If such a person does not exist or does not have clear decision rights, the team will not be able to produce anything.
“Fundamentally, the requirements can be changed at any time and the team must be ready for it.”
Yes, this is in the spirit of the agile approach, but it does not mean that any change can be made to the finished product for free and within two seconds.
By involving the customer in the project from the very beginning, we strive to eliminate the risk of having to make major changes at the last minute. If that fails, then there is the iron rule of the scope-cost-time triangle that no agile wizard has ever defeated. Therefore, in addition to the team, the budget and deadlines must also be ready for changes.
“Developers must not bother business people. We have analysts for understanding the requirements, don’t we?”
Building isolated silos of analysts, developers, testers and business staff is a corporate sin that not only flies in the face of the basic principles of agile development but also reduces the efficiency of resource utilization. In such an environment, you are always waiting for someone and no one can ask anything, so in the end, there is no product at all or a product that misses the target by miles.
“Documentation is an anachronism.”
It is not. It is just that in each project it is necessary to decide what should be documented and what should not be. This is a method of process tailoring that we have been using at Profinit since long before the arrival of any agile prophet.
“There is no need for analysis or architecture. Let’s start programming right away.”
Again, the rule of tailoring applies to analysis and design. It is necessary to ensure that the requirements are stabilized to a point that permits anchoring of the architecture. Otherwise, get ready for a project with a bottomless budget lasting an infinite amount of time. A note for DevOp fans – I guess you would agree that making tens of releases to production per day requires more than just high spirits; it calls for neat architecture put in place well before writing the first line of business logic or the user interface.
By the way, did you know that technical excellence, solid software design and abiding by the professional rules of software engineering are supported by the twelve basic principles of the “Manifesto for Agile Software Development” written already in 2001?
Do you want more entertaining examples of agile development misunderstandings? I recommend reading “Lipstick Agile”, an excellent article written by Stefan Wolperse.
Do not believe in miracles. Software development is a complex discipline. Agile approaches are valuable and they correctly strive to address some of the risks of software projects. They are useful tools for efficient organization and they bring about healthy standards for project team communication, both internal and external. But they cannot beat the laws of physics as some of the proponents try to suggest. And they do not solve one of the key problems of software engineering that has been bothering the real experts for decades. That concerns finding the optimal balance between three interdependent factors:
- the flexibility of functional and non-functional requirements;
- stability of architecture; and
- financial and time constraints.
If you want to read something truly erudite on the topic, I recommend starting with the yet unsurpassed Barry Boehm article “Anchoring the Software Process”, published in IEEE Software magazine in 1995.