Continuous integration
One of the pitfalls of waterfall methodologies is that integration of the codebase often happens weekly or monthly. Often, new defects are revealed as code is integrated, and additional time has to be spent fixing bugs and reintegrating. With infrequent integration, feedback is not as tight as it could be. Agile promotes much more frequent integrations -- in 3Q's case this means integrating once or twice a day.

Most teams elect to have a build machine, where pairs of developers can check in completed code that has been written in the test-code-refactor cycle. Each pair is confident that their code has been tested and refactored prior to being integrated into the code base. Once checked in, the automated build machine compiles all the code, runs all the tests and displays via a monitor (out to the team) -- whether the build needs attention -- for example: did the newly checked in code break anything?

This does two things:

• Creates the smallest possible time lag between code that is integrated and to the team realising there is problem.
• The build monitor radiates information to the whole team -- either the integration was successful -- or needs attention -- allowing the team to reprioritise right away.

  Integrating this frequently means that a working build of the software is always available for anyone. Significantly for this to work as well as possible, the build needs to be automated to make integration as easy as possible. Below is an example of 3Q's build monitor that radiates information to the team.

  
  
  
  As the pictures demonstrate, the build monitors can provide additional information to the team.

  Critical success factors

  • Automation -- this needs to be an automated process. Otherwise you have to have one developer who runs the build -- not a fun job. Get the environment, equipment and automation set up first.
  • TCR and Pairing -- for this level of integration to work, the team must be working in a test-code-refactor cycle so that they are confident that the only defects are coming from the integration. Without the TCR cycle, this part of the process will be difficult.
  • Take one step at a time -- as with all of this, start slowly and simply and build up over time -- especially areas such as coding standards.

  Maintaining effectiveness - step three
  As we said in part one, Agile processes are intensive ways of working. Add to this that software development itself can be very pressurised, and the team's potential to burn out is quite high.

  Sustainable pace recognises that the development team is and will be working very hard. Overtime is not something we want to encourage, although at times it is necessary. If a team does have to do overtime, we want to try and minimise this to say one to two weeks of overtime rather than a month or more at an unsustainable pace. Again, Agile is a very intense way of working; pair programming requires a lot of interaction and attention, as does the test-code-refactor cycle. While Agile brings out the best in our teams, we need to be aware of the risk of burnout in cases where lots of overtime is required.

  Critical success factors
  This is one area managers have to be very aware of. It will largely be their responsibility to ensure the team keep a reasonable pace throughout the project.