by Sue McKinney

Evaluating Agile Software Development Programs

Jan 23, 20095 mins
Agile DevelopmentDeveloperProject Management Tools

Agile development used to be relegated to small-scope software development projects. No longer, says IBM's vice president of development transformation and integration. She argues that Agile can adapt to the most complex of development projects.

Although it may not be obvious, software is hidden in crucial aspects of your everyday life, from the bank ATM that gives you money, to the E-Z Pass that allows simplified payment methods to major roadways. Delivering high-quality software efficiently is critical to businesses in every industry, and more importantly to end-users. Eighteen-month product cycles are no longer acceptable, and businesses are looking for ways to become more agile and adapt quickly to changing market demands.

Despite the demands of an efficient software development program, many of today’s development projects still function and rely upon a traditional methodology that requires defining all requirements up-front, with little, if any, room for change. The problem with this approach is that most stakeholders are not adept at accurately defining their needs. Coupled with the dynamic pace of technological advances, the results are disheartening. U.S. research firm Standish Group found that 90 percent of software projects are completed late, 66 percent are deemed failures and 30 percent are scrapped.

As you may know, Agile development is a process methodology that enables companies to deliver software more rapidly. It is an incremental, collaborative method aimed at producing high-quality software in a cost-effective and timely manner.

In the early days of Agile, the applications where Agile development was applied were smaller in scope and relatively straightforward business applications. Today, the picture has changed significantly. As companies want to apply Agile development to a broader set of projects, Agile needs to adapt to deal with the many business, organization and technical complexities faced by today’s software development organizations.

To properly analyze the cost of a transition to Agile, you must weigh costs against the benefits, while taking into account any reduction in development risks. For example, a commitment to an Agile methodology requires changing the way engineers spend their time and how they approach all software development activities. Highlighted here are some key points as to why there is such a switch on focus including:

  • Individuals and interactions (over processes and tools)

  • Working software (over comprehensive documentation)

  • Customer collaboration (over contract negotiation)

  • Responding to change (over following a plan)

You must also consider the role you will play as manager. Most managers of Agile and lean development programs take a more hands-off approach. They allow team members to spearhead specific aspects of projects to foster the kind of environment needed to enable the most successful switch to Agile and lean development.

Agile increases the efficiency of a team’s software delivery, which translates into customer satisfaction and revenue. Efficiency is about eliminating waste in a particular activity, which may or may not have an impact on the larger goal. However, efficiency does not suggest that you are doing the right thing, or doing things in the right order. Efficiency is bigger and more important since it suggests that you achieved a goal.

Among other important Agile development principles are ongoing customer involvement and, as briefly mentioned earlier, consistent team collaboration. Stakeholder feedback on working code and test-driven development is essential to rolling out a successful project as well. Stakeholders—including business stakeholders, operations and support staff, and other enterprise IT professionals—need to be involved early and often in Agile projects throughout the life of a project, actively participating in modeling and testing efforts and sometimes even in development. This level of involvement enables them to see the inner workings of the software development efforts. It motivates developers to focus on the priorities of their stakeholders rather than their own personal priorities that may not enhance the product’s usage.

These guidelines provide the foundation for how companies can respond quickly to, and be ready for changing requirements. For example, using Scrum (a method of Agile development that borrows its name from a rugby play), a daily “scrum” or meeting is held with all the stakeholders. Every day, developers answer three questions:

  1. What have you done since yesterday?

  2. What are you planning to do by tomorrow?

  3. Do you have any problems preventing you from accomplishing your goal?

This daily meeting ensures that everyone is accountable for what they are doing and that teammates are able to highlight errors and incompatibilities before they become catastrophic. It also ensures that someone can respond promptly should an emergency arise.

Agile Development is often criticized for being undisciplined, which is far from the truth. Communication and discipline are the two fundamental components of Agile development. Agile’s greatest motivator of discipline is the regular delivery of working software. The shorter the cycle, the greater the discipline required to make it work—for instance, having to provide concrete, measurable business value in the form of working software at every iteration.

While the debate over discipline in software development continues, one thing is certain: Interest in Agile and lean development is increasing. At IBM alone, in the last two years, the number of Agile projects has increased from 5 to over 200.

Sue McKinney is vice president of development transformation and integration at IBM. She is currently responsible for development transformational activities with IBM’s software group. Her major focus is driving adoption of Agile and lean principles into the mainstream of software development. Sue also works with large clients to share IBM’s experience and help them scope opportunities for their own transformational activities.