The use of the Agile methodology has rapidly grown in popularity, largely replacing the use of Waterfall in the software industry. The Agile principles stated in the Agile Manifesto favour a more iterative and incremental approach to software development that is more… well, agile, and adaptive than the traditional Waterfall approach. The use of these Agile principles to guide the software development process addresses the issues modern software companies faced when using the Waterfall approach for more commercial and end-user product development. However, Agile does have its own limitations and issues to be aware of.
- Faster delivery of a product to market or value to the customer.
- A basic, functioning, piece of software is developed quickly to increase speed to market or value to the customer quickly. The value transfer to the customer is much sooner than in a traditional software project.
- More adaptive and flexible.
- The working software is iterated using feedback on how the customer uses it or feedback about what more they would like from it.
- Customers don’t need to make all the decisions about the final product up front – they can make decisions, changes, or adjustments based on what they discover from using the early versions of the product.
- Software will be more aligned and tuned with customers’ needs based on what is discovered during iterations.
- Many smaller and more frequent reviews (leading to higher-quality software with fewer bugs).
- Developers complete smaller chunks of code, so reviews occur more frequently, and take less time to do. Errors or bugs in the code are caught early on, which minimises the amount of rework that needs to be done.
- Better communication (creating a more holistic approach overall).
- People and interactions are favoured more than processes and tools under the Agile Manifesto. There are more frequent communications with the customer throughout the entire development process. It is much more end-user focused.
- There is also more communication internally within the cross-functional software teams responsible for each part of the product. Communication occurs between the whole team throughout all the stages of the process.
- Less focus on the desired end state of the software (final product).
- Developers can get caught up in iterations of the software, zooming in on the now; the focus is on incorporating what the customer wants, or user feedback on specific features and details, rather than focusing on the commercial goal of the product (the desired end state).
- Sometimes consideration is not given to how a specific part fits in with the overall product or the company’s software platform.
- The focus on creating working software can lead to missing required specifications.
- Too much focus on speed.
- Coding is often prioritized over documentation. Although we don’t want comprehensive documentation upfront, we do want a decent amount of documentation. This never really happens though, as developers focus on racing to get the coding done.
- Software teams sometimes fix some of the bugs but defer fixing others so they can declare the code ‘good enough’ to put into the software. Fixing the remaining bugs is then rolled over into the next sprint or added to the backlog of work (increasing technical debt).
For many software businesses, using the Agile approach is more effective at creating a great product than using the Waterfall approach, but it’s not perfect. There can be a tendency for teams to lose focus on delivering value to the customer or aligning with the strategic direction of the company. Being aware of the limitations of Agile can help a business avoid these issues, or you may decide Agile is just not agile enough for you...