Not everyone can implement agile properly and that’s ok: 5 agile myths you should avoid
© Shutterstock / Zein
In this article, Danish Wadhwa debunks some of the most common misconceptions about agile. Are you doing it right? If not, this article should help you discern the truth from myths.
Agile has proven to be a polarizing force to every type of businesses, big or small since a group of software developers proposed it in 2001 in the form of the Agile Manifesto as a reaction to traditional “Waterfall” development, which they found dysfunctional and slow to give results. Agile is flexible and encourages rapid response to changing business needs and user requirements as compared to the Waterfall methodology.
Whether we talk about IT or other business communities, all businesses are justifiably enthusiastic to achieve desired results quickly, and some of them take Agile training to get the most out of advanced software development approaches.
Not everyone is able to implement agile properly due to a variety of reasons. One of the reasons is the disruptive changes in agile to establish processes that place additional burdens on users. The reality is somewhere in the middle.
Agile myths often permeate heated discussions taking place among business leaders considering Agile as their software development model.
“Agile is new”
Agile is not a new concept. In 2001, the Agile Manifesto was published; the Scrum Pattern language was presented during the Object-Oriented Programming, Systems, and Languages (OOPSLA) conference in 1995; the Episodes pattern language that is the forerunner of Extreme Programming was described in PLoP 1995. So it has been a while agile methods are around.
Simply, agile nurtures adaptation in the dynamic environment where variability is experienced. This principle applies to, for example, evolutionary theory. It is also the way of interacting with others on a daily basis– indeed it is the only way of effective interaction in a complex world.
“Agile is easy to implement”
It is hard to change a complex system delivery lifecycle to a simple one. Most of the organizations are likely to make things more complicated rather than to simplify them. Companies who are new to agile are often haunted by the question does agile scale? If it does not, what we should do?
Sadly, some organizations often try to implement an agile operating model or a single agile framework “by the book” but without any knowledge of the transformational complexity. As a result, they either fail to implement agile, or successfully implement it to some extent but by paying off higher costs that they would not have paid if they had managed the transformation more effectively.
These organizations do not realize the complete benefits of agile. To start with agile, you need to develop your mindset first. It is easier to learn how to fly plane theoretically by reading a book but don’t expect me to sit next with you on your first take-off!
“Agile means no planning”
Similar to the waterfall, detailed planning is essential to the effectiveness of agile. The two approaches differ in timings. The planning primarily takes place at the project outset in Waterfall versus ongoing in agile.
The incremental planning approach limits upfront investments and leads to the adaptability of projects to rapidly changing requirements and priorities, scope, etc. with the progress of the project.
There is a planning meeting at the beginning of each sprint to get agreement on the addressed requirements, and they require a high degree of accuracy to correctly estimate the time that each requirement will take to complete. In the meeting, the team prioritizes different tasks collaboratively. The daily standup meeting during every sprint defines the activities for the day at a detailed level. Whether the team is present in the same room or distributed, the scrum master ensures to run sprint retrospective within the team at end of each iteration.
When it comes to an incremental planning approach, most of the businesses face the challenge of technical debt management (cost of code quality.) However, they are able to solve most of the challenges because of their willingness to rework on prior decisions as more information becomes available with the progress of the project.
For businesses, it is essential to understand both user requirements and system requirements to prioritize them effectively as part of the backlog refining process.
“Agile does not require any project documentation”
Documentation serves as a roadmap in any application development effort: It keeps the objective of the businesses, end users, and developers aligned and also explains how a particular system will work and what it will contain.
Furthermore, teams experience the less need for designed documentation as an increase in collaboration throughout Agile development projects provides the better understanding of the end product to all stakeholders.
In fact, agile produces documentation, even though it is different from Waterfall. Rather than creating a single, lengthy document listing all project requirements, for example, project managers might compile user stories that are easy to update and maintain using software, prioritized on the fly, and to ensure real-time visibility throughout development.
“Agile does not efficiently deal with development requirements for federal software”
It doesn’t matter what your federal regulations are; you can continue using Agile methods. Sometimes, specific standard federal practices may present challenges to businesses contracting with software developers that use Agile methods. The three main areas where challenges fall are—acquisitions, enterprise architecture, and security certification & accreditation.
Consider this: Most of the agencies make a list of project requirements along with detailed description of the end product before putting a software development contract out to bid. This is done with the hope to buy a specific outcome from a decided vendor. The question here is what an will an agency do if the outcome changes with during progress of a project?
“Agile is flexible and embraces last-minute changes that result in accommodation of agency requests without any delays, change orders, and budget overruns. But that doesn’t mean agile is only about being faster. We have to be liquid,” experts say.
The changes often become difficult to make after the finalization of all project requirements and is being spelled out in vendor contracts—as mostly are on the federal project. Therefore, a shift in focus from fixed scope to fixed timelines and buying capacity may occur in agile, e.g., user stories and a set number of sprints.