Starting With Extreme Programming

Suppose I'm starting work on a new project with a new team. I want to use ExtremeProgramming so where do I start?

My vote would be PairProgramming and 100% UnitTests as 2 of the first things to install. RobMee can say what he set up first, maybe (hint, hint, Rob). He told me they write unit tests first, then program in the simplest thing and make sure all tests still run when they go home at night. -- AlistairCockburn

What will it take to put in place the tools to support ContinuousIntegration? You'll need to be able to work on code without "reserving" it first (the way you can edit a Wiki page), and to fold in all the changes others have made since you got your snapshot. CVS (see ConcurrentVersionsSystem) can do this; there's a version available for NT, plus GUI front ends. I don't think SourceSafe will cut it, but that might be ignorance. -- PaulChisholm

I'm no great fan of SourceSafe, but I think it's up to this task. Just make sure you enable multiple checkouts. Actually, if you're using VC/VJ and you use the built-in source control, it should work pretty well. -- CurtisBartley

SourceSafe is a reservation-based tool too -- not appropriate for this task. What you really need is some efficient way to determine exactly what your pair changed -- so you can reproduce the changes on the integration machine. The "branching" multiple-checkout feature of SourceSafe or CVS might be able to help you with this -- maybe. -- JeffGrigg (a regular SourceSafe user, but not an ExtremeProgrammer)

Do the Chrysler C3 people have any comments about this?

Start with the PlanningGame. If you don't have the stories, or at least the beginning of the stories, you risk wasting lots of time solving problems that aren't problems. I ask this question a hundred time to a new XP team, "What story are you working on?" Generally the answer is, "Well, none, it just sort of seemed that this stuff needed some work." -- KentBeck

And testing. With testing you can know when you're done, and you can go faster. So focus in on exactly what you do have to do (and don't have to do) with PlanningGame. Then do it (simply, of course) with lots of testing built by the developer, as you go, preferably before the code that's being tested. -- RonJeffries. (who is such a RecentChanges junkie he forgot to come back.)

The company is strongly resisting the idea of PairProgramming -- as wasteful. The developers don't want to UnitTest. They aren't writing UnitTests before coding. They reluctantly write them at the end -- if at all. The developers are even fighting the notion of StandupMeeting. It seems hopeless! -- AnonymousDonor

Possibly both PairProgramming and UnitTests should be tried "as experiments" for a week or so. PairProgramming IMO is not essential to XP (just very valuable). UnitTests, however, are core.

Remember there was an article in Communications of the ACM a few months back talking where the guy did an experiment on pair programming. I don't have the exact reference here (but I think it is somewhere here on wiki). Might be worth a look.

One thing I've noticed here ... the harder you push, the more people (I'm not naming any names here) push back. Don't kill yourself, it hurts and won't help. OnlySayThingsThatCanBeHeard is good advice. (Yes, world, I knew it was good advice. ;-> )

How can we help? -- RonJeffries

Please keep this page alive with insights and challenges. I wish *I* had a 3-person team and a new project.

Obviously, PairProgramming and UnitTests first are the two hardest sells, with coding convention buy-in being the third. I would definitely get a 3-week commitment from the team for all three of these with a simple "Try it, please, trust me, it'll be fun." In fact, whenever I pitch XP-like practices, I speak first and foremost to simple joy: Programming is fun. Shipping product on time and under budget is fun. Wrestling control away from paper-intensive methods is fun. Giving business business decisions and developers developer decisions is fun. So very many programmers have lost touch with the initial spark of joy that got them sucked into this business. Focus on bringing it back!

Good luck and keep us posted!! -- MichaelHill

If possible, find a "corner" of the software that someone can do from the ground up with UnitTests and pick two developers to try it. Give them the opportunity to get bitten by the bug and let it spread from there. If a pair isn't possible, go with one to get UnitTests rolling. If you can't go ground up with UnitTests, find the best niche to add them after the fact. If you're getting a lot resistance, I think the key is growing the interest from a few people. -- KielHodges

Here are some common problems...

