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:

• testing/refactoring. These go hand in hand. Test-driven development (TDD) is the most valuable programming practice I’ve ever come across. The value of test-after pales in light of test-first. Refactoring is extremely important in extending the potential lifetime of software product; it is only really possible if you are writing comprehensive tests. And it’s really only effective if you do it all the time, i.e. if you build it into your TDD cycle (test, code, refactor, repeat).

• constant planning. The problem with most projects is they attempt to plan once and assume they’re done with it. They spend a lot of time up front to come up with a date that everyone knows is bogus. XP takes the view that planning is good, but you really want to be planning and replanning all the time. Reality always intervenes with plans.

• pair programming. Take a look at the article on my site called “Pair Programming Observations.” It contains a lot more information that I won’t repeat here. When done well, pairing is a wonderfully enjoyable and productive practice.

Here are what I consider the cons of XP:

• As experience at IFC and elsewhere suggests, understanding and following through on quality design is essential. It is possible to depend upon “emergent design,” but if and only if you remain dogmatic about refactoring. A team needs at least a couple “refactoring zealots.” You have to eliminate duplication at all costs, and you have to ensure that the code remains expressive and clean. You have to write tests for everything. Tests are specs, and if you’re not going to write specs on paper, you have to write them in code. Write tests for everything, including exceptional conditions. Don’t write code unless there’s a test for it. Obviously you can’t test every possible condition, but you can at least test what you do know you have to code. 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.

• The temptation to let iteration deadlines slip is high. “Let’s just get that one more feature finished and then we’ll ship.” No. You have to learn to deal with deadlines in the small before you get anywhere near good at dealing with deadlines in the large. Management, unfortunately, has a hard time understanding this. So they slip. And then you lose all sorts of things, from consistency, trust, understanding of how to deliver product, and accuracy in estimates.

The pros:

• Done well, XP gets a team to gel more than anything.

• It builds true competency in all team members.

• It makes for an enjoyable and honest work day.

• It gets people out of their cubes and talking to one another.

• TDD teaches developers about how to write quality code and how to improve their notions of design; it helps them to improve estimates. It improves the resumes of developers.

• It gives management many tools, including predictability, flexibility of resources, consistency, and visibility into what’s really going on.

• It gives customers the ability to see whether or not a company can deliver on its promises.

• A personal favorite: you don’t spend a lot of time in stupid, wasteful meetings, and you don’t produce a lot of useless documents that no one reads and that aren’t trustworthy anyway.

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.

-Jeff-

Share your comment