How to Realize the Full Potential of Agile Development

Agile has become popular with enterprises looking to modernize their application development approach. Enterprises who have embraced Agile methods see higher project success rates and improved customer satisfaction. But in moving toward Agile, some enterprises have found themselves trapped, process-wise, between the old and new. Here, Knowledge Center contributor Tracy DeDore shares steps that companies can take to reap the full benefits of Agile development.


Many companies are embracing Agile software development methodologies for the benefits they offer versus sequential or waterfall development. The promise of Agile is to enable application development teams to focus on delivering higher quality software faster and to collaborate closely with the business to ensure that the software meets expected business requirements.

In short, an Agile approach to software development enables organizations to become more productive by increasing the response time to changing business priorities, reducing the amount of rework and lowering business risk by identifying defects earlier in the application delivery life cycle. However, to realize the full promise of Agile, organizations need to move beyond the mindset that it is a developer-centric practice. All key stakeholders in the software life cycle must embrace and become part of the Agile delivery process.

Fully embracing Agile

Agile is most effective when its practices are applied at every stage of the application delivery process, beyond just development. Completing the code faster doesn't get the application to market quicker or with higher quality if key stakeholders in the organization-business analysts, quality assurance (QA) engineers, project managers, etc.-continue to follow waterfall practices and timelines. Every stakeholder involved in the delivery of an application must be included in the Agile methodology to ensure that teams are aligned on the project objectives, processes and timeline.

As organizations move towards adopting Agile processes, many suffer from piecemeal adoption. In some cases, developers move into sprint-like iterations, but the work of business analysts and testers are left in their old, sequential places in the project plan. This problem of part-waterfall and part-Agile within a single project is common enough to have earned its own moniker: "scrummerfall." (The joke being that projects fail twice as fast as they would have with waterfall alone.)

There are three key questions that can help you determine if you've fallen into the "scrummerfall" trap. First, ask yourself, "Are my Agile projects discovering code defects earlier in the life cycle than my traditional projects?" With Agile, you should always surface issues sooner. Second, ask yourself, "Am I seeing fewer defects in finished products when I compare my Agile projects with non-Agile projects?" Agile should improve the quality of a software project while decreasing the costs of fixes. Third, ask yourself, "Are business stakeholders generally more satisfied with Agile projects?" Agile should help business and IT better communicate expectations.