Would longer build time hamper Agile Development?

This is one of the biggest issue I have seen in enterprise environment for teams trying to be Agile.

Consider multiple scrum teams delivering features and bug fixes to a common stream. If nightly builds takes 8 to 10 hours for completion then it’s difficult for this group of engineers to be Agile. Build can take long times for various factors like

Hardware – Build is running on slow network and/or running on older hardware that is unable to keep up with the demands.

Software – Build has circular dependencies between modules; each module is being executed in serial order, etc…

Global teams - If multiple global scrum teams (Ex. India and US) are delivering to common stream, and dependencies are not managed correctly, the nightly build might fail. A “simple fix” in such situations can turn into 24-hour delay due to time zone changes.

In addition, isolation of build knowledge at single geographical site adds to the delay in generating timely build.

Here are some possible solutions…

In my opinion, enough investment should be made on hardware and the tools used for build environment. Future growth and needs of the product should be kept in mind while designing the build system to avoid future disruptions to the build system.

Sufficient investment should be made in people who understand build system so that issues like circular dependencies in the builds can be broken.

If need be, take hit on active development to split the serial execution of modules so that they can be run in parallel on separate hardware to speed up the overall build process.

Train and educate build personnel across each site to avoid single point of failures.

I have led some successful agile projects and have seen over and over again that by investing up front and taking control of build environment helps reduce overall build delay. By setting up build environment using continuous integration server like Hudson, and build tool like Maven, the development team gets continuous feedback on quality of their deliveries and helps scrum team self organize.

The question you should ask yourself is – should I spend time and money NOW to correct this problem, or am I willing to take a hit, and pay the price of not fixing it forever.

Have you ever faced such situations? How did you remedy it?

There is some good discussion on this thread at "ScrumDevelopment" forum.

http://groups.yahoo.com/group/scrumdevelopment/message/40744