What Problem Does Xp Solve

Software with a crappy design, delivered late, full of bugs, and not what the customer actually needs. The usual suspects...

[Moved from XpCritiqueDiscussion]

Ron tells us "Right: ExtremeProgramming is designed for small teams...". And I wonder: was there ever a problem to be solved here? Has the software industry really ever had a problem producing software on a small scale? The problems only really come when you add more people to a project.

If you read a bit more you will see that Ron also says "[a] HundredPersonProject is a ten-person project, with overhead. Doctor, it hurts when I do this". Now do you see how XP solves a problem? You should start to ask why you are adding more people to a project. --AnonymousDonor

was there ever a problem to be solved here? Has the software industry really ever had a problem producing software on a small scale? The problems only really come when you add more people to a project.

Yes, there are many small teams that fail to deliver satisfactory solutions to small-scale problems. The solutions that are often associated with the term SoftwareEngineering may not be applicable. Much of the literature came out of large systems, often government of very large vendor products, and is focused on dealing with very large systems problems and large teams. Trying to scale these kinds of practices downwards is, as Ron says, a "Doctor, it hurts when I do this" effort.

XP is prepared for change, but not for success

You don't have to have a problem to solve to try out new ideas. Doing so might help you see problems you never knew existed. What I like about XP is that it shows there is more than one way to develop software. XP is an example of how old rules may be broken to good effect (e.g. refactoring vs. "if it's not broken don't fix it").

However, it is a dangerous step to take from "small teams can work more efficiently" to "a small team is something to aim for". Let's start with the the question of "why you are adding more people to a project". Well, how about this: because the project is a success!

In an XP project there is never a time when you could say, "this is just too much work for 10 people". Why not? It's because an XP project only plans as much work as 8-10 people can do. But if your product is a success, then you will have requirements coming in from the four corners of the earth. How are you supposed to react to that success with only a few people? The truth would seem to be that XP is prepared for change, but not for success. --ChrisSteinbach

...and we are still waiting to hear why more people == greater productivity. --AnonymousDonor

Well it doesn't if you use XP, that's my point :) --cs

Why not just refactor projects that are growing too large into subsystems that smaller teams can work on? So if, eg, you start off writing analytics for a bank, and then later on you need remoting, static data, etc, each of these becomes a separate responsibility.

This seems OK to me, although now you have to compensate for the communication overhead between teams and users. Can you do this and XP? I don't think so, but that isn't important so long as your project is able to move from one way of working to another. --ChrisSteinbach

It seems to me that, to facilitate such an environment, you'd want the interfaces between subsystems to remain relatively constant. Can't you just make this a UserStory? "The subsystem shall have such-and-such external interface..."? -- MikeSmith

That works for a software interfaces, but what about communication channels, delivery procedures, integration and test activities? --cs

... Can you do this and XP? ...

MikeBeedle seems to think you can by using ScrumProcess to wrap XP teams. Scrum does scale (according to Mike and KenSchwaber, authors of the ScrumBook).

See also XpMayNotScale

XP is apparently about solving the problem of responsibility. An XP programmer moves all responsibility to the poor customer... --AnonymousCoward

The XP practices of WholeTeam, OnsiteCustomer, CustomerTests, and PlanningGame address problem of poor feedback between team and customer. We recommend one keep the customer in the loop; don't keep them in the dark, don't feed them horse shit. Do what they say to do, in real-time.

Customers find XP teams very easy to steer. If the poor customer does not want to steer, what methodology will solve that? --PhlIp

When you fly on a plane, how much does the pilot ask you, as the customer, to steer? --AnonymousDonor

The airline asked you, before you bought your ticket, where you wanted to go. The pilot is not like programmer doing creative work, he is carrying out a repetitive task as well as possible. In this example what is wanted is very clear (get safely from point a to point b) and thus not a good analogy. For one thing, you can't change your desired destination mid-air. Well, you can try, but you'd get in big trouble. One of the things XP claims is to be better at helping you figure out where you want to go. If you change your mind, XP can change course, but the customer is informed of the cost.

Have you ever flown with a bush pilot? Might creative, and thankfully so. XP doesn't help you figure out where you want to go because it is the customer that tells you this! What does XP do other than say ask the customer for the tests? --AnonymousDonor

Well, for one thing, the customer is part of the team and in constant communication with the developers. Another, they are involved in IterationPlanning and ReleasePlanning. Etc...

See ExtremeProgrammingCorePractices. Practices include ContinuousIntegration and DoSimpleThings.

There's quite a bit of discussion of XP-style requirements and responsibility at ElicitingRequirements.