Skip to main content

Principles of Extreme Programming

Posted by thedarksavant on November 7, 2003 at 8:58 AM PST

Most debates about XP revolve around a certain practice. Pair programming gets the most abuse, but many others take heat as well. It's time we transcended the practices and starting talking about the principles. But what are they?

Womack and Jones opened my eyes in Lean Thinking to the fact that practices don't map from project to project. They discovered after their landmark book The Machine That Changed The World that manufacturing companies were having little or no success implementing Lean Manufacturing even though the company embraced and believed it. The problem was that the companies were trying to map the practices that Toyota used to their particular manufacturing process. This doesn't work. The principles of lean manufacturing are constant, so you take the principles and adopt your own practices, possibly from a list which includes practices known to work.

We've all heard the story of the development team that adopted XP and failed. Then they tell us that XP doesn't work. The stock response usually is "Tell me about how you implemented the practices and we'll try to discover what went wrong." That doesn't usually work either. What went wrong was that the team tried to map the practices to their team. I've done this and it has worked brilliantly. I've done this and it has failed miserably. When it didn't work it was very frustrating because I believed that the practices should work all the time for every team in every situation. Today I know better.

Kent Beck and Ron Jefferies have both said many times that to get the most out of XP you need to do all the practices all the time because they support each other. I do not recall either of them ever saying that you must do all the practices all the time to succeed, but doing all the practices all the time gives you the best chance for success. They suggest you do all the practices all the time then fix XP when it breaks or in other words, change the things that are not working. I've done this as well and it has worked, but I've had the most difficulty getting all the practices to happen all together all the time. when this happened I'd get frustrated and push back. Of course, the harder I'd push, the harder the team would push back until it fragmented into a worthless group of individual developers or coalesced into a team willing to do the practices they believed provided the most value. In the latter cases we successfully built software at great speeds. In the former cases we failed.

I propose a different approach to bringing XP to an organization. I propose we offer the principles of lean software development put forth by Mary Poppendieck and Tom Poppendieck.

  • Eliminate waste.
  • Amplify learning.
  • Decide as late as possible.
  • Deliver as fast as possible.
  • Empower the team.
  • Build integrity in.
  • See the whole

Find out which of the above principles the team and company find the most value in then suggest
the XP practice that enables adherence to the principle. For example, if the team decides that if they do nothing else, they must build integrity in, then introduce them to test driven development, continuous code improvement, onsite customer, simplicity, and perhaps even metaphor. But the beauty of this approach is that you can ask the team to decide how to enable the principles. When it's their vision on how to make sure that the product has built in integrity, then you get more buy in to the process. Chances may be that they come up with the same practices that XP would have, but since it is their idea, they are more willing to do it. And they may even come up with better practices that no one ever thought of before. Then you can write a book and become rich and famous.

Related Topics >>