Transitioning To Extreme Programming

Posit a hypothetical developer (mathematicians may treat the developer as a point mass). She is using Case tools, has an investment in Rational Rose, drinks a steaming cup of waterfall methodology each morning, whatever ...

"Look," says the ExtremeGuru?. "I'm not saying you should abandon your beliefs without any empirical proof. And I realize that simply pointing at the ChryslerComprehensiveCompensation project is unconvincing. But if you adopt subset of the Extreme Practices, you'll see what we're talking about.

Questions: what is subset, what are its benefits, how hard is it for our developer to adopt this subset, how easy is it for her to grasp the rest of ExtremeProgramming from subset, and how convincing will subset be (obviously, extra credit for extra answers).

Straw Example:

Last night I gave a talk at a local developer group. And afterwards, someone was talking about how they are re-architecting a project. "Hey," I said. "You should check out JUnit. It makes things like that easier." And this morning I followed up by e-mailing some urls (pages on refactoring and JUnit).

Now, I'm not extreme (that's why this is a StrawExample?). But it's clear (????) that for ExtremeProgramming to conquer the universe and become all pervasive, some approach like this must be articulated, to make it easier for people to break away from their current practices and feel confident when doing so.

-- WilliamGrosso

Yup, just be careful you don't end up doing AlmostExtremeProgramming! -- AlistairCockburn

OK, William, time for some homework. Here's how to start working this out. Put down your list of our top eight or ten rules and how you think that rule would fit in to your project, how you would know whether it was helping, what it could replace if helping. Here's one example to get you started:

PairProgramming Experiment. (Assume the project uses code reviews.) Do some tasks with programmer A and B separately, some others with A and B together. Similarly with programmers C and D. In the reviews, count the issues raised on code written separately and together. Measure time from task start to tasks all reaching the same (high) level of quality as perceived by reviews. If total investment to quality is lower, keep doing PairProgramming. If review hits go down far enough, stop doing reviews.

Now you do a couple ... how could you check UnitTests, AcceptanceTests, customer direct contact, short increments? Planning? Reporting? C'mon you other XP questioners, help William out. How can he try it?

We have a communication breakdown here. The question "What do XP developers view as partial subsets that, if adopted, would help people evaluate/understand XP" is not identical to "What are the possible subsets of XP practices and how could we test whether adopting them would improve software practice."

Among the other aspects of the request for XP people to do this is they are better able to evaluate what the plausible / easily adoptable subsets of practices are. A naive counting algorithm yields that 10 practices implies 1024 possible such subsets. Experience leads me to believe that experts can probably rule out all but 5.

As an aside, I am neither hypothetical nor female (nor, for the mathematicians among us, spherical).

-- WilliamGrosso

I'm spherical but not female. And it's time for our sideline players to get more engaged. Get in the game. Think, put down some ideas, and let's work with them. -- RonJeffries

Why should I do that, you ask. Imagine that your company were wise enough to have an ExtremeMaster? come in and advise an experimental transition to XP. The answer wouldn't be to pull out the transition card and say "first this, then that". The XM would ask about your organization, how it works and so on. Now guess what - you know your organization almost perfectly, and you know more XP than you might care to admit to non-spherical females. That's why you should do that. Try it, we'll all learn something! -- RJ

I'm with Ron- I'm about to go on a week long answer strike, since you guys know the answers already. However, I will indulge one last time before zipping my lip and rolling up my newspaper. What if the subset were in time, not in practices? That is, what if you said, "We'll be extreme as best we understand it, but only for a week. Then we'll spend a day reflecting on what worked and what didn't, we'll post that to Wiki, then we'll go back to working as we were."? -- KentBeck

I will offer the VcapsProject as an example of one project working towards being Extreme. We have made good progress in the development area but still have a long way to go in the project management area. (-- Would be interesting to know what way the project management has to go? Or, what was missing? -- BasDeBaar)

What we did here was to examine what was hurting our project the most and try to fix it. In our case we had oodles of bugs. Many were of the type MessageNotUnderstood?. It was clear that automated testing would help that problem. It was irrelevant that testing was one of the cornerstones of XP. We wrote a few UnitTests and a few Acceptances and the bugs were reduced. Management resolved to continue the practice not knowing it was XP.

We then took another look at our problems. We found that integration was hurting us. Integration consisted of one person spending the entire weekend merging separate development paths together. We started using a SingleReleasePoint to solve that problem. Again the bugs dropped and both management and customers were delighted. And still no one even suspected XP was coming.

Now, I have no way of knowing what the biggest problem your project faces today is so I can not say what is right for you. But I have so much confidence in KentBeck's ExtremeProgramming methodology that I am willing to say no matter what your problem is there is a solution you can begin to apply now. Your problem might be turnover, obsolete documentation, customers who don't know what they want, or any number of things. Pick the biggest, the killer.

I will warn you that ExtremeProgramming is meant to work as a complete methodology. The different practices fit together like a jigsaw puzzle. There is no overlap and each piece is exactly the right size, no larger, no smaller. When you implement only one practice you will have to work at it. It will not make you go faster right away. That is the down side. But the up side is that if you can solve your biggest headache with a little more effort your management and customers will take notice and they will support you. They might even ask you "what do we do next". -- DonWells

[The above example was used to support the IdentifyTheWorstProblem pattern]

OK. You want to transition to XP. Why? Serious question: what are the things about XP that appeal to you? The answer to that will help make recommendations for how to transition. Thanks. -- rj

Ok, I've got a question that might focus the discussion. Since ProgrammingIsLife and life is programming (if you understand how), think of the project's process as a system that is flawed just like a computer program that is flawed. Now, how do you RefactorTheProcess? to improve it? If CodeSmells, ProcessSmells. AcceptanceTests are process metrics. etc. Is this getting meta-extreme? -- SunirShah

I don't think this is a helpful direction because people aren't computers. A software development process is not a set of instructions to be unambiguously interpreted. A development process is a totem to help keep you working your best even when you are afraid, and to help you learn to work even better. -- KentBeck (I could be wrong on the "not helpful" part. The rest of it I'm fairly sure of.)

I think it's still sound. You can put the process into a feedback cycle that allows you to learn and adapt and consequently optimize the process. How else would you know whether or not a process is better than another or what to change to improve your process? -- ss

My own experiences in this area are in MigrationToXp. -- RichardDevelyn

See AdoptingXpPatternLanguage, ExtremeProgrammingEnablingChart

CategoryAdoptingXp