Top Agile Myths & Misconceptions | David Tzemach
Updated: Jan 12
It sometimes amazes me that there are still people who haven’t heard of Agile or what it represents. Below are some myths and misconceptions that people have believed about Agile. Of course, if you've ever worked in an Agile environment, some of these items might come as a surprise. But these are things I hear again and again.
Agile Is a New Force in the Software Industry
No, Agile is not new. However, the Agile Manifesto was published in 2001. At first glance, this seems to be a relatively new concept, but it’s not. It can be traced back to the mid-60s; it is certainly not as new as people think.
A close look at the report from the 1968/69 NATO Software Engineering conference reveals some great insights about the early origins of Agile (page 32, Perlis):
“Through successive repetitions of this process of interlaced testing and design, the model ultimately becomes the software system itself.”
Agile Is Better Than Traditional Methodologies
Although more and more companies are using Agile as the preferred way to develop their products, this assumption is wrong. The type of development methodology should be determined per project and based on environmental variables. For example, we can use the Waterfall methodology if we have clear and informative requirements from day one of the projects. Also, when we have a stable environment, that increases the predictability of the project with respect to the work that needs to be completed.
There Is No Documentation in Agile
This myth may have started with the Agile manifesto itself by stating, “Working software over comprehensive documentation.” Even earlier with Kent Beck, the founder of Extreme Programming, who is reported to have said: “Documentation may only be necessary before I die, and can't explain it personally.”
This wrong interpretation led people to believe that being Agile means no documentation, which of course, is not the truth. In Agile, you can have as much documentation as you need because it can be part of the team deliverables. It provides value to the customer and the development team/organization.
Deadlines do Not limit agile Projects.
Agile is not a free ticket to abuse the project timelines like traditional methodologies. Remember that there is a customer who is paying for the software (and a company that needs to earn money…). There is no chance that a customer will agree to work with a company if they are told there is no expected time for project completion.
The main thing in Agile is that we can deliver incremental releases of the product to allow the customer to review the project’s progress and use a basic set of functionalities that increase as the development sprints progress.
Agile Revokes the Need for Planning
In Agile, planning is everything! No project does not involve significant planning. The main difference in Agile is that the planning is spread throughout the whole development process, rather than at the beginning, as in traditional development.
In Agile, there is less up-front planning because planning is performed per sprint, continually until the completion of the project (there is no need for significant up-front planning that will become obsolete due to changing requirements). However, customers and critical stakeholders use sprint plans. Any deviation from a particular delivery date may be seen as a failure on the part of the team and not as a failure of the plan itself.
Agile Is the Cure for All Problems
Agile will not solve all problems related to the Software Development Lifecycle, but if used correctly, it will most likely help the organization increase the percentage of project success. It will also increase visibility, improve communication, and continuous improvement if the process continues.
Agile Is Not Suitable for Large Projects
Managing large projects is very demanding, no matter what methodology is used. The main difference between Agile and traditional methodologies is that we take a large project and break it down into small manageable deliveries rather than delivering it all at once.
Agile Means No Design
Does this even sound logical? Of course not; being Agile does not mean a project does not require any “design” supporting it. The main difference between Agile and other models is that in Agile, the design is reviewed and updated continuously throughout the development process.
There Is No Need to Plan Your Testing Activities
Test planning in Agile is part of any planning session and occurs at the beginning of each sprint, where the team will work together on stories to determine the test strategy for the upcoming Sprint. Moreover, the testing effort must be based on quality standards. These must include up-front planning to support the coding activities involved in developing each user story.
Who Needs Test Documentation?
In Agile testing, we have fewer documentation activities, such as creating long, comprehensives STP docs or STDs containing thousands of test cases. This does not mean the team is free from documenting their tests at some level. As part of the testing activities per sprint, the team must document their tests somehow. Irrespective of the testing methodology used (e.g., Exploratory testing, Risk-Based testing, automated testing, etc.), we need some documentation to gain the most from the test execution process.
Tools Will Remove the Need for Testers to Communicate With Other Team Members
The Agile manifesto gives importance to people over processes and tools. Tools are essential in any environment, especially in a fast-changing environment like Agile. Tools help reduce manual labor and costs and allow team members to focus on crucial quality artifacts. However, in Agile, we rely on people to collaborate, irrespective of the tools used in the development activities.
Testing practices based on a well-designed strategy are always more important than just using tools (essential as a supporting layer). Testers must be key players in the overall development sprints, including participation in daily sprint meetings, planning meetings, etc. This needs to be from the beginning of the project and part of the development of each user story to add their insights as early as possible.