Is Xp Synergistic
Is Xp SynergisticMoved from ExtremeDiscipline, which was moved from IsXpOverclocked - this thread seems to me to be more about the synergy of the different XP methods than the discipline required. It also touches on the viability of PureXp and ImpureXp? which I've tried to imagine in XpLite. Besides, I wanted the name for something else. ;-) -- BenAveling
Inserted: I've observed that when C3 goes off-process, productivity drops substantially. This is consistent with our claim that XP is synergistic. It is also consistent with Alistair's work discussed below. The inquiry behind this page relates to an Extreme Project needing, quickly, to see that it's off track, to determine whether it's off-process or under-process, and to fix things. The page isn't about failure, it's about tracking. It's about humans and their flaws. It's about me and mine. -- RonJeffries
AlistairCockburn comes by his methodology recommendations especially honestly: he has visited many projects and recorded what they actually did. His "Crystal" notion characterizes methodologies on dimensions of risk vs team size. He recommends "with so much risk and so many people, here are the practices that have been associated with success".
XP seemed to Alistair to be too good to be true. The ChryslerComprehensiveCompensation team claimed too much success with too little process. When he visited the team, we put two pairs on his "coffee machine" exercise (see his web page). He was surprised to find that they approached it the way XP recommends. He interviewed the team and was surprised at the consistency of the reports.
In his presentation on methodologies at SD West '99, Alistair points out that though a methodology might be scaled to X risk and Y size, you can "push" it to a bit more risk and a bit more size. He suggests that XP reaches above the scale you'd expect by use of high discipline: the team follows a much more strict regimen of rules adherence than you'd normally require or expect.
The eXPressionists have been saying all along that you have to do it all to get the full benefit. Is Alistair saying the same thing, with some useful data from other real projects? I'm starting to think so.
As has been reported here from time to time, the C3 experience has been that when we fall away from our practices, things go to hell. Now any decent set of practices would have that characteristic: if you don't do the good stuff, bad stuff will happen. But a high-disciplne, synergistic methodology might be particularly "cuspy": a little deviation could take you way off track.
As the guy on top of this one project for so long, I am strongly inclined to agree with this. When it's clicking, we can really kick. When we go off process, however, we seem to hit the weeds rather quickly.
If it's true, what's the lesson? I suggest that the lesson is that if you're going to try XP, you have to really monitor the signs that you're going off the road. You have to do it all, you have to stay right on top of your game. If you don't, you'll find that you need more documentation, more process, with a resultant slowdown, to stay effective.
-- RonJeffries
Ron, although I am a strong believer in some XP principles, your comments such as when we go off process we seem to hit the weeds rather quickly sound similar to devout worshippers believing that the reason they have been unlucky is because they weren't devout enough (we must SacrificeMoreGoats to make the rains stop!). Do you claim that if things go to hell, then you're not doing XP? -- JohnFarrell
I don't claim that, I observe it in the specific case of C3. Discussed further below.
It actually sounded like a simple cause-and-effect thing to me: when we do this we go fast, when we stop doing it we slow down. It's the scientific method. First you observe a phenomenon, then you devise a hypothesis to explain it, and then you build confidence in the hypothisis by watching it predict the outcome of experiments. The difference between Ron and the goat sacrificers is that when Ron sacrifices his metaphorical goat his metaphorical rain actually stops. -- PhilGoodwin
All the best religions sound like simple cause and effect - if you sacrifice a goat, the rain will stop, unless the rain gods are really angry, in which case you should sacrifice more goats. Consider DoTheSimplestThingThatCouldPossiblyWork. When you do that, and fail, the naive reason would be because you got carried away and didn't do the simplest thing. Because simple means so many different things, that's an easy claim to make. However it could also be because the simplest thing had to be totally refactored to do something a bit harder, in which case maybe the simplest thing wasn't the best thing. Similarly, if you have problems when you RefactorMercilessly, is it because you were too merciless, or not merciless enough. There is so much room for interpretation in the XP principles that you could do it successfully or unsuccessfully. To claim that XP is the panacea is to detract from the judgement and experience of people like RonJeffries and WardAndKent who know what the simplest thing is, know how much mercilessness is enough, and are (apparently) so damned good at making XP work. I find it easier to believe that when Ron hits the weeds, he adjusts his interpretations of simple and merciless to get back on track. At no time has he left the XP framework, and it is in fact Ron's ability which gets him back on track rather than XP. -- JohnFarrell
Thanks for the implied compliment. What we're trying to do with XP is to tell people what we do and how we do it, so they can benefit. (By doing what we do, or the opposite, whichever actually turns out to work.) We don't claim that XP is a panacea. We do believe that at the appropriate scale of project risk and size, the practices are sufficient for success. I'm exploring here the extent to which they are necessary.
The XP rules are mostly not subject to interpretation up or down: they all point one way. Testing everything that could possibly break is better; refactoring all the way to once and only once is better, etc. In experience, as discussed below, C3 has never once decided to improve by doing less of any of the practices. Always more. --R
Hmm....I'm perplexed by all this magical philosophy stuff. As an XP outsider, or a mere mortal at best, I find that I benefit most from reusing the parts of it that add the most value to my current project. I don't think any project I'll ever be involved with will ever be considered "XP Certified" but I'll always feel glad that their experiences to some extent helped me do a better job in my own situation.
Perhaps I'm too much of a pragmatist, or a rogue at best, but how can you talk about being simple or merciless and really offer any more value than a waterfall method or a ScrumProcess or a Rational Unified Process can? Is it easier to be successful at projects that are pure XP?
We all would like to have "the answer", the way to develop software that can't fail. XP isn't it. Nor is RUP or Scrum or anything else. XP projects will fail, and there is nothing we can do to prevent that. The best we can do is improve the odds. And yes, I think XP improves the odds. There are certain kinds of failures that XP is designed to tend to avoid. -- KentBeck
John and PhilG: When things go wrong, it becomes obvious sooner or later. A customer is unhappy, something breaks in production, estimates aren't met, something.
When this has happened, some folks always suggest some new process element, or want to go back to old-style project management. "Why don't we just assign tasks, instead of letting developers pick?"
Every time C3 has dropped down in performance from the level we have been able to sustain over time, we have found a specific process element that wasn't being adhered to as much as it had been.
One time we hadn't been refactoring; one time we had slacked off on testing; one time we had slacked off on having public CRC sessions to design stuff.
Two key aspects: Every time, trouble has come from a specific practice decline, and every time we recovered by just refocusing. I'm pretty reflective about this stuff, and I'm really quite sure I'm not making this up. I'm really quite sure we didn't "redefine" testing, we just went back to doing as much as we used to.
We didn't redefine testing, we reflected on the recent past, noticed we had done less than before, noticed we had slowed down. Did more, sped up.
We XP guys have been saying for a couple of years that when you do all the practices in concert, you go substantially faster. Therefore, if you are doing them all, and you stop doing one, duh, you'll go substantially slower.
What I'm working on at the moment, with all your help, is how you recognize quickly that something is dialed down a bit, how you recognize what it is, and how you pump it back up, before your tires hit the grass.
PhilE: Is it easier to be successful at projects that are pure XP?
We have been saying so. We believe so. We believe that waterfall is based on an extremely incorrect assumption, i.e. that you know what you want. We believe that RUP is overloaded with process for many situations, and that a lighter process can go faster. XP is made to be as light as possible.
Kent: If synergy of all the practices makes XP go more than proportionately faster, and we say it does, then one practice going down will have a disproportionate negative effect.
When we're on our game, we have "scores" like 90, 85, 95, 90, 99, 87, 90 ...
When we're off our game, we have "scores" like 80, 75, 82, 70. Way different. This shouldn't be a surprise.
My questions are:
I gotta go now, got goats to kill. --R
Ron, the phrase "hits the weeds fast" implies things being pretty bad, worse, I suspect than what you perhaps mean. You and I have both seen projects seriously "in the weeds". I suspect C3 wasn't that far off, but I wasn't around and have to ask you.
You have commented elsewhere on discovering difficulties during Xp. My question here is, how high were the weeds you were in? We clearly are not talking project shutdown, here. Nor, I suspect, failing a 3 week deliverable and turning it into a 6-week delivery. I am hazarding the guess that you mean people had to work overtime and the delivery was up to 5 days late.
For C3, that may be in the weeds, but for many projects, that is still quite luxurious. So please clarify - how bad or how close to disaster, and how long until you discovered? If "XP failure" means "reverting to like most mediocre projects", then we should not make it look like "lay people off and send them home." cheers -- AlistairCockburn
p.s. I was about to compliment you on your IsXpOverclocked page. Good analogy, even if the title is a bit pessimistic.
I speak vividly. It keeps me awake. OK, we were clipping the gravel on the side of the road. We released a few non-fatal defects to production. A few things aren't getting done in the iteration and we're surprised. We've reverted to better than mediocre - but that's a long way down from where we like to operate.
I think the overclocked metaphor is a bit off, note Kent's remark that working 100 hour weeks is overclocking. I don't see why doing the XP discipline should make anyone tired - but I observe that it does. It's not like burnout, I've been there and done that. But it's "a little tired". Maybe Don's right and people need a change. Don't know yet. But I will. -- Ron
So, Ron, when things went wrong, what was it that went wrong? How wrong did it have to go before you noticed? What did you do when you did notice? XP keeps track of certain things like FunctionalTest scores and LoadFactor. Was it changes in the things you keep track of that you noticed? I'm also curious about whether the first thing you tried worked. If it did it indicates that you have some deterministic way of diagnosing these problems and treating them. Maybe you don't know how you do it yet, but I have faith that once you know that you know, you'll find a way to tell others. If you don't have a means of diagnosis then you probably want to look for one. If it were me I'd be wondering if I'm keeping track of everything I want to know about. -- PhilGoodwin
picking up the thread about discipline from IsXpOverclocked...
In IsXpOverclocked, you said "But XP, as we've defined it, is all of them." So if I have 22 days vacation per year and I plan on using them, am I not following XP as you've defined it? I don't want this to sound sarcastic, I'm just wondering where you draw the line. -- PhilipEskelin
I'm sorry Philip, I'm not tracking. I have yet to say anything about vacation schedules in the context of XP. I was just saying what is common in Europe that I haven't seen done in the US. I think it is a good idea, and it might address the problem Ron mentioned. -- KentBeck
The quote refers, I guess not clearly, to the fact that to be officially doing XP, you have to be doing all of the defined XP practices. Vacation days and dietary regulations aren't part of XP. Am I not understanding something? -- RonJeffries''
I don't mean to be cryptic, so I'll try to clarify. I have a hard time with the whole 'one size fits all' attitude about methodologies. I don't know if this is what's happening with XP. My experiences so far -- based on reading your XP pages over the last few years, through talking with colleagues, and through reading Kent's recent CPP Report article -- tell me that I can get a lot out of borrowing from certain parts of XP that I find attractive based on the needs of my situation. For example, I've used PairProgramming a lot, but I've never used CrcCards. Perhaps on the next project I'll find them useful. As I wander through other things I understand about XP, I see myself using and not using various parts, and it slightly differs from project to project.
So what I'm struggling with is this: what is the value of going through the trouble of following all of the defined XP practices when I already benefit from it anyway? Who knows...maybe there are a few key XP pages I've missed that hit this nail on the head. -- PhilipEskelin
There's no law or anything. We wouldn't recommend them all if we didn't think they all worked best together. For example, you can DoTheSimplestThingThatCouldPossiblyWork more safely if you use MercilessRefactoring, which is much easier to do with comprehensive UnitTests.
What is the value of exercise if you're already eating right? -- RonJeffries
I am fairly on record as promoting "one size won't fit all", and I think the XP designers accept the notion, also. There was a long discussion about "100 person XP projects" to illustrate those issues. XP certainly seems to work for 10 person teams. I also detect that individual XP practices are valuable in and of themselves, and Philip does, also. What Ron and Kent are saying is that doing 90% of the XP practices gives you (e.g.) 75% of the value of XP, and to get from 75% value to 100% value, you have to do 100% of the XP practices. That nonlinearity is certainly interesting to note and discuss - see NonlinearityOfXp -- AlistairCockburn
OK, this is pretty cool. I'm glad we've had these discussions. I think you are right that 100 percent XP pops you into 100 percent value, which to me is defined as being entirely successful at executing the vision of your project.
see SuccessStatement
For the record, we do not assert that if you do all of XP you are guaranteed success. We just think it's a really good set of practices, and that if you do them all you get disproportionately better results than with a subset. -- rj
And I could do 80 percent XP and 20 percent magic (or luck depending on how you look at it ;-) and be just as successsful in execution. And Jane and Joe Hacker could bang out something with "no method" at all and be happy campers. This shows that there is no prescribed recipe anyone in the world on a team of any size could follow and guarantee success. Probably why this discussion's been so interesting. But it is odd to me since this recipe is what many software process zealots/alchemists have been after for decades.
While I agree that there's no silver bullet, I don't quite follow the logic that says that Jane and Joe being successful without the bullet proves that there's no bullet. Doesn't Jane and Joe's success just prove that the bullet is non-necessary rather than non-sufficient? -- rj
I find this discussion very confusing, and I think the confusion centers around a difference in what "success" means to different people.
I think that asking whether or not a project is a "success" is only looking at a small part of the whole picture. Surely there are varying degrees of success. Suppose that you met all the requirements for delivery on time and on budget. That's certainly a successful project. Suppose you got there by using 70% of the XP practices -- well, fine, 70% was good enough.
The "synergistic" argument says that if you had done 100% of XP, the project would have been more successful. Sure, the customer is happy -- but wouldn't the customer be happier if it had taken half as long to complete the project? Or had performance vastly better than had been mandated? Or included some of the functionality that has currently been deferred to "phase two" of the project?
Obviously there is some minimal level of deliverable which constitutes "success" (this is what SuccessStatement is saying, unless I've completely misread it). However, I would say that there's always room to do better -- unless your project is solving all of the world's problems in zero time at zero cost, and incidentally transforming me into the AllBeingMasterOfTimeSpaceAndDimension. If I have the option of doing some of XP and making my customers happy, or doing all of XP and making them much, much happier -- I would certainly opt for the latter.
Brett, I think your comments are compatible with mine. Ron, maybe the logic wasn't there, and there really is a bullet. Will we ever find it? It seems that success is so darn relative, that it would be hard to imagine that in all contexts doing 100 percent XP makes you more successful than 80 or 60 or 40. Maybe in some instances it was a political issue: the project crumbled because people pushed the XP kumbaya too hard and people used it against them. -- PhilipEskelin
EditText of this page
(last edited January 20, 2004)
or FindPage with title or text search