An Agile approach to software development looks good on paper. However, author Rajashekar Reddy Ramasahayam argues that it may not be a fit for all projects.
An Agile approach to software development looks good on paper. It refers to working collaboratively with cross-functional teams, taking an adaptive approach, and making continuous improvements along the way. It requires companies to be nimble and flexible. When used to develop software, an Agile methodology can lead to systemic changes in an organization and in various departments as everyone adapts to the Agile ideology. Recognizing and understanding the principles and the core values are essential before embarking on this path. On the other hand, Agile may not be ideal when the company is working within a specified timeline and budget, and when they cannot change the scope of the project once it is launched. Consider wisely. In some cases, the more traditional project management approach known as “Waterfall” may turn out to be the better approach for software development projects.
How Agile started
Agile evolved as an alternative to traditional project management at the beginning of the 21st century. It came at a time when many software products were taking too long to complete or failed to even reach that point due to a lack of adequate collaboration amongst all the parties involved. That led to the creation of the “Manifesto for Agile Software Development,” which was defined by a team of 17 software developers, with representatives from Extreme Programming (XP), Scrum, DSDM (Dynamic Systems Development Method), Adaptive Software Development, and other purveyors of Rapid Application Development. The goal? Find a more efficient alternative to software development and create a structure to ensure success. Key principles identified in the Manifesto included:
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- Continuous attention to technical excellence and good design enhances agility.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Working software is the primary measure of progress.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Pros and cons
The Agile approach, which sounds like it should always be a win-win for all parties involved including the end users, has its pros and cons. With an Agile methodology, products get to market faster, with more flexibility and better communication between all the parties involved beforehand and during the development process. Yet, when continuous adaptation of the process to the work at hand is employed in an Agile environment, some predictability and documentation of steps along the way can be lost in the shuffle. In addition, the product first released to the marketplace may wind up not being the most optimal version due to a shortened development time frame in a fast-paced, ever-changing marketplace. As a result, the outcome and timeline for completion can be less predictable with an Agile development process.
A second issue involves the participation of the end user in the process. A key element of Agile development is customer (product owner) involvement. Ideally, when the customer is involved upfront, it can save time and effort in determining what the customer really needs from the software package. Here the role of trust becomes critical to the success of a project. Whether it’s trust in the input being received or trust in the competence and skills of individual team members, absence of trust can lead to dysfunction. To avoid dysfunction and the resultant lack of trust, which can disrupt the process, Adam Fridman wrote that “testers, customers, and developers must constantly interact with each other.” If this is not possible for your project, Agile might not be a great fit.
Third is the importance of selecting a software development approach that supports your corporate culture. Agile is conducive to environments that are more collaborative, team-oriented and where fewer people work in silos that isolate them from other departments. According to one survey, agile has a 64% success rate, compared to just 49% for the waterfall model. The 2015 CHAOS report from the Standish Group also discovered that the agile method produces a higher success rate than the waterfall model, with a much lower failure rate as well (9% vs 29%). But if your culture will not support such a collaborative approach, perhaps Agile is not right for you. In his Inc. piece on the downside of Agile software development, Adam Fridman details the “greater demands on developers and clients [that] require close collaboration and extensive user involvement.”
Last, it’s essential to look at complexity and timelines when considering the pros and cons of Agile methodology. In some cases, the more traditional Waterfall approach that Agile replaced involves more detailed long-term project plans and a single timeline. An added definitive project management structure is employed, and a fully completed product is to be delivered at the end of that timeline. By taking stock of project requirements to see what methodology makes more sense, companies can choose whether a traditional or Agile approach makes better sense. Questions to address in this process include:
- How well-defined are the project requirements? Are the end products needs clearly defined? The more likely that the scope of the project is to change somewhere along the development and testing process, the more an Agile approach makes sense.
- How long is the planned product duration? What’s the due date, when is it needed? What must exist at the due date to meet customer needs? If the customer is okay with getting a product sooner rather than later, even if it requires a subsequent tweaking, then again the Agile approach would be the preferred methodology.
- Are there regulatory compliance issues that might be easier to comply with by using one approach over the other? With agile development, documentation may be subject to change often and may be less detailed, with time being of the essence and additional players often involved in the software development process. With Waterfall, detailed documentation in every project phase is often available upfront before implementing a project and that may better align with compliance requirements.
Employing or consulting with a software coach or expert who knows how to apply Agile and Waterfall principles could be beneficial when making this decision.
A growing appetite for Agile methodology
Regardless of the above challenges, research firms forecast a steady growth in the market for Agile project management tools and methods. The estimated size ranges from five billion dollars-plus in 2020 to almost ten billion by 2026 (mordorintelligence.com). Well-known companies that use Agile include Apple, IBM, Microsoft and Procter & Gamble (wrike.com). In today’s “got to have it yesterday,” ultracompetitive global environment it would seem that for many Agile methodology has arrived at just the right time.
But one last word of caution. If the adoption of an Agile approach is not managed well, teams might deliver products faster, but these projects might fail due to quality or not delivering enough value to customers. When the product team is unsure at the onset what needs to be built and cannot get help understanding the requirements, they may forge ahead but never get the information necessary to deliver value or quality.
Regardless, when all is said and done, Agile methodology wins the day for many. When team members are primed to make adjustments along the way following Agile principles, an Agile approach can produce more features in a shorter period of time during the brainstorming and development process. Agile also gives the team more flexibility throughout the process so that development teams can take advantage of rapidly changing business requirements as the project unfolds.
The bottom line: it’s important to know and address the pros and cons before embarking on the Agile development path.
Under which scenario waterfall is better than agile methodology strategy? Any examples please.