Agile definition and solutions

Every manager knows about the nightmare programming project. The project that takes twice as long as expected, has massive cost overruns—and there’s no end in sight. When you presented the partial application to users, they hated it, yet your company really needs the application to meet certain goals, such as increased production capacity.

Fortunately, you don’t have to live with the problems that the old iterative software development process creates; you can use Agile programming to overcome the issues.

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?

What Are the Business Reasons for Using Agile?

Businesses need a way to reduce development costs, improve software reliability, decrease time to development and ensure applications actually work with the users, rather than against them. These four issues are a tall order for anyone to fill, but Agile programming techniques can do it in many application programming scenarios. Agile makes business sense because you can reduce development costs by reducing the number of errors developers make when designing and building applications. In addition, Agile programming techniques can eliminate that most expensive development cost of all: the failed application.

However, even when an application makes it out the door and you have it installed on your server, reliability costs can eat up any potential gain from an application. The five 9’s of reliability that most companies strive to achieve can happen only with a well-designed application that doesn’t spend more time in the digital repair shop than it does answering users’ needs. Agile accomplishes this task by reducing the number of potential development errors per module and by providing constant testing that locates errors quickly.

Many businesses are looking to obtain a quick return on investment for any development project. Instead, most projects languish for years as the company waits for the developer to complete the application as a whole. Rather than wait for the entire application, Agile programming techniques help you use at least part of the application today, which means you obtain a significantly faster benefit from the application. In short, you can obtain part of the application free because the cost savings you realize go into the development of the remainder of the application.

Applications that work with the user might not seem like such a big deal, but it really can spell the difference between an application that saves (or makes) money and one that doesn’t. A project at a large clothing vendor illustrates this fact. The developer assumed that users would rely on the mouse to select items on screen when taking orders. After the vendor’s new application was installed on the production servers, the company realized a significant loss of employee performance, rather than the gain it had expected. It turns out that the employees use the keyboard exclusively; moving their hands from the keyboard to the mouse to work with the application cost precious minutes for each order.

Agile programming helps you avoid this scenario by involving the user early in the development process. If the clothing vendor had followed this approach, the first iteration of the application would have helped the company realize the expected performance gain. Instead, the company spent time and still more money reworking the application.

What Makes Agile Programming Different?

Agile programming breaks down an application development project into small modularized pieces. Each piece, addressed one at a time in a very short time frame, adds to the application and represents a complete part of the functionality. You can deploy the partial application and expect people to accomplish some level of work with it, even if the application doesn’t do everything you intend it to do in the long run.

Each piece is an iteration that lasts from one to four weeks. As a result, you know immediately when a particular piece of an application proves troublesome. That lets you work through the issue immediately, rather than after you’ve built all sorts of other functionality on top of the buggy or “not what the user wanted” bits.

Each iteration is like a mini-project in its own right. As an Agile project manager, you oversee the planning, requirements, design, coding, testing and documentation stages as you normally do, but you do it for only a particular application feature.

For example, if you were creating a special kind of word processor, one iteration might be its spellchecker. The spellchecker adds to the word processor, but it affects only one aspect of the application. Before the developers create the iteration that handles spelling, users can work with the word processor without that feature in place; they simply can’t perform a spellcheck on what they write.

Won’t I Have to Do a Lot of Extra Work?

Some people imagine that Agile programming techniques require a lot of extra work to implement. However, it actually reduces workload and makes the return on investment significantly faster because of the shorter turnaround time on each component and putting the software into action more quickly.

In fact, because of the swift response that developers can give to such software, managers often use Agile programming techniques to rescue projects that are in trouble. For example, the original designer of Agile programming, Kent Beck, used it to rescue the Chrysler Comprehensive Compensation (C3) project in 1986.

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?

What’s Different, Besides Working in Iterations?

The keystone of the Agile programming methodology is communication. The method emphasizes face-to-face communication, with written documents as the discussion points. In other words, rather than have a lot of people working on their own on various project pieces, everyone gets together and works on the pieces as a cohesive unit.

Unlike other programming methods, Agile programming relies on teams of highly differentiated members who work in a group called a bullpen. A team includes project managers, designers, developers, testers, customers, writers and anyone else who needs to work with the iteration. Because the project piece is small enough for everyone to understand and for all of the stakeholders of the piece to work together, it’s usually possible to get it out the door in a minimal amount of time, with little or no rework.

However, the most important consideration about Agile development is that the development process involves everyone. The customer (user) is involved with the project at the outset, which means that the development team makes fewer wrong assumptions about how the user will interact with the application and the steps required to perform a particular task. This process is very different from the “write a spec, throw it over the wall, and then ignore it until you sneer during the application demonstration” approach that’s common in many shops.

Won’t Working Like this Change Our Corporate Culture?

Agile programming does require a different environment from what you typically find in a corporate setting. For example, all team members have to embrace some level of trust in the other members. No one person can hold out information, resources or data from the other team members. To ensure a good result, the team must work as a unit and avoid the usual political entanglements. In some cases, this may mean replacing one team member with another member who’s willing to trust the team.

In addition to trust, the team members must be willing to compromise. A piece of the application may require certain features and have other features that are nice, but not required. Sometimes, to get the piece finished in a reasonable time frame, a team must decide to remove unnecessary features and save them for a future iteration. The point is that the team must be willing to work together to create the application piece within the given time frame.

Some organizations are used to throwing a lot of people at a particular problem in hopes of getting the job done faster. When working with Agile programming techniques, you use a few highly skilled people. Fewer lines of communication mean that the team members can accomplish tasks faster because there are fewer people who must agree to a particular course of action.

The team will make some decisions that might not prove popular with the organization as a whole. The old saying, “You can’t please everyone” comes into play here. Because the team includes a representative from every part of the organization, the organization must trust the team to act in good faith. The goal is to live with that application piece that the development team delivers. Otherwise, the project can quickly spiral into chaos. Of course, this doesn’t mean that the organization has to accept a buggy application or one that doesn’t work as needed to accomplish the task. The reason to deploy the application in small pieces is to find and fix bugs and usage problems sooner, rather than later, to reduce the cost of repair.

A final piece of the picture is providing an environment that encourages communication among team members. Achieving this goal may require that you set aside a specific place for team members to work. The members should maintain the same working hours and be available to other members as needed. You may have to temporarily assign customers (defined here as someone, such as company users, who will interact with the application) to the team and not ask them to perform their regular jobs during this period.

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.

Here are a few of the more common Agile programming methodologies:

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