On the XP list, Dominic Williams wrote in with:
I don’t want to give the impression of dodging your questions, so I’ll contribute what I can below. However, are you or your boss assuming that if XP or Agile has been done before in a similar company, it is somehow less risky for you to try, and you can apply some of the same recipes? I think those assumptions are very wrong. I don’t think you should even consider adopting a new methodology if you don’t want to take risks, and above all if you are not prepared to go through the difficult and long process of finding /your own way/ of doing agile development. Just slapping someone else’s XP or Agile onto your company won’t work.
This struck home with me. Lots of people I’ve run across, and several I’ve seen post to the XP and other lists, are looking for safe ways to do XP. “We don’t have enough time to do TDD.” “If the pairs just get stuck in a corner no one will learn anything.” Etc, etc.
XP, Extreme Programming, has a very intriguing word in it. No, not programming. Extreme. Extreme is defined as:
- Most remote in any direction; outermost or farthest: the extreme edge of the field.
- Being in or attaining the greatest or highest degree; very intense: extreme pleasure; extreme pain.
- Extending far beyond the norm: an extreme conservative. See synonyms at excessive.
- Of the greatest severity; drastic: took extreme measures to conserve fuel.
- Sports.
- Very dangerous or difficult: extreme rafting.
- Participating or tending to participate in a very dangerous or difficult sport: an extreme skier.
- Archaic. Final; last.
While the second one seems more related, I like the third definition. “Extending far beyond the norm.” Extreme programming to me is stating that you are tired of the norm, you want more, you want better.
Let me emphasize. You are tired of the norm. To be tired of the norm, and to go past that means going some place that most don’t or aren’t going. This means risk. You might find out your team can’t self-manage. That they cheat to get around the CI server by not checking in their code. That they have lots of tests like:
public void TestWidgetAInitializesWidgetB(){ Assert.IsTrue(true); }
So what’s on the other side? What do you see as the end goal for XP? It works best when you have a goal in mind. For example, at my work I see XP as helping to resolve central issues around project visibility and quality. We already deliver prototypes and build off of that (for good or bad), so short iterations isn’t as big of a concern to be.
I think about bungee jumping. First, you had the crazy people who tied cords to bridges and jumped. Then, you had others who saw that, but wanted to be more sure and so used really good cords. Others wanted to do it, but didn’t want to jump off a bridge. Next thing you know you have bungee jumping at a fair over a big inflatable cushion in case something happens. And if it does, you know a lawsuit is going to happen. People want the experience without the risk of blazing the trail to get it.
So, now it is rare to see much about bungee jumping. But people still are pushing it. Bungee jumping from hot air balloons. That kind of stuff. They keep growing, keep learning and keep taking risks to acheive that goal.
So what’s a company to do? You want better software, you hear about this XP thing being the wave of the future, but it all sounds so scary. No BDUF? Two week iterations? Pairs switching projects? Letting the customer be able to run any release?!
Start with your problem. Why aren’t you delivering better software giving more value to your customers? Poor software? Vague requirements? Changing requirements? Poor project management? In those cases look at the XP practices. Ask around. See what could help. Maybe TDD helps improve the quality of your code. Maybe a CI server resolves issues around deployments. Maybe planning games help smooth out the changes in requirements. Take a small risk, and work with it. Manage it. Box it in. Maybe try another. See how it goes.
Once you’ve done that, ask yourself, “Can we now make the jump?”. XP is as much about a culture change as it is process change. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Scary terms, ones that maybe your company doesn’t have the culture to do. If you can’t say, “This seems to be working, let’s do it” then I would say that you don’t have the culture to be an XP organization. And that’s not a bad thing, if it is working for you.
I live with the fact every day I’m not going to be an Extreme BMX guy. I admire those who do it, I try out bits and pieces (say, on a video game from the safety of my couch). But I know I’m not the kind of person who is going to do that. I still consider myself a good person. You can still consider your organization as a good organization.
We’re just not Extreme.