SmartAdvice: Agile Programming Not For The Risk Averse

Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers two questions of core interest to you, ranging from leadership advice to enterprise strategies to how to deal with vendors. Submit questions directly to [email protected]

Question A: What is agile programming, and should we be interested?

Our advice: In the quest for smaller, faster, and cheaper software, companies have been looking hard at a new paradigm in programming methodologies called agile programming. The first agile methodology, "extreme programming, or XP, was developed in the late 1990s by Kent Beck, Ward Cunningham, and Ron Jeffries.

By 2001, the umbrella term was coined to describe a number of methodologies that shared the common characteristics of breaking projects into small, manageable modules and using a highly iterative development approach instead of traditional "waterfall" schemes. It's particularly effective in startup situations or in secret projects where the final product is, by necessity, ill-defined at the initiation. From a business perspective, this can be very attractive as it more closely maps to the natural market-development cycle.

Related Links Extreme Programming: A Gentle Introduction FitNesse Agile Software Development With Scrum Domain-Driven Design

What distinguishes agile programming from the more traditional "top-down" design methods is that once an overall architectural framework has been established, the entire project is divided into small modules that can be developed into fully functional, tested, and potentially usable releases in a short amount of time -- often in less than a week or even a day.

Since the agile approach places a higher value on risk management, early user feedback is highly valued. Agile projects should either succeed or fail early on, before too many resources have been committed. There's nothing worse than investing a lot of resources before finding out the product has features the users didn't want or need. That means that teams can focus on only the modules and features that have the most value to the users. Marketing types love the approach, because even early in the development cycle, important features are functional and ready to demonstrate.

Although it's not essential, it's a good idea to plan the overall architecture at a very high level, in the sense of deciding on the interfaces and protocols, vendor libraries, etc., before creating the individual working modules. It's best if everyone on the team has a good understanding of the overall design and the reasons behind the design decisions.

Because agile methodologies are so dependent on creating separate working modules, they require lots of embedded and iterative testing throughout the development cycle. Yes, quality-assurance and user-acceptance testing is part of the process, but instead of tacking it on at the end, where the temptation to truncate the testing to meet deadlines is high, it's built into the coding cycle.

Agile programming used in the right context and for the correct project can be an extremely effective technique. By modularizing the project into interlocking, manageable chunks, each feature can be developed separately while maintaining overall product functionality during the process. Of course, as with any methodology, the keys to a successful application of agile programming tools are good programming practices and excellent project-management skills.

--Beth Cohen

1 of 2