Realizing the full potential of Agile Development

BANGALORE, INDIA: Many companies are embracing Agile software development methodologies for the benefits they offer vs. sequential (“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 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; 

* Lowering business risk by identifying defects earlier in the application delivery lifecycle.

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 lifecycle 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, QA engineers, project managers, etc. — continue following waterfall practices and timelines. Every stakeholder involved in the delivery of an application must be included in the Agile methodology to ensure 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/or 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.)

Here are three key questions that can help you determine if you’ve fallen into the “scrummerfall” trap:

1.Are my Agile projects discovering code defects earlier in the lifecycle than my traditional projects? With Agile, you should always surface issues sooner.

2.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.

3.Are business stakeholders generally more satisfied with Agile projects? Agile should help business and IT better communicate expectations.

{#PageBreak#}

Agile Principles & Traditional IT Best Practices:  Friend or Foe?

One reason organizations are slow to fully embrace Agile is the fear that it will promote more bad habits. It’s a justifiable fear.  However, embracing the benefits of Agile such as flexibility and responsiveness does not mean that traditional IT goals like consistency and thoroughness will need to be abandoned.  The truth is that these goals are mutually supportive. 

Consider a few other key areas where “traditional” IT objectives help to further Agile goals:

Speed and quality: To meet Sprint deadlines, Agile development teams often short-circuit the testing effort.  However, this undermines the goal of discovering defects early in the development cycle — perhaps the primary benefit of iterative over sequential methods.

To overcome this, organizations should balance speed and quality through the use of test automation tools to validate the functional, performance and security requirements of the application during each development iteration.  Automation allows you to increase test coverage while still keeping the project moving in Sprint time.

Flexibility and consistency: Unlike traditional methods that often rely on obsolete project plans that are cumbersome, Agile encourages teams to be flexible and responsive to change. Unfortunately, this can sometimes lead teams to abandon formal project management altogether. 

This results in loss of visibility to progress, particularly when teams continue to use sequential methods and planning standards.  Organizations can find the right balance by using a solution that helps manage Agile methods (user story definition and management, release, sprint and backlog management, burn-up, burn-down charts, etc.) as well as non-Agile methods.  This helps provide visibility into the progress across all projects, regardless of the development methodology.

Entrepreneurial and economies of scale: Agile encourages smaller teams to work with greater autonomy. These are good objectives, but they can trend toward limited cross-team collaboration and higher duplication of effort.  To preserve cross-team collaboration, delivery teams should utilize a common repository to streamline the sharing and reuse of project assets and artifacts (user stories, tests, components, known defects, etc.).

Determining when to use Agile

Finding the right balance requires a new approach to developing applications.  It requires stepping back and reassessing your tools, processes and, potentially, your organizational structure.  Below are three things you should consider to determine if Agile is right for your application projects.

1.  Automate Agile processes: Organizations should leverage an integrated management and automation solution that will allow all stakeholders to be actively involved in the Agile delivery process.  Having a centralized system in place will help foster collaboration and develop stronger communication amongst developers, testers and business analysts.  Additionally, an integrated management solution will help increase project visibility and progress throughout the delivery phase of an application. 

2. Begin with a pilot projects: Agile should be adopted in steps.  Start with a pilot project comprising of a small team of business analysts, developers and testers.   Determine what works and identify areas of inefficiencies, then work to correct them before scaling to additional projects.  

3. Use Agile where it makes sense. Remember that not all projects should leverage Agile methodologies.  In cases where business requirements will not change throughout the application delivery process, using the waterfall methodology would be best.

(The author works at HP Software and Solutions, HP, India as Director.)

(The views expressed in this article are that of the author and do not necessarily reflect the views or policies of CIOL.)