- Consulting / Coaching
- Jeff’s Blog
A colleague in a graduate degree program recently posed a question to me on email:
> We’ve had quite a bit of eXtreme Programming discussion this week in my
> Software Processes class. Unfortunately, none of us have actually been
> involved in a real, live XP project. I’ve tried to defend it, but my XP
> background is pretty weak.
> I know you’ve been involved in a lot of XP work. Can you give me some info on
> what type of projects you’ve worked on, how successful they were, and what
> you think the pros and cons of XP are? If you don’t mind I’d like to quote
> you a bit in our online class discussion as someone who has really been in
> the XP trenches.
My response, with some name changes to protect the “innocent” and some additional cleanup, follows.
In general, the XP projects I’ve worked on were slightly more successful than the non-XP projects. I’ve probably coached 20 teams; this includes a mixture of small teams (2-4 people), lots of medium-sized teams (6-12), and a few large ones (18+). Some of the shop types included government, retail, airline industry, grocery, financial, telecommunications; everything was all over the map.
Prior to XP, I did lots of waterfall-based development at places like MCI, Marriott, and ChannelPoint [a failed Colorado Springs dot-com]; I also worked in a number of smaller shops where some flavor of waterfall was in place. I also did some spiral development at MCI, and I’ve consulted in a couple of shops where they had some implementation of RUP.
The most extensive XP effort I had experience on was with [a grocery chain I’ll refer to as IFC] in Texas, where I was initially in the trenches doing paired development. About two months after starting the contract I ended up running a short-term subproject to develop an offline solution for their pharmaceutical processing system.
The IFC effort was a good example of both success and failure in XP. Using test-driven development (TDD), the development team had managed to build a significant amount of reasonable quality production code within a short period of time. They reported a very low number of defects. The code had an extensive body of tests. The IFC team had an open environment and mandated pairing. However, there were a number of XP practices that the team did not follow. Specifically, they did not adhere to fixed-length iterations, and their planning was somewhat ad hoc; also, they did not refactor as much as necessary.
The upshoot was that at some point after I joined, they were unable to sustain reasonable delivery periods, partly due to some network dependency issues that exacerbated poor design in the code. Making changes to the code base was difficult, since the tests were overly dependent upon the implementation (they abused mocks). However, they were able to make a significant number of changes and improvements rapidly, since they had tests in the first place. Management insisted we develop an offline solution.
The offline solution I directed as coach/tead lead was to me a testament of the value of XP. In a matter of 8 weeks, we built a complete and successfully deployed solution that allowed offline pharmaceutical fills. As a coach with full ability to direct the XP team as I wanted, I took a number of “lesser” developers and showed them how to adhere to the simple rules that they had neglected over time: fixed iterations with simple but comprehensive plans, and hardcore as-you-go refactoring. The “senior” guys (including some expensive Vitria BusinessWare consultants) were left alone to solve the stability problems; they floundered and ultimately failed. My mostly junior team learned how to trust each other as a team (despite some early ugliness) and enjoyed working together. They also saw success and progress on a two-week basis.
I’ve seen many similar examples. At [a failed dot-com in Orange County], the development team continued to enjoy working on and delivering product while the walls and rest of the company crumbled around them due to a bad business model. At [a large company in Dallas], I worked with a number of different teams on a short-term basis; some of the teams had abysmal performance while others delivered spectacularly to expectation. The differences often could be attributed to adherence to practices.
The teams that took the values to heart and believed in what they were trying to do were successful. The teams who resisted and thought they were too smart for anyone else’s ideas on how to build things failed. Ultimately you could say this about most processes, not just XP. The best thing you can do is to get a team to gel: to learn how to communicate well and to trust each other. This means trusting each other enough to say when things aren’t going the right way. Or to speak up when something seems like it’s a waste of time (e.g. attending meetings where little is accomplished).
I believe XP promotes these values. If you want to talk specifics, the main value that I get out of XP practices boils down to three things:
Here are what I consider the cons of XP:
The con here is that this is very hard to do. It requires a good coach to initiate and ingrain the rules into peoples’ heads. And it requires the people within the team to care enough to not let things get sour. Unfortunately, it’s almost impossible to get a team to be that meticulous. In retrospect, I’ve learned to invest just a small bit more of time up front in doing design. However, I temper that by ensuring everyone is fully aware that the initial design is a road map; reality will always take you on detours that end up redrawing your TripTik.
With respect to TDD, the Jerry Jackson story about TDD is always good. I don’t remember if you’d ever met him while at ChannelPoint. He was one of the first authors of Java books; his book Java By Example was the fourth ever published on the Java language. I hadn’t seen him in a while; two years ago I met him in the fall while at Tim’s chess tournament. He said that he’d read a bit about TDD but hadn’t tried it yet, and that he was going to look into it. I saw him again about three months later, at another tournament. Before I could say anything to him, he walked up with his face lit up and said something like, “That TDD stuff is amazing!” This is the testament I get from anyone who’s given TDD an honest try. They all say similar things, about how cool it is and about how much it’s taught them about their coding and their design. Jerry now works at Cassatt; apparently they are all doing TDD (and a lot of their technique and inspiration is based off a paper I wrote for OOPSLA 2001).
Oh yeah… if you’re going to do XP, or RUP, or Scrum, or Crystal: Hire a process coach! It’s easy to screw any of them up. You would never field a football team without a coach, even if all of the guys had played before. It seems ludicrous that we slog away at building software, spending millions of bucks, without someone to make sure the process and techniques make sense.
I hope this helps.