I think you're really missing the point here. Both the point behind XP and Steve's description of agile processes at Google.

If you read between the lines, all forms of agile development are about one thing: find stuff that works, make it cheap, and do it constantly. Most developers have never been on a project that wasn't hoplessly dysfunctional in one way or another, so adopting the 12 step XP program is probably the best way to start with a process that works.

But XP doesn't work in every team. In fact, it doesn't work with most teams. The on-site customer is easily the hardest facet to pin down. A lot of teams that want to do XP realize that they will never get a full-bandwidth on-site customer and start adopting what they can, even if it doesn't make them fully agile or 100% XP. But at least it's a step forward.

If you read what Steve describes as Google's process, it's an attempt to achieve the same result with a totally different approach. Google greases the rails in a unique fashion that's probably not repeatable anywhere else in the world. That doesn't mean that Google's process, complete with free lunches and unlimited funding, is the only way to do agile development, just as XP isn't the only way to run an agile project.

Steve's point, as I understand it, is that there are two kinds of "agile" in software today. There's the hype-laden world of consultants, trainers, seminars and conferences that preach and spend your money, and make you feel bad if you're not following someone else's process by the book (but ultimately don't leave you with a functional process, and make you feel guilty for your procedural shortcomings). And then there's the world of actually getting things done, and removing all distractions, and turning the knobs to 11 until you can't help but deliver valuable software to your customer, continuously and repeatably.

Adam, thanks for the comment.

I like to think that my little XP guide made the point that the XP practices fit together carefully to meet the goal, but that if you understand how any single practice supports and depends on the other practices and why it's part of XP, you can replace it with something similar if you're careful and thoughtful. (You can use eggs or oil or butter in a cake recipe, but you can't get by without something to mix with the flour.)

I also like to think that this reasoning is well in line with the "Delivering real value to your customers is the goal of software development" people.

Making facile, throwaway assertions that pair programming never works or the planning game is stupid puts Steve firmly in the camp of "Doesn't understand XP or agile development" to me. Catered meals may improve developer motivation, but what do they have to do with feedback, discipline, repeatability, or customer value?

I don't think it's helpful to have a blanket response for anyone who disagrees with you that consists of, "Then you don't get it." If nothing else, the Internet has proven that argument to be as unhelpful as it is wrong.

That said, you're certainly justified in saying that it's unfair to criticize a methodology as a whole by analyzing its component methods individually. If XP or Agile works for you, then I don't think anybody will come by and tell you that your experiences are somehow wrong. What gets to me, and perhaps others critical of formal methodologies in general, is that proponents are often very dismissive of other methodologies. The problem is when you have, for example, an Agile booster poo-poo'ing Waterfall as too rigid and slow, and then proceeding to document their own 12 step program, seminar series, books etc. that you need to follow in their entirety to see the benefits. That sort of thing just rings false to me.

I've written more about my reactions to Steve's post and what I think about why Google can run the way it does over at my blog, but perhaps we just don't see eye-to-eye on this.

Thanks for the reply, Anthony.

I do stand by my comments though. I strongly believe that XP stands or falls on the combination of its practices. If you throw out refactoring, you severely weaken your ability to add new features and modify existing features. If you throw out iterations, you impair your ability to deliver value to the customer at any time. If you throw out collective ownership, you forego refactoring and pair programming. Without good coding standards, forget about collective ownership. Without an on-site customer or equivalent, you have far fewer opportunities to manage scope changes.

It's easy for programmers to understand that your computer just don't work the same way without a CPU. Why is it so offensive and difficult to believe that if you throw out parts of XP for whatever reason, it's not going to work?

Trust me; it's not easy to develop good software and it's not each to practice XP well. It takes a team with commitment and dedication. It takes discipline and courage and honesty. I expect to make mistakes, but I also expect to learn from them and react to them appropriately and to get better at writing and delivering good software over time.

Yet when someone says "XP will never work because pair programming is silly because I don't want someone watching me type over my shoulder and telling me that I've missed a semicolon", I start to think that that person knows only enough about XP to use some of the same words in a sentence. I usually say so, and I'm not surprised when hucksters, charlatans, and the deliberately ignorant take offense to people saying "You really don't know what you're talking about."

That seemed like a fairly wellreasoned critique, although the Star Trek Marmot spiel was a bit harsh. But isn't Steve Yegge sort of known for his late night, hand waivy, half-researched pieces? I mean don't most people read his work for the artiface rather than the content?

Actually, I had a completely different take on what Steve was trying to say in the original message: less that XP was ineffective, and more that the rabid "Kool-Aid" attitude of its adherents was out of proportion with its actual effectiveness. Some of the responses I've seen to his article (like this one) really seem to mostly support this theory -- the tone is more defensive than conversational.

No one's accusing XP pracitioners of being stupid, or unproductive, just more fastidious about a particular set of processes than you would need to be if faced with a better working environment. No, we can't all work in ideal (and idealized) environments like Google, but clamping down even harder on individual creativity with hardline enforcement of a particular process model isn't necessarily the answer, either.

The freedom of developers at Google to work without the constant emphasis on ship dates is not some new privilege brought about by their market successes; rather, it's part of their culture, brought along from (gasp!) academia. This is a Good Thing, and worth emulating at other firms.

Just because you wait for a product to be finished before you ship it doesn't mean you're going to be slower overall, just that you don't necessarily pull delivery dates out of thin air and then stick to them. Look at the history of, say, Microsoft OS releases: they pick a hard date, and then push it back repeatedly, alienating customers all along the way, while not actually delivering more predictably than a "when it's finished" shop.

Having worked in business that followed both scheduling models, (despite having never gone anywhere near a graduate degree, or having worked at Google) I can say that the "when it's ready" school really does have a lot to recommend it. Blowing a deadline is bad, but blowing an entire relationship because you deliver crap is even worse.

rcoder, thanks for the response.

I'm not sure why you talk about an emphasis on ship dates, however, as if that's part of agile development. (I have the sense that you're setting up a false dilemma here, but I could be completely misunderstanding you.)

The quality you suggest of Google's development process -- finishing features -- is actually part of agile development as well! Both Scrum and XP provide managerial and management techniques to handle the scope of features with the schedule, and XP provides also developer techniques to refine the features, to accomplish them with the necessary time frame, and to know that they are complete.

I really don't get the sense that Google's model provides that. That doesn't mean that I think that Google's model is bad, just that comparing it to products that have actual customers with actual business needs for the software (else why are they paying for its development) is severely inappropriate.

(I also have no idea where your notion that this clamps down on individual creativity comes from.)

My main problem is that I understood Steve as dismissing XP based on a severe misunderstanding of a few practices. It was as ridiculous as if I claimed that Mandarin Chinese has no verbs because I've only ever seen a list of nouns.

I know XP. I understand how it works. What Steve described as agile had only the presence of a few words in common with XP. If he's going to describe it as "agile" without adding a disclaimer or making his satire reasonably obvious to someone knowledgeable, people who understand XP and agile development really ought to be able to say "That's wrong and uninformed."

I'm sorry if you think that makes my response rabid.

In my experience, the Marmot/Muskrat thing sounds exactly like the way a lot of managers treat technical or procedural recommedations from technical people.

It is fantastic and easy make.