The myths and misconceptions of Agile

Myths are widely held but false beliefs, ideas or stories. Myths are different to limitations. In this article, we discuss the myths and misconceptions relating to Agile and show how they are untruths or ill-informed opinions. In another forthcoming article, we will look at the limitations and pitfalls of Agile and how to overcome them.

Firstly, myths can vary based on whether someone is an “Agilest” (They are Pro Agile), “Traditionalist” (They are pro Waterfall, but may not necessarily be anti-agile), “Sceptic” (Don’t believe in Agile) or “Agnostic” (Don’t believe in either Agile or Waterfall).

Secondly, myths are different from opinion in that myths are collective and opinions are individualistic. While it is hard to argue whether myth or opinion is worse, it is amusing to note that most people who voice strong opinions about anything know the least about it. If they knew much about something they would have “insights” and not “opinions”.

Thirdly, myths are wider manifestation of deeply-held beliefs. They are often not substantiated by proof or evidence but are supported by “anecdotal or second-hand experience” or hearsay.

Lastly, misconceptions are not myths. They are just mistaken views, concepts or understanding. Misconceptions can be more easily corrected than myths.

Let us explore some of the popular myths regarding “Agile”;

Popular Myths of Agile

Agile is just another fad and it will pass too

Rebuttal: If Agile is a fad then it appears that fad has survived from the 16th century. The word Agile has its origins from the Latin word “agilis” meaning flexibility. The umbrella term Agile refers to a set of software development approaches and practices guided by the values and principles outlined in the Agile Manifesto. Anyone who reads the Agile Manifesto will find it hard to argue or disagree with the values and principles. While “methodologies” can be fads, value systems rarely become fads.

Agile doesn’t require any documentation to be created

Rebuttal: Agile does not advocate nor ridicule documentation. One of the key values states that Agile values working software over comprehensive documentation. This requires two interpretations. One is that, given time and resource constraints, a team should focus on creating working software rather than use up that time and effort on creating documents (for the sake of documentation). Second, the emphasis is on “comprehensive” and not on “documentation”. This means that teams ought to create the necessary and sufficient amount and type of documents, not a copious number of documents that some standard prescribes but nobody ever reads.

Agile projects don’t do any testing and they produces poor quality products

Rebuttal: Agile is very big on testing and nowhere in the Agile manifesto does it say that Agile does not require testing. No software will work without testing. One of the key principles of Agile states “Continuous attention to technical excellence and good design enhances agility”. There can be no agility with broken or dysfunctional software. Agile frameworks recommend a different and significantly more effective approach to testing – where testing is integrated with development rather than as an afterthought and at the end.

Agile projects don’t have any project plans, therefore they will not succeed

Rebuttal: Agile approaches do not require a project plan like Waterfall method does. Agile attaches greater importance to planning but not to plans. Agile, fundamentally, guides teams to develop an ability and approach to cope with change. Change is useless to project plans. Therefore, the planning ability is vastly more useful and important than conforming to a plan. In any case, a plan tends to be useless because it assumes the future and the future rarely turns out to be as assumed in a plan. The ability to respond to changing requirements and conditions is what Agile is about.

Agile projects are chaotic because nobody manages it

Rebuttal: Agile does not have a Manager nor does it require one. Scrum, a flavour of Agile, has the role of a Scrum Master and Product Owner. While they provide guidance and coaching to the development team, they do not tell the team what to do. Agile promotes self-organization and initiative in the team. Self-organized teams become adept at handling uncertainty and ambiguity much better than traditionally managed teams. Maybe, the buzz of collaborative activity in Agile teams is mistaken for chaos by “anti-agilests”.

There is no governance in Agile projects

Rebuttal: Agile projects are “governed” just as Traditional / Waterfall projects are, with a difference in approach. Agile projects too have stakeholders and stakeholders are interested in the status of a project, whether that be done in an Agile manner or traditionally. Product Owners of Agile projects, typically manage stakeholders and provide status inputs for Governance. The emphasis on Governing Agile projects are different to traditional projects. There is no concept of command and control type conformance and governance in Agile environments. Governance in Agile organizations is primarily about quickly and continuously delivering “value” to the customer / user and helping the team by removing obstacles in its path to delivering value.

Agile will not work if the entire team is not sitting in one room

Rebuttal: While the best form of collaboration and communication is the face-to-face interaction between people, several organizations are running distributed Agile projects with team members geographically dispersed across continents. This is the reality of the world today and rather than take a defeatist attitude towards it, organizations should work on bridging cultural differences and strengthen the one-team concept by leveraging diversity in skills, talent and approaches.

