What Are the Business Reasons for Using Agile?
What Makes Agile Programming Different?
Won't I Have to Do a Lot of Extra Work?
What's Different, Besides Working in Iterations?
Won't Working Like this Change Our Corporate Culture?
When Should I Avoid Using Agile Programming Techniques?
Is There Just One Kind of Agile Programming?

When Should I Avoid Using Agile Programming Techniques?

There isn't a silver bullet for application development. There never is. Although Agile programming techniques can help you create great applications very quickly, these techniques don't work for every project.

For example, an organization may truly need to create a huge application that can't be broken down into small pieces, and which requires more than 20 developers. If you're creating a heart monitor application for a major hospital, you don't want to create just the part that monitors the heart and deploy it without the parts that send out alerts when a patient's heart fails. In this case, you must create the entire application and test it as a whole before deployment, or else you'll end up with a lot of dead patients (and lawsuits). Agile programming techniques aren't a good solution in this case, because the system quickly breaks down when too many people are involved.

Applications that require a distributed development don't work well with Agile programming techniques, either. If you have some developers in England and others in the United States, team members can't communicate quickly enough. Distributed teams have difficulty getting all of the benefits of Agile methods, even though tools such as instant messaging or IRC may compensate somewhat. The system can quickly bog down, and you'll find yourself devoting a lot of time to keeping individual team members updated.

You may also find it hard to use Agile programming techniques with mission-critical applications where every single piece has to work at the outset. Because Agile programming techniques work best with small iterations, you won't get a whole application put together immediately. The process requires that the organization deploy the partial application to invite comment from the organization as a whole. The goal is to fix any real bugs and usage problems quickly, not to create one monolithic application that can't be tested until the end of the project.

Some companies simply don't adapt very well to Agile programming techniques because they have a command-and-control management style. That kills the creative process required to make Agile programming work. Most experts regard the command-and-control management style as outdated and a real problem that the company should work out.

Is There Just One Kind of Agile Programming?

The Agile programming umbrella shelters a significant number of methodologies that you can use to accomplish your goal. The precise method you use depends on the kind of application you want to create, the customers you must satisfy and the environment within your organization.

• Extreme programming (XP): This method places a high emphasis on adaptability, rather than predictability. It works best in scenarios where the organization doesn't know precisely what end product it needs. This is the method first employed by Kent Beck.
• Scrum: This places an emphasis on restarting an iteration, rather than attempting to fix the problem. It works best in scenarios where the organization is using new tools and wherein the application will almost certainly change during development. Jeff Sutherland first used the Scrum method at the Easel Corporation in 1993.
• Adaptive software development (ASD): This method places an emphasis on speed and flexibility. It works best in scenarios where the organization needs to produce results quickly for an application that could grow as customers use it. Jim Highsmith developed this method.
• Dynamic systems development method (DSDM): This was originally developed from rapid application development (RAD) techniques that place an emphasis on user involvement. It works best in scenarios in which the application must work in a complex environment that the developer doesn't understand very well. The DSDM Consortium developed this methodology in 1990 in the United Kingdom to consolidate programming best practice experiences.
• Feature driven development (FDD): This places an emphasis on predictability and adherence to development best practices. It works best in situations where the development team must create an application with specific features and higher-than-normal reliability. Jeff De Luca originally developed this method to accommodate the needs of a large Singapore bank in 1997.

This isn't an exhaustive list. Other Agile programming methodologies, such as Crystal Clear, could have a place in your organization. The fact is that Agile programming is so useful that people are finding new ways to use it all the time. Consequently, you'll continue to find organizations that create new Agile programming methodologies.

Further Reading on CIO.com

• Sign up for the CIO Development & Architecture newsletter
• Learn how other companies are deploying agile technologies in The Best Way to Implement Agile Development Processes: Your Own Way — and then judge your company's effectiveness with 10 Questions To See If Your Company's Developers Are Agile.
• Examine a case study in software planning in Agile Development Can Avert Disaster: How and why two projects went wrong and what Agile Development could have done to save them.
• Five Things IT Executives Should Know About Software Requirements
• Taming the Wild Child of IT—Application Development
• The Secret to Software Success
• How Simulation Software Can Streamline Application Development

John Mueller is a freelance author and technical editor. He has writing in his blood, having produced 73 books and more than 300 articles to date. The topics range from networking to artificial intelligence and from database management to heads-down programming. His most recent book is VBA for Dummies, 5th Edition.