This article is targeted at non-technical, mostly client-type audience. It was written from the approach of selling the idea of going Agile.

The new accounts management software you’re having made has a million bugs, is incomplete, and is late. Your personnel are complaining about how its interface makes their work more difficult. The reports have the data wrong. The project is running way over budget. To top it all the new application is not communicating with the database of your other systems. Oh, and someone set one of the pages to hot electric pink with flashing yellow text.

These are the fears whether having new software made or having existing software modified. We want applications to work right. We want them to be easy to use. We want them to look right. We want them to work well with our previously existing applications. We want them on time and on budget. We also do not want our people to be staring at hot electric pink screens all day.

These scenarios are a fairly common occurrence when employing the venerable Waterfall method. The method of having all project specifications nailed down at the start and making nearly no changes as the project goes on is necessary when dealing with projects like building bridges or manufacturing cars. In those endeavors changes late in the construction process come with astronomically high costs. What would be just the stroke of an eraser and pen to change the shape of a car’s fender on the drawing board translates to millions if the metal stamps have to be changed just before going to production, and even more if already-produced cars need to be recalled.

But when it comes to software, the Waterfall becomes a major hindrance. Software production takes time and over that time a user’s needs can change. Creating specifications also takes time and specs will have to change when a user discovers that something was left out, changed, or was stated wrong. The Waterfall works for making cars since if a customer doesn’t like the car, they buy a different make. But when we commission software, we do not have the luxury of changing brands at the end. It makes sense to make sure things go right.

Enter: Agile

Software has a characteristic not available to automakers and civil engineers: the cost of changing a small, and sometimes even medium-sized, item does not change appreciably with the stage it is introduced. A layout change just before project sign-off costs not much more than that same layout change done in the early stages.

Enter: the Agile development methodology. The three key elements to making this work are:

1. A software development team that is flexible enough to respond to changes requested by the customer.
2. A customer who is willing to take an active role in guiding the software’s development by giving frequent feedback and clarifying issues.
3. The willingness of all parties to work with many short development cycles rather than one overarching one.

The biggest fear customers have with adopting the Agile methodology is that they think they will lose control over the pace of development and that without the all the specifications set beforehand the project will be doomed to go beyond the allocated time. What is not immediately apparent is that while one gives up knowing exactly when a specific module will supposedly complete, the gain is that the module will complete in better time because errors and usability issues are handled much earlier, before they have a chance to propagate. As a result, errors are reduced and even future errors get reduced. Since in many cases debugging software can take up two-thirds of the development time, it is a wise investment to do things in a way that prevents the errors from even starting.

How Agile is implemented, briefly, is that the client and the developers agree on selected features that will be implemented within a specific development cycle, typically a few weeks. At the end of the cycle the features are tested by the client for usability and to see if they work according to their business rules.

The next development cycle is then planned where the developers will get a mix of requested changes and new features to implement. The cycles are repeated and feature-by-feature the application grows toward completion. The features are selected according to business value and the customer picks the features that are most needed first. This way the important features get completed earlier and chances are increased that the application may get to be used even before it is complete. As the features get added the customer also gets a better idea about their needs even when those needs start changing. An unimplemented feature may be dropped in favor of another feature that will create more business value.

If somewhere during development it is unfortunately decided that the project be stopped, the customer is not left with money spent and a mountain of code that gets nothing done. Instead they are left with a partially-complete application with fully-functional features. Instead of projects going over-budget and overtime the project becomes more manageable because errors are nipped in the bud.

Instead of having to make a huge number of corrections at the end, corrections are handled earlier, and later features will frequently benefit from these corrections, so overall there is less corrective work to do.

Instead of all the worries of deadlines and “will it work?” everyone sees a stable application growing steadily with working functions appearing one by one.

So what does it take for you to go Agile? It’s just knowing your business rules, being able to communicate them to the developers, willingness to answer questions and sit with them to select the features that will have priority, and give feedback as to whether the features are working as needed or need to be changed.

Go Agile. It means better-made software, less stress, and more satisfaction. … and no hot electric pink backgrounds.