Misconceptions of Agile

Agile is another software development method

Correction: Agile is an umbrella term for several approaches such as Scrum, Kanban, Lean Software Development, Extreme Programming, etc. Most are frameworks comprising practices. All of them conform to the Agile values and principles. Few of them, if any, are “methods”. To clarify the semantics, a “method” is a procedure for accomplishing something. It implies the qualities of being well organized and systematic in thought or action. Results from following a “method” usually require “conformance” to the systematic procedure. That idea conflicts with the flexibility principle of Agile. A “framework” is a basic structure, underlying a system or concept. A framework is less prescriptive than a method and is intended to be a guide to doing things under an overarching set of values and principles as with the context of the Agile Manifesto. Waterfall or traditional project management is a method.

Agile works for only certain types of software – Mobile apps, Digital, Web, etc.

Correction: Agile works for all types of Software development – Digital, Mobile, Web, Enterprise, Client-server, Interfaces, Integrations, Legacy, Etc. Agile approaches also work well for non-software products. Agile is well suited for unpredictable, ambiguous, unique, complex, frequently changing not easily estimable projects. On the contrary, if requirements are completely and unambiguously defined, clear and unchanging and the required effort for completion can be easily and confidently estimated and very similar projects such as the one being considered have been done by the same team several times before then Waterfall or traditional project approaches work well and don’t need to be Agile.

Time-boxed Waterfall is also Agile

Correction: Time-boxed Waterfall also humorously called “ScrumWaterFall” is not a good practice and needs to be discouraged. It is better to use either Waterfall or Agile, but not a combination. Agile is not simply time-boxed execution of projects. Agile starts with prioritising requirements based on value which doesn’t happen in Waterfall projects. Agile projects aim to create a usable iteration of a product in every time-boxed cycle called the sprint. This requires the use of all tasks such as requirements, analysis, design, coding, testing, defect fixing, release, etc. to be completed in that sprint for a smaller set of requirements. Time-boxing by functions or tasks is not Agile.

Agile is for the nerds and not for “real projects”

Correction: Agile is for anybody who is involved in developing products effectively, software or non-software. Agile approaches closely involve customer representatives, Product Owners, Scrum Masters, Coaches, Developers (Programmers, Analysts, Architects, Designers, Testers, SME’s etc). Most of these people are “real people” working on “real projects” and are not the nerdy types.

Agile is faster and cheaper than Waterfall

Correction: Agile aims to produce working software that delivers value to customer, early and continuously. It does that through prioritising Software requirements based on value and through iterative and incremental approaches. While “faster” and “cheaper” are not the drivers for Agile, most often those outcomes are achieved through the focus of delivering value. It is nearly impossible to categorically say whether Agile projects are faster and cheaper because very similar projects are unlikely to be done using Waterfall and Agile approaches in similar contexts and environments. Cost and Time comparisons tend to be subjective and based on opinions. There is empirical evidence to suggest that less time and effort is wasted in Agile approaches than in the Waterfall method.

Agile is a silver-bullet and can solve all software development problems

Correction: Agile is not a silver-bullet and does not solve all problems relating to software development. Agile aims to solve the most important problem relating to developing software that users and customers perceive as valuable. Agile approaches solve that customer value problem through close collaboration and the “fail-fast to win-fast” approach.

Agile is suited only for small projects and small organizations

Correction: Agile approaches can be adopted for projects of any size and in organizations of all sizes – small, medium and large. While it is true that Scrum teams are best limited to 9-11 members, large projects can be broken down into several smaller and related Scrum projects and teams that work on the common set of backlogs. Approaches such as Scrum of Scrum and Scaled Agile Framework make Agile work well at enterprise level in large organizations.

Summary

Myths are dangerous and need to be debunked sooner than later. Although it is now 16 years since the Agile Manifesto was published, less than 50% of all software development projects and less than 50% of all organizations have adopted Agile today. They are losing out on the key benefit of delivering value to their users and customers. Organizations and teams that are hesitant to try and adopt Agile practices probably reflect their organizational culture of preferring to maintain status quo rather than try something new. Experimentation is an innate quality of innovating organizations. If after adopting Agile practices, in a few projects and over a period, an organization does not see any benefit then they can always go back to their old and traditional ways. At least they will have tried something and learnt from it rather than fall prey to myths, misconceptions and opinions.