• White Papers |
• Blogs |
• Video |
• Webcasts |
• Podcasts |
• Events |
• Solution Centers |
• Newsletters |
• RSS Feeds

ABC: An Introduction to Agile Programming

By John Paul Mueller

March 28, 2007 — CIO — 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.

 

 

 

Email

Print

Comments

Digg This

SlashDot