Agile Myths that can Fail Agile!

“Setting the record straight on the most common misconceptions about an increasingly popular—and controversial—approach to software development.”

The Agile principles tried to eliminate all the rigidity of Waterfall by focusing on more productive tasks, like working code over comprehensive documentation, adding more customer collaboration, enforcing individual interactions instead of tools and being agile by responding dynamically to change instead of following a static plan. Those ideas took the world by storm and suddenly many software development teams were adopting one of the different methodologies that claimed to be Agile in order to deliver better products at a lower cost, on time.

If Agile is so good, Why and Where Agile fails?

The common answer was that people did not truly understand Agile and were doing it incorrectly. Although that may sound more an excuse with the methodologies not truly acting in an agile way, with static procedures the team must follow without missing a single step, the truth is people were adopting Agile without fully learning and understanding it. Due to that misunderstanding, a set of myths emerged; misconceptions that further made people fail to achieve the promised business value. Let’s see how Agile principles transform to Myths and how these Myths lead to Agile Failure.

Myth 1: Agile is all about Early and Continuous Delivery.

In most agile projects I’ve been involved with, the defect list has grown faster than it can be dealt with. On one medium-sized project, a huge defect backlog had developed over the previous 12 months and required a full-time role just to manage it.Not only did that come at the expense of new features, but it naturally introduced new defects—which were just thrown back onto the same endless pile of things to be fixed.Obviously, large defect backlogs are nothing new in projects, but what is new is that agile promotes the practice of ignoring defects. This leads to unmanageable backlogs and, eventually, to ineffective development. I’ve watched developers, initially caught up in the excitement of collaboration euphoria, end up psychologically worn down by the perpetual defect list to the point of burnout. Agile projects are responsible for burning out many a good developer, which is far from the agile promise that projects “should be able to maintain a constant pace indefinitely”.

Myth 2: Agile means No Planning.

The second myth, hits the agile principle of –responding to change over following a plan. In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes.Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. Detailed planning is as essential to the effectiveness of Agile as it is to Waterfall. The difference between the two approaches lies in timing. Planning is ongoing in Agile versus taking place primarily at the project outset in Waterfall. Agile’s incremental planning approach limits upfront startup costs and allows projects to adapt rapidly to changes (in requirements, priorities, scope, etc.) as the projects progress.

Myth 3: Agile requires ZERO documentation.

The documentation should be replaced by face to face communication per Agile principles. The problem here arises when there are distributed teams – multiple teams, separated by distance, or changing over time in a long-lasting software development project. In any case, some knowledge has to be captured in documents for others to read in case there is no chance of face-to-face communication.Documents are also commonly associated with models, diagrams and manuals. The lack of documentation about decisions and the rationale behind them generates rework when team members start repeating the same mistakes or going the same path that was proven unsuccessful in previous projects. The lack of models also condemns the project managers and product owners to read code or ask developers directly if they want to know what is going on. This generates costs and there is a risk of poor quality information institutionalised to support future decisions.

Myth 4: Follow the methodology and you have Agile.

Agility principles try to improve the development cycle by making developers more collaborative, and including clients in that collaboration. It also tries to improve productivity by reducing non-beneficial tasks. Still, there are a lot of decisions that should be taken using information gathered from all stakeholders and coming from traditional development tasks like requirement analysis and system design. The common outcome is, for large companies with large software systems using traditional processes, the change of methodology only happens at software team level, meaning the client stakeholders are not actively included on the team. With that we have lost most of the information that should come from the client. Then, by following the methodology only, there are other tasks that are not performed, hurting the second part of the information (peer reviews is an example).Agile methodologies are a guide, but they are not the whole solution, and should be customised to the project characteristics.

Myth 5: Agile processes are less disciplined and structured than those of Waterfall.

Mature Agile frameworks prescribe a disciplined, repeatable approach to implementing software. Successful Agile implementations are more process-driven and coordinated than traditional waterfall implementations. From scope management (via user story prioritisation) to project management (via defined roles and events), Agile requires more discipline because a project’s scope is actively managed from planning to launch, with stakeholders reviewing progress at set intervals and providing feedback every step of the way. The flexibility of this process includes built-in safeguards (e.g., suppressing the addition of new requirements or user stories in the middle of a sprint) to prevent never-ending release cycles. 

Learnings?

If wrongly done, Agile produces the opposite of the promised effects. The important thing to acknowledge is that there’s still a lot of improvement that can be brought to the process, even having been through this journey – it’s a constant process of assessment and adaption – but the journey is definitely worth it, despite some of the rocky water we hit along the way!

If you really like my posts on Software Testing and Quality Analysis, please support by subscribing or sharing my blog - qanalysisblog.wordpress.com Feel free to share your thoughts in the comments section below as I learn just as much from you as you do from me. For my original article please refer - https://qanalysisblog.wordpress.com/2017/06/28/agile-myths-that-can-make-agile-fail/