...and suggestions on how to resolve them.

A programmer writes lots of code -- no comments, bad variable names, not modular, etc, etc, etc... Programmer resists Refactoring, and in CodeReview insists that putting in comments would add weeks/months to the project. How can we get him to do what we want without hurting him?

"That's right, Jack, no one wants lots of documentation. The way to be sure we don't have to do it is to make sure that all code is readable. Let's start with this code here. Arthur, why don't you sit down with Jack and the listing and re-enter this to make it readable."

Programmer resists writing UnitTests until after writing the code; or tries to avoid UnitTests altogether. Q: A UnitTest is done in code, not on paper, right?

"Right on, Jack, on the UnitTest. Let's get it in the system. Then when you and Arthur re-enter the code to make it readable, we can just run your test to be sure everything is covered."

PairProgramming is viewed as a waste no matter how much I try to sell it. The overall Project Manager and for the most part the company do everything by this linear schedule and all project members are already "heavily scheduled." How would they schedule it? Why take two people to do what one could? It's hard to get the idea of "collective code ownership" going.

Don't call it pair programming. Just start helping people. Just start asking for help. Start suggesting that Billie help Jamie on this or that. See what happens. No one can reasonably object to people helping people.

I'm glad you're excited. I'm not surprised they push back, considering how hard certain people have pushed back here. Let them taste it. Maybe they'll like it. Expect adoption to be incremental. When things are a bit off, point out that they're a bit off, ask the group what to do. Suggest trying X to see how it works.

Don't become strident. It seems not to work, in my frequent experience.

Ward, advise us.

I thought I would give this a shot. XP can be broken up into a lot of pieces. Others have written about the importance of testing, pair programming, and project planning. These things are important parts of XP, but imposing them onto a project will not make it Extreme. C3 chose to follow Kent's process as a team. We interviewed and hired RonJeffries, because we knew we needed full time help making the transition to this new development style. Ron works for the C3 team; he stands a step outside of the development process, watching what we do and how we do it. He has no authority beyond our willingness to follow his advice. We all refer to him as C3's coach, but he is not a coach in the Vince Lombardi sense. We follow him because we decided to follow him. So, after all of this, my point is - my answer to 'how do I start with Extreme Programming' is You have to get all of the members of the team to want to do XP.

The developers have to be willing to give up their egos, they must be willing to hang up their ten-gallon hats and spurs and become object engineers. At first, they may think they are giving up a lot, but they will soon rediscover why they became programmers. Writing code that you know works, on a project you know will succeed, with a customer that trusts you, for a management that believes you, is so much fun that you feel like a thief on payday.

IT management has to be willing to give you the benefit of the doubt. Our deal with our management was that every 3 weeks we would prove that what we were doing works. If we couldn't prove it, they were to pull the plug on our project. XP will provide you with the proof that it works.

The customers must be willing to place knowledgeable people on the team full time, to write stories, to construct functional tests, and to participate in project scheduling.

So how do you do this? There are two ways, if your team is onboard, you could just start doing it, trusting that management and the customers will sign on after they see how well it works. I don't believe this strategy will get you to a fully Extreme point. I believe you need to get IT management familiar enough with XP to see that it delivers quality software in a predictable manner. I believe you need to get your customers familiar enough with XP to see that it will deliver software that meets their needs, even if those needs change during the project. I believe you need to get your developers familiar enough with XP to see that it will make the project the most fun they have ever had at work. You can find most of the resources you need to do these things here on Wiki and on RonJeffries' web site.

-- ChetHendrickson

The customers must be willing to place knowledgeable people on the team full time, to write stories, to construct FunctionalTests, and to participate in project scheduling.

I find this to be a bigger stumbling block than UnitTests or PairProgramming. Our customers are used to the "waterfall" approach where they give you requirements, you develop software and they check it out when you are all done. When we approach a customer about having one more people on the team fulltime, we are met with comments like "but these people have full time jobs, we can't tie them up full time on a development project". Given that XP is a relatively new approach to development and therefore lacks many projects which can be pointed to as XP successes, how should one go about convincing the customer that it is in their best interest to have one or more knowledgeable people dedicated to the project? -- JimHowe

If your customers are not willing to join the team, I don't think you can do full XP. So how do you get them to see the light? We do XP because our customers want its benefits and saw that they were not able to get the software they needed, when they needed it, without XP. Demonstrating to customers that this will be true for them is a very local problem If your customers are happy with the waterfall approach, then it may not be possible to convince them to try something new. If they would like software delivered quicker, with a higher confidence that it will meet their needs, you should be able to get them to come to the table. If they want the benefits of XP with none of the costs, then you are in a no win situation anyway and it might be in your best interest to try somewhere else. -- ChetHendrickson

If the customers are not willing to join the team, I wonder how you can be sure you are delivering the correct system without a lot of thrashing. This sounds like an anti-pattern to me - let's call it RequirementsTossedOverTheWall. -- RussellGold

I'm with Chet that without customer connection, you can't get the full value of XP. However, I'd add this: if all a project lead can do is to get the techies on the same page, that is a great thing. A house divided against itself cannot stand and all that. If I had known as much about XP on some previous projects as I do now, I think some of them would have had much better outcomes. Here's why: DeveloperOnlyXp --RonJeffries

[AnonymousDonor described having problems due to general CodeChangeResistance, and also very severe problems with the "Extreme" name. He later retracted his comments.]

I still like the term "JustInTimeProgramming." (NameXp used to have a nice list of ideas.) -- JeffGrigg

Another possible name: Light Weight Process -- NickBishop

We can't really expect people to just jump in over night, not when they've had years and years of other methods or no method. It's comical about the accusation that you're trying to lay down some new DOD method on them!

This is probably a bit late for this particular test case, but if you have trouble with the name you might consider a name I have been using for a while for a broadly similar set of aproaches. I call it StressFreeProgramming. After reading up on all this XP stuff, I may just aggressively rework my rules a little too. Don't ever get hung up on a name - invent one if you have to! -- FrankCarver

One of the things that's impressed me about XP all along: the high level of empowerment for developers. Maybe the next step to take is not a direct XP step, but is the indirect step of building an empowering process. Remember, central to XP is the contention that we find measures of whether something works, and we only continue doing things that actually work. Maybe the next step should be along the lines of building an evaluation process.

As always, if you tell me I oughta do it, I'm annoyed, but if I think of it myself, I'm delighted.

At this point, I think of XP more as a way than as a set of individual techniques. Anyway, good luck and keep us posted! --MichaelHill

Some issues to be concerned about as a project starts to use ExtremeProgramming:

UnitTests have to become a way of life. This is relatively easy to achieve if some major players buy in. Declare it by fiat for two weeks and then gather the reactions. It is trivially experience-able that UT's really improve almost any coding situation.
The next hurdle: developers make developer decisions, business makes business decisions. This is a tougher sell. Try getting a mixture of them in a room with a deck of user-stories and let them start playing. Remember that it's *fun* to plan this way, as well as functionally successful. See if you can convince a business person how much the team needs a business player at least part-time.
That old PairProgramming magic. This just can't be done by fiat, I think, only by modeling. Much of the logical opposition to PairProgramming has to do with the question of inefficiency. Point out that PairProgramming is only inefficient if your sole measure is LOC. If we ask how *good* the LOC are, in terms of defects, maintainability, creativity, and flexibility, then pairs seem much more efficient. Of course, the logical problem isn't the only one: DeveloperMorale? is a more serious matter. For that there is only the modeling. Do it yourself, and encourage others to do it, too. *Enjoy* the pairings: the productivity AND the discourse. Scan ToAyoungExtremist, too, to see one response to 'vision' differences.

The only evidence that exists suggests that PairProgramming produces LOC at the same rate and higher quality. It does not appear to produce code more slowly.

That said, there is no need or point to selling PairProgramming to management. Just help each other. They likely won't object to people helping each other. Tell them it's teamwork. --RonJeffries

It really pleases me that you're getting somewhere with all this. Keep up the good work! --MichaelHill

Always and only: recommend what you and your guys have actually done and what has worked for you. If UnitTests have worked, show the lunch guys, tell them. If PairProgramming has worked (even sometimes) tell them.

And mention other things that you haven't tried yet, but that you plan to, and invite folks to experiment with them and share their experiences.

Nearly in order, if I had to do things in order: UnitTests, FunctionalTests, IterationPlanning, CommitmentSchedule, the coding rules (YAGNI, Simplest, ...). Oh yes, and CRC. Design and describe the system with CRC always. Don't call it anything, just do it that way. And always adaptable: if there's a problem, and people recognize it, experiment with ExtremeRule?(s) that address that problem:

"Hmm, this code sucks. Instead of throwing it away, let's try first writing some UnitTests for it, and then see if we can refactor it to be cleaner without breaking it."

Opportunism is it. As you have seen, you can't just dictate the stuff, you have to pull it out when they're ready. OnlySayThingsThatCanBeHeard, says Hill. It's a good point. --RonJeffries

I have just started down the same path: introducing XP to a team on a project in trouble. So far PairProgramming and StandupMeetings? have been introduced and are working nicely. There is some reluctance on one developer's part to participate, but I think that can mainly be contributed to his general lack of social skills instead of lack of wanting to do XP. Already, just with the standup meetings, we have cut overhead by two to three hours per day!! Next comes UnitTests and ReFactoring.

-- HankRoark

If the problem was that nobody knew what the customer really wanted to be done (sometimes in spite of the piles of paper sometimes because nobody has even tried to listen), I would start with UserStorys. I say, "I'm just not understanding these wonderful analysis object diagrams and sequence diagrams. Would you mind if I just made some notes on what needs to be done?" Then I start writing what sound like the name of stories on cards. After a few minutes, there is always an opportunity to pick two up and say, "How is this different than this?" or, "Which of these is more important [holding one above the other and then switching them." Pretty soon the customer can't stand it and they start handling the cards. Then they start writing. --KentBeck

Recently C3 has been doing fewer CRC sessions, because we were into final release stuff with smaller and smaller tasks. Or so we thought. Just now we've started CRCing more. First thing that happened:

Person who knows the problem and solution sits down for a quick review of his proposed solution. Goes through the cards, gives his [very nice] solution. One of the other people, not involved, says "Wouldn't it be even better if blah blah?" Silence, then everyone around the table goes "Oh yeah!"

Second thing that happened:

Sitting around the table CRCing one of the problems on the board. Half way through, someone says "Hey, that's like what I was working on," and describes their problem. Session continues. Pretty soon another person says "Hey, that's like my card too," and describes their problem. Session continues. Finally someone proposes a very simple solution that handles all three problems, more simply than any one of them would have been. Never would have happened had they not all been around the table.

To get people all on the same page, sit down and CRC with them on your problem. Make sure people who can contribute are there. Make sure people who need to know more about the system are there. In general, make sure everyone is there.

You'll bring the group together, you'll develop team behavior, and you'll get better code. --RonJeffries

I have noticed that on more than one occasion [some new project managers] have said "my developers" instead of "our team". Not a bad thing but it does change the tone of advice I would give. During the NapoleonicWars? the best generals were the ones who drew their sabre, grabbed the battalion colors and ran hell bent toward the enemy line having absolutely no notion of whether anyone else would follow them or not. I suggest that some things never change. Set a good example of how you want things to be done, they will follow.

PairProgramming is very hard to get started. It is very difficult for people to see exactly what you mean by it. I know I didn't. Again, set a good example. Do all of your own code in a pair. Another good thing is to make sure there are only "number of people divided by two" tasks being focused on at any given moment by the developers. Now you have an environment where PairProgramming has a chance to grow. -- DonWells

I tried PairProgramming, but it doesn't go well either. I think it requires you use CrcCards often, so both programmers know what and how to do. -- ChenYu

How about getting all three of you into a small corner if the office, and do some ScrewdriverWork?