It all started with a phone call. Would I please come have a look at the performance of a payroll system Chrysler was putting together? I had written and lectured on Smalltalk performance tuning, so I wasn't surprised to get such a call. I was a bit surprised at the answers to some of my screening questions. One in particular caught my ear:
"Do you have tests so I can be sure I don't break anything with the changes I make?"
"We aren't actually computing the right answers yet."
If I don't have to compute the right answers I can make a system go as fast as you want. I had done enough consulting to smell a bigger problem than merely performance tuning. Since I was curious, I decided to go.
I arrived on Shrove Tuesday, 1996 (around Easter). I can remember the date so precisely because the team and I had paczkis (pronounced "punchkeys"), a Polish jelly donut that is only baked on Shrove Tuesday.
I quickly spotted the signs of a project in trouble:
They had been two months away from going into production for five months.
People looked to see who was listening before answering my questions, a sign that they were protecting themselves from their teammates.
People were obviously tired and snappish.
As so often happens in consulting, the client already knew the answer. Part of my job as a consultant is to find the person with the knowledge and convey that knowledge to the person with the power. Over coffee the first morning, someone said, "If only we could wipe the hard disks, we could do this project." Everyone laughed nervously at the thought of throwing away all the code when they were only two months from deployment.
Two days later I was in a meeting with the CIO of Chrysler. I gave her three options: continue the current course and never really be sure when the software would be ready to deploy, cancel the project outright and lose all the expertise, or start over from scratch with a smaller team. She chose to start over with my involvement.
Successfully making a big change requires many components. Luck is one of them. When I got home I had an email from Ron Jeffries saying, "I need a job. Can you call me at 810.555.1234."
I called and said, "Please tell me 810 is a Detroit area code."
"Ann Arbor, but that's close enough."
That is how Ron became the first full-time XP coach.
Martin Fowler had been consulting with the project on analysis issues. I grabbed onto him to help with analysis and testing, knowing he would keep a level head even when we were trying new software development ideas. Finally, I had management support and a team willing to stick with a development style that would be uncomfortable at first.
Two weeks later I was back to kick off the project. I decided the first thing to do was to interview each member of the (shrunken) team. I wanted to know what they thought they could do to help. I started with Bob Coe, the project manager. After the initial chat, he asked, "So, how is the project going to work?"
This was the question I had been preparing for but dreading, because I didn't know exactly what I was going to say. I launched in. "We'll have these uh...uh... three-week uh...uh... iterations. In each iteration we'll imple ment some uh...uh... stories, which Marie [our payroll expert] will pick. We'll estimate the stories and figure out how many can fit into each iteration. We'll count the iterations and that will give us the length of the whole schedule."
"Sounds like that should work."
At the next interview, I said, "So we have these three-week iterations, each of which contains some stories. We'll make sure we have the stories in the uh...uh... first iteration so we can print one real paycheck correctly." And on and on through the day, each time becoming more comfortable with the project structure and each time adding a little more detail.
My goal in laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10. We would do everything that was absolutely necessary as intensely as we could imagine and we would ignore everything else. If it turned out we needed to do more, we would add that in later.
At the end of the day, I had laid out the basics of XP: an always- deployable system to which features, chosen by the customer, are added and automatically tested on a fixed heartbeat. It took experience to find out that what I thought was 10 on the dial was actually only 8 or 6.
I say "basics" because the team there did the work of applying those abstract concepts to a real project. There were procedures to work out, tools to write, skills to learn, and relationships to create and deepen. I gave them a vision of how to develop software differently. They actually developed the software that way and better.
Our first task was to estimate how long the project would take to complete. The team wrote and estimated stories. We had a day-long planning meeting at which we reviewed all the stories. Our customer picked the minimal functionality for a first deployment. Then we added up the estimates and presented the date to top managers from IT and the sponsoring organization. At the end of the day one of the programmers told me, "This is the first estimate I've ever seen that I actually believed." Then the team started implementing stories, three weeks at a time.
The team was humming and I was overly confident. I was sure we could always deliver on time by negotiating scope. However, there are no guarantees in software development. One incident in particular sticks in my mind. I was absolutely certain that by dividing the system into features and giving control of the features to the customer, our software would always be deployed on time. I had bet a bundle on getting our system into production on time (January 1997). Come the middle of November it was clear that we weren't going to make it. We were calculating the payroll numbers well enough, but they weren't showing up correctly in the output files. Our tests only went as far as the numbers. There was more work to be done to correctly export the results. (This disaster gave rise to the saying "End-to-end is further than you think".)
I would like to say I handled the situation well. I didn't. I panicked. I tried to get the team to agree to cram all the remaining work into the available time. It was Chet Hendrickson who brought me up short with his drawled, "Every other time we've had to estimate a completion date we've estimated the pieces and added them up. What's different about this situation?"
I was worried about my bonus, but I was also worried about my dream of never having to deploy late again. The situation worked out okay. We were certified in March and went live in April.
The system was in production for three years, being decommissioned in 2000. The two issues leading to its termination were technology and funding. By 2000, Java, not Smalltalk, was clearly the dominant object technology. Chrysler didn't want to maintain a system in a little-used language indefinitely. They were already in that situation with another system and it was awkward and expensive. The project had been funded by IT as a pilot in using object technology. IT asked Finance to pay for later phases. Finance refused. The project was cancelled.
The system was reliable, cheap, and easy to maintain and extend. The architecture stayed fluid and appropriate. The defect rate was incredibly low compared with similar projects. The team made it easy to welcome new members and the departure of team members made proportionate impact on the team's effectiveness. The project was a technical success to the end.
The project was also a business success. It proved that object technology was appropriate for large-scale data processing projects. Then the business needs changed. Politically controlled funding pays for software development. Software development funding priorities change rapidly with the shifts in technology and business practices.
This is my story of the beginnings of XP. Since then, much thought and work by many teams have gone into the refinement of the ideas and explorations of the relationship between values, principles, and practices in XP.
No comments:
Post a Comment
Your comments are welcome!