Continuous Integration

Agile Methodologies demand frequent deliveries in short cycles. It's desirable to fully automate the mundane process to checkout latest code, build, deploy, test, and send out notification on errors. Continuous Integration (CI) come into the play. There are some other significant benefits to adopt a CI tool:

• A fully automated process will improve the quality standard for build processes. You don't need to worry about scenarios when the code works on programerA's environment, but not programerB's.
  
• Code quality will be improved. For a large project with many programmers, it is inevitable to accidentally check in uncompilable code. You can count on the CI tool as a safety net to catch the errors before they pollute the whole team's working environments. To be specifically, the CI tool can be configured to check out code every 15 or 30 minutes, catch the error, and send out notifications accordingly.
  

You may have vivid memory how frustrated you were when hours of debugging work only pointed to non-reliable build process or non-stable code repository. So you cannot wait to try out a CI tool. Amazingly the efforts needed are trivial. You may only need a hardware, an open source CI tool, and some configuration work. For the hardware, you need a dedicated box to do the CI work exclusively. For the software, there are several major players on the CI arena, for example, Hudson, Cruise Control and Continuum. Java World has a good article to compare them: http://www.javaworld.com/javaworld/jw-11-2006/jw-1101-ci.html

Most configuration work is easy if you are familiar with build scripts like Maven or Ant. It may be a little bit challenging to configure those scripts to be environment-agnostic. You may wish to put all environment-specific variables into a configuration file, which includes, directory locations, database connection strings, external system URL's and etc.

Limitations of Agile Methodologies

Agile Methodologies are adaptive, iterative and incremental. Their effectiveness is well recognized in the industry. However, there is no silver bullet. The Agile Methodologies have their limitations and demand a close interaction among end users, business analysts, developers and testers in short cycles. It implies a break down of walls among divisions and the formation of a coherent and collaborative team from different groups. The Agile Methodologies work best for co-located teams. In certain circumstances this is simply too expensive or politically impossible. Another consideration point is the team size. When the size of the development team increases, it's agility decreases.

In a conclusion, think twice before adopting Agile Methodologies for large scale projects or distributed development teams.

Agile Methodologies vs Waterfall

Let's consider the simplified version of a complicated question, how to develop a system composed of ComponentA and ComponentB? ComponentA can be a software sub-system. ComponentA can also be deliverable artifacts like documentation, design, or code. The assumptions are: ComponentB cannot be started until ComponentA is finished; both ComponentA and ComponentB take significant efforts to finish.

The straightforward answer is:

• Step One: Finish ComponentA;
• Step Two: Finish ComponentB;
• Optional Step Three: Assemble ComponentA and ComponentB together.

This is exact the sequential waterfall approach. It mimics what an assembly line has been doing in the mature manufacturing industry over decades of years. However, software is quite different from hardware. By its very nature of flexibility, software development process is much less predictable. Big surprises (or risks) may arise:

• The ultimate goal of the project is a moving target;
  
• By any chance, if ComponentA is delayed, all components down the chain will be delayed;
• If a working project cannot be delivered finally, ComponentA may be totally useless.
  

To control the risks, Agile Methodologies, the iterative, adaptive and incremental approach, are preferred. The process looks like:

• Step One: Finish (ComponentA-- and ComponentB--); "--" means a simplified version of the system;
  
• Step Two: Finish (ComponentA- and ComponentB-);
• Step Three: Finish (ComponentA and ComponentB).

The benefits are listed below:

• Be adaptive to changing requirements. End user's feed back can be heard early. To do the right project is more important than to do the project right.
  
• Progress and deliveries are very visible. We don't have to wait until the Step Three to see some workable results.
• If by any chance, there are limited budget, time, or resources to finish the Step Three, the results of Step One and Step Two are still acceptable working systems.

For any approaches adaptive in their nature, people will raise the question, how to make the short term targets in line with the long term goals? This question has an assumption that the 'long term goals' are well known. Agile Methodologies help most when the 'long term goal' is unclear or when the process how to achieve the 'long term goal' is unclear. The short term cycles help to clarify things during the iterative process. If both the 'long term goal' and the process how to achieve it are crystal clean and carved into a stone, go ahead using Waterfall with no hesitation.

It's my motto that - Release early, release often, and release working products. However there is no panacea to resolve all software quality and delivery challenges. In another post here, I discussed limitations of Agile Methodologies.