An Extreme Fifteen — Part 3
Well, it can’t get any worse.
Such were the high aspirations of our manager when the new team leader and I presented him with the proposal of using Extreme Programming. It was mid-September 2001, shortly after I left the contract that had switched from building a large Java system to a COTS RFP.
The system on which this new group worked had been in production since 1998, and a release was being rolled out to production when I arrived several weeks earlier. For this project, the development and customer teams were colocated, and the customer was already in charge of creating and managing the requirements. This showed promise for being an agile environment!
At the time, though, it was anything but agile. Everyone was scurrying about in the usual panic to fix last-minute problems in order to get the release out the door. The system did ship, but it was owing to the heroics of a few. It seemed like just another day in the IT trenches.
I didn’t find out until later that the team leader who was in place when I started was something of a control freak who insisted that he do all the analysis and simply generated specifications for the developers. To his credit the design of the system was reasonably good, however there was a terrible communications gap between the developers and the business people. The customer never saw the system until it went into user testing after a 6 to 8 month development cycle (even screen shots were embargoed because they “might change”), and the developers weren’t privy to many issues brought up at weekly status meetings, which only the team leader attended.
A few weeks after I arrived, that team moved on to another organization and was replaced, purely by chance, by an old friend of mine. The new team leader was the wife of my manager from 1992–1996… the same manager who insisted that the whole development team be moved to the same physical location as the people who would be using the software we produced. At any rate, the new leader and I had known each other for almost 10 years and she already trusted my judgment.
I wrote a document (of which I’m still rather proud, if that can be said about a document) providing an overview of XP and how it fit into the team and the work we were doing. I sent it to the team lead and we talked about it a couple of days later. She was very receptive to this fresh, new approach!
I’m tired of telling teams to do things that I know don’t work.
She had been working for a number of years in the organization’s Project Management Office (PMO), providing guidance on and, to an extent, enforcement of the organizational standards for projects. Her disillusionment with enforcing processes she knew were at best suboptimal led her to seek her new role as the team lead on our project.
Together we decided to pitch the idea to our manager. Again, we sent the document, and scheduled a chat for a few days later. He, too, was receptive, albeit from a more cynical perspective. He did say, though, that the business people had for many months been asking for the level of collaboration inherent to XP. So, he gave us his blessing to talk to the customer about trying out XP.
That pitch was the easiest. I believe we had the business manager at, “the business and development people would be working together on a daily basis”. Everything after that was just icing on the cake. If dissatisfaction with the status quo is a key ingredient in any change process, we had it in spades. No one was happy with how things had gone and everyone was open to trying a new way. And new it was!
The very first suggestion I made was to open the weekly meeting up to everyone. I happened to sit near the wall of the boardroom in which these meetings took place. I heard the adversarial style of the sessions, mainly because of the yelling that was involved. So, there weren’t many people who were all that enthusiastic about joining a meeting that they already knew wasn’t much fun. I asked for a suspension of disbelief, which was obliged, and the meetings now included the whole team.
Since a release had just gone out and the various post-release issues had been dealt with, we did release planning. Again, the whole team — development and business — was involved. While we didn’t use Stories, the individual requirements were of a nature that it was quite easy to know when they were “done”. We did a finger in the wind guess of how many stories we could complete in an iteration, mapped out the release and away we went.
This system was built with the client-server tool PowerBuilder, which didn’t have the same capability as Java for unit testing. What we were able to do, though, was find a place in the software that allowed us to “inject” values, run the processes on them, and inspect the outputs. So, we built our own testing framework and allowed us to use a test-first approach. It worked wonderfully, and we were ahead of schedule before the end of the first iteration.
Part way into iteration two we were even further ahead of schedule. Our customer was away at an external site, meeting with the vendor who supplied data for the system. I had just committed a relatively large chunk of work into source control when I received a phone call from the Customer:
Customer: Have you done any work yet on Feature X?
Me: Uh, yeah… I just checked it in.
Customer: Oh. That’s bad.
Customer: We were totally wrong about we thought had to be done for it!
Me: Um, OK. I can pull it back out.
Customer. Good. Let’s talk tomorrow when I get back.
The customer returned the next day and we looked at the changes. The work that we had done on the feature to that point had to be tossed. So, we updated the tests to reflect what the customer had learned and restarted the work. Since we were already moving faster than anticipated we finished the iteration with all the expected work completed.
We continued to be ahead of where we expected to be, which allowed the customer to bring more stories into the release. In each iteration the work was being tested as soon as it was ready. Our weekly team meetings moved from reluctant participation to an anticipated social event! The group as a whole was working really well together.
The final little nugget was that the customer had scheduled four weeks of acceptance testing, despite my suggestion that it be shortened due to the ongoing testing effort. That was one leap of faith that the customer wasn’t prepared to make, so I relented.
The acceptance testing process was completed in about a third of the allotted time with only 3 or 4 minor defects reported. The customer decided to add on Windows 2000 compatibility testing, and the entire system was tested and ready to ship 10 days early! Due to the significant database migration effort required, we waited until the release date scheduled some 5 months before and deployed the system.
In the space of 6 months the group had gone from a last minute bug fix panic after a closed, adversarial development process to a seamless, defect free release from a whole team that enjoyed working together. The customer was, to use the term that popular now, delighted. Both the business and technical people on the development team were delighted.
After the pain I had experienced in that large project with the large team with large requirements, this was incredibly liberating! My feeling that XP was a great way to deliver software was borne out in practice. While the development was going on, I was absorbing as much information on Extreme Programming as I possibly could.
I joined and participated in the XP mailing list, soaking up information from its creators and other practitioners. Kent Beck, Ron Jeffries, Martin Fowler, Ward Cunningham, Bob Martin, Alistair Cockburn, Grady Booch and many others were more than gracious with their time and patience with myself and the others who were jumping onto the XP bandwagon. I was, what I refer to now, a second generation agilist — someone who learned from the originators and mostly understood their original intents. If I didn’t understand something, I simply asked and received an answer. I rarely had to provide my own interpretation of what something meant… Continuous Integration wasn’t “an automated build”, it meant to integrate your completed, tested code into source control as often as you possibly could, certainly at least once per day. Test-Driven Development wasn’t “write some unit tests after you write the code”, it was driving the design of the code using examples in the form of unit tests. Pair Programming wasn’t “have someone look over your shoulder criticizing your code”, it was immersed, interactive collaboration around building code that had the nice side effect of providing a real-time code review.
Overnight, it seemed, I had become interested in software process… well, OK, this particular software process! Not only that, I had helped lead the team I had worked with through the Extreme Programming experiment acting in the unofficial Coach role.
It was, as Frans Johannson described, a Click Moment.
I suddenly saw where my career should go next. I could still build software, but coaching people in the use of Extreme Programming and the nascent Agile movement sounded much more interesting. In addition, it sounded like a really good business to get into, given that I was there essentially on the ground floor!
I immediately started to look for ways to raise my profile with respect to the XP world. I found out that there were several other people in my area who were interested in XP, and I co-founded XP Ottawa with them in mid-2002. On the mailing list I asked and answered questions. I combed the web for articles on XP, and commented frequently. I was like a toddler, continually asking why in order to keep the conversation going and soak up more information!
I had found out what I wanted to be when I grew up.