Ah, the Daily Build Revisited……

I just left the development team in Kyiv that I have been working with for the last six months. This is a new team, formed in only the last six months, building a large scale application (unfortunately, the project is in deep stealth mode, so the nature of the application will be “non-disclosed” for a bit longer). The agile master, (Alexander ,or Sasha ,to the team), was recruited specifically for his experience in agile development. None of the other members of the team had any prior agile experience but with Sasha in the lead and with some steady coaching from me, their agile prowess is pretty good (I’d give them four “bars” on the agile scale). Even though the application is fairly large in scope, the team runs weekly iterations. (Why, you might ask, given the steady recommendation in my book for a standard two-week length? The answer to that question will come in another posting).

Recently, we’ve been working hard on some of the “long poles in the agile tent”, most specifically completing functional testing within the iteration, splitting the team as it got to 14 members, etc, and I was fairly comfortable with their overall progress and we had settled into a fairly routine weekly cadence with Wednesday being demo day.

For entirely different purposes we had a consultant visit to look at some of the technical aspects of the application we were building. The consultant had 30 years of experience in building large scale systems, mostly by traditional process models. He understood a bit about agile and on the way in from the airport (Kyiv Borispol, Ukraine) he asked some basic questions about the team and their process. He immediately asked about the daily build process. Sasha noted that, while the team didn’t build daily, they could build on demand and would build once or twice per iteration and that was adequate. I didn’t say anything at all on the point. After a spirited defense of the ad hoc build by Sasha, the consultant seemed satisfied.  Sasha looked over at me and noted that I had pulled the hood on my parka down over my face. I suspect he understood the point.The next day Sasha I discussed some of the problems we had been having in testing certain modifications to essential algorithms that produced results that required review by the product owner (me, in the interim). Basically, we noted that we often had to put together a custom build at every point where we needed to test the new algorithms, and often that was a scramble and a delay of a few days to see results. (note to agilists of seniority: remember when seeing full results in 2-3 days was lightning fast?!) We also noted that we had spent significant time in reaching the demo state with Wednesday integration and demo preparation being a monumental weekly task, and that more than one iteration had failed to be successfully integrated in time for the weekly demo. After, a few more minutes of discussion, Sasha gave me the knowing look that said –it’s time–. So Sasha built a story in the next iteration to instigate the daily build 

When I think of the daily build, I’m reminded of the high bar that is set by the true agilists (See Chapter 14, Continuous Integration.) For example, Martin Fowler notes that he and other agilists have a pretty aggressive view about what makes a successful build:

l       All the latest source files are checked out of the configuration management system (including all scripts, config files, etc.).

l       Every file is compiled from scratch.

l       The resulting object files are linked and deployed for execution.

l       The development system is started, and a suite of tests (build verification tests) is run against the system.

l       If all these steps execute without error human intervention and every test passes, then we have a successful build. 

Reference: Fowler, Martin. 2006. http://www.martinfowler.com/articles/continuousIntegration.html. 

I promise to report back in a few weeks and let you know how it goes.