This is probably my favorite story as it was one time when I actually got a little ahead of the industry.

After I had completed the initial delivery of the remote management libraries at PictureTel, the members of my team went back to the teams from which I had drawn them. Now on my own, I needed to extend the library to support a new videoconferencing system code-named "Beetle" being developed using Windows CE as its embedded platform.

The Beetle project was a massive exercise in big design up front, creeping features, and pushing more and more stuff into each build, resulting in a series of disastrous big-bang integrations. I knew that the first rule of management is "No surprises" and that managers would rather get a little less at a predictable rate than either a lot or nothing useful on a hit-or-miss basis. I wanted to isolate my component from the madness, delivering tested code with known features at a steady rate. I started with things I knew. I had learned the "next boat out of harbor" approach to software delivery between a component and a larger project at Digital. I had a repeatable build that ran from a simple batch command. I had written up a set of tests to execute before I delivered software. However, I needed more.

One day on the way to work I had a brainstorm. I was involved with earth-centered spirituality at the time and was thinking about how we model our lives. It occurred to me that, given the way that it develops from release to release, farming was really a much better model for what we do with software than manufacturing. That got me thinking about folk practices around farming, how farmers are attuned to the cycles of the sun and moon. As this flight of fancy continued, it developed into something that was crazy enough that it just might work.

By the time I arrived at the office I had the notion of delivering drops of my component with the new moon - coding on the waxing moon and testing on the waning moon. I could negotiate the deliverables for the next drop when the previous one is delivered, adjusting as the needs of the product changed. If something was harder than expected and plans needed adjusting, there'd be fair warning at least two weeks before delivery. If somebody wanted me to squeeze in one more feature "even if it isn't tested", I could simply say "in two days I deliver working code - you can have it in next month's drop".

Overall, the approach worked very well. I gained a lot of respect for delivering working software at predictable intervals. If anything didn't work as delivered, I improved my process so that similar problems wouldn't slip by me again. People quickly learned that by saying "No" to their last-minute requests I was doing them a favor, as the thing they needed would not slip indefinitely but be delivered as reliable code in the next month's drop.

As it turns out, this approach used many of the practices that were later to be identified with agile software development. I didn't know about unit test frameworks at the time. In early 1998, they hadn't been written yet or were just being written. I didn't know about some of the key techniques that were vital to effective automated unit test, like dependency inversion through the use of interfaces and factories. I learned about those a couple of years later and they addressed the few significant problems I experienced in implementing the approach. But most of the heart of agile development was there.