Position Paper for XP2002 Workshop: Experience Exchange II
Poole Consulting L.L.C.
20224 Pond View Lane NE
Poulsbo, WA 98370
In July of 2001, I spent three weeks trying to turn a project around. I had only recently learned about Extreme Programming and this was my first attempt at using it. The short-term results were quite spectacular, the long-term, less so.
The project manager had just left and a replacement was selected but not available for three weeks. I had been working as a lead responsible for one part of this project. With my group's work basically done, I was anxious to leave - I'm an independent consultant and value my time off. Asked to fill the project manager role temporarily, I agreed with the understanding that I might make changes in how the project operated.
I accepted this task as both a challenge and an opportunity to learn. I felt I could accomplish something in the short period but I wondered whether the changes I made would last.
We canceled the much-feared weekly meeting and replaced it with a Monday morning breakfast at which team members told what they expected to work on that week and what help they might need. We acquired extra machines for integration and a "war room" where we could display charts and diagrams.
I also set up a Wiki page describing what I was trying to do and ended up receiving helpful suggestions from many in the XP community. See ThreeWeekProjectTurnaround.
We arranged for an Onsite Customer who moved into the team area. The customer and two other team members formed a Requirements Coordination Group, which went through the backlog of unanswered questions and published the results on a web page.
The Planning Game identified stories previously unknown to the developers. We dropped lower priority stories and created a new release plan. The release date was farther out than management wanted but was accepted after some discussion.
We created a plan for the first iteration and began working on it. Those of us who had already begun to work with Unit Tests and Refactoring continued to do so. Some Pair Programming was practiced on a voluntary basis.
The third week of my three-week tenure was spent on firming up the practices used by the team and planning for continuity. We had started with practices that met our immediate needs. We were fully practicing Continuous Integration, Small Releases, Onsite Customer and the Planning Game. Our next emphasis was to spread Test Driven Development and Refactoring across the whole team. We were trying to introduce Common Code Ownership in spite of organizational and ego problems. In short, we needed enabling practices to allow us to continue what we had started.
Our fear was that the new manager wouldn't support this approach. In the team, we planned for continuing the growth of XP practices so long as they weren't explicitly forbidden. We discussed the need for someone to act as an evangelist. I lobbied management vigorously.
I maintained some contact with the team over the following months to find out how things turned out. The new manager didn't make much effort to learn about XP. However, the project was moving along well and she didn't interfere at first. During the next few months, the team continued with the practices we had introduced and added a few more. Iteration planning continued and estimates became more accurate. Tests were automated.
After a few months, the new manager began to change some of the practices. The onsite customer was reassigned and was only occasionally available to the team. Time spent writing tests was discouraged. The project progressed but at a slower rate. As formal testing approached, more shortcuts seem to have been taken. One team member describes it this way: "As we get closer to the end, management wants to sprint across the finish line." At the time of writing, the team was working to correct performance problems that arose in final testing. The product will ship - an outcome that was once in doubt - but the full promise of our initial experience using XP hasn't been fulfilled.