Agile Changed My Life (Twice)

In 1999, while I was at Evity, we used many agile techniques. Daily stand-ups. Developing incrementally. Two week iterations. Testing within the iteration. A prioritized backlog. Retrospectives. We even took releasable to the extreme. We released every two weeks (it was a hosted service). This approach was very successful. Within 4 months, we had a beta version of our software. Within 6 months, it was generally available. Within 10 months, we were acquired by BMC Software.

After being acquired, we slowly adapted to the mainstream approach at BMC: Waterfall. We went to longer and longer releases. We began doing requirements documents and functional specifications. We started doing big things (not incremental). We started testing the quality in at the end. It was analogous to the frog in the pot of water. If you raise the temperature of the water gradually, the frog won’t jump out. Eventually the frog dies. We were the frog.

Something happened before we died. In 2004, Israel Gat joined BMC. He was a big proponent of Agile development. But, he didn’t push it on any of us. He encouraged us and supported us in adopting as we saw fit.

We then started a large scale project. We were to bring together the lightweight PATROL Express (remote monitoring) with the more robust PATROL (agent based monitoring) into a single solution: BMC Performance Manager. The issue was that the two were very distinct architecturally and in their capabilities (though they were fundamentally trying to solve similar problems in complementary ways). We could easily have spent two to three years developing a first version only to realize that we missed the mark. We realized that we needed to do it in a way that kept us focused on the most important aspects and let us get lots of feedback as we were going along. Agile seemed the way to go. In retrospect, I can’t see how we would have been successful otherwise.

It was a breath of fresh air. We no longer got mired in the details / debates that in the end didn’t matter. We focused on what was truly important: working software, not specifications. We started working better as a team. And eventually, better as a business unit.

We began using agile on a few of the core teams. We started expanding to more and more. BMC Performance Manager is entirely agile at this point. Service Impact and Event Management (the group I’m in now) is getting there. Agile is like a virus (in a positive way). It has taken root in BMC and we’re seeing a lot of benefits in our ability to put out powerful new features with much higher quality (see http://biz.yahoo.com/bw/070910/20070910005634.html?.v=1 for some recent press on the subject).

My goal with this blog is to share some of the things that we picked up along the way (and the things that we’re still picking up as we expand its usage and take it even further).

Walter