Why did I go Agile? Part One: An Open Mind
I've recently been called a fanatic, crazy, insane, and a zealot about all this agile stuff. This really startled me and made me think about how I come across and how I talk about agile. This has not made me change anything about what I do, what I say, or what I believe. However, I do want to share why I decided to "go agile," and the road that led to me becoming an agile evangelist.
This will actually become a series of five (or maybe six) posts. Today will be the background on why my mind was open to new ideas. In future installments, I'll also talk about what sold me on TDD, Scrum, Pairing, and Team Spaces.
Why did I go Agile?
A few years ago, I was part of a development team in MSN, and I was finishing up a death march project. A few months before the project was supposed to ship, the development team was cut by 80% (from 5 to 1) and the release date stayed the same. However, I (being the only developer left) was able to negotiate a few changes to the feature set, reducing it by a whopping 10%, which was a miracle in and of itself. I explained that I was being asked to do the impossible and argued forcefully for more time or resources, but I was overruled. I ended up delivering about 1 or 2 weeks late, but I was burnt out. By burnt out, I mean exhausted, tired of looking at computers, and tired of 100-120 hour work weeks. The project was a success, as far as management was concerned. I considered it a failure.
I was immediately pulled into another project as a firefighter. This other project had major performance issues, and I was given two weeks to fix it. This was a great break from the 12-15 hour days I had been doing. It was almost like a vacation, but not quite, since there was still pressure to find solutions immediately. I was able to fix a number of the problems they encountered and provide a course of action to follow to stop the issues from reappearing. I cut application load times by 50%, and increased performance by 50%. A good few weeks of work.
I moved onto another project for a grand total of two weeks to help them solve some performance issues that were being seen on another tool, this one used by customer service agents. This was a great break from the 12-15 hour days I had been doing. It was almost like a vacation, but not quite, since there was still pressure to find solutions immediately (if not sooner). I was able to fix a number of the problems they encountered and provide a course of action to follow to stop the issues from reappearing.
After this brief bout as a firefighter, I was put on another project that was under a very tight deadline and looked like it would be another death-march. This was based on previous experience in the group, the schedule that we were given, and management's comments that this software "must ship on time" for strategic business reasons.
Needless to say, at this point I was ready for a change. Any change! And there was one thing that I could control and change myself without letting anyone know. I could change how I wrote software and try out TDD.
