As Agile software development methodologies have gained prominence, they have inevitably spawned some myths over the last two decades.

TEAM AGILE: Company-X professional services manager Michael Hamid, left, discusses a project with senior software developer Arno van Niekerk, seated, and business analyst Dave Kooker.

Agile development will solve all development problems

While there is much information available about how effective adopting an Agile approach to develop software can be, it is not a silver bullet or a cure all solution.

A major strength of Agile is that it brings the client and the software development team a lot closer and allows all the people involved to understand each other better. 

Software development encounters challenges and problems that need to be resolved. At times these problems can be obscure and difficult to explain to a non-technical client. But a client’s business also has problems that the development team need to understand.  

Often, in the discussions between the client and the development team, a solution can be developed that is technically possible and meets the client’s business need in a way that neither party could see before entering the discussion. 

Agile development does not require much planning

This notion may have come about because traditional waterfall projects took a long time to develop requirements and plan a project.

Agile involves a lot of planning. But in this case the planning takes place continually.  

A two-week sprint typically starts with a planning meeting to plan out the tasks for the sprint. Daily stand-ups also allow the plan to be adjust in small increments each day to manage any problems and/or issues that arise. This is the heart of Agile. The ability to review and adjust quickly as the development continues. This makes the process much more efficient. 

Agile doesn’t produce any documentation

The focus of Agile is on producing working software rather than documentation. This does not mean documentation isn’t produced. Documentation is produced where it adds real value to the software rather than as the main means of communication. Face to face communication is preferred as it is far more efficient and effective in most cases.  

Agile development only works on small projects

Because Agile teams are normally five to nine people there is a notion that Agile is not scalable and won’t work on larger multi-million-dollar projects.  

This is not necessarily the case. Scaling in Agile involves coordinating multiple Agile teams to work on different features concurrently. There are Agile frameworks like SAFe (Scaled Agile framework) that have been developed to enable multiple Agile teams to coordinate their work.

While this does involve more management and coordination of the various teams, this is also the case when using a traditional waterfall method. 

Agile development is faster

This is not really a myth, but it needs to be understood in context. 

Agile development applied well can deliver working software faster than a more traditional waterfall approach. But that is because it approaches software development in a different way. Traditional software development aimed to complete and deliver fully finished working software after the specifications, development and testing of the total product were completed. 

Agile looks to deliver a product that works with the smallest amount of functionality that people can use and then incrementally add more features over time. Using a traditional method involves discussion about all of the features that are needed in the finished product. In Agile, while it is important to have an understanding about the longer-term vision for the product, the discussion focusses on what functionality is critical for the first release. This discipline of constantly evaluating how important a feature is to the product is invaluable in reducing bloated and expensive software that have features most people don’t use.

Michael Hamid is Professional Services Manager at Waikato software specialist Company-X and a teaching fellow at the University of Waikato lecturing project management courses.