By “higher caliber,” I mean: there are some developers that you would trust to write the firmware for your pacemaker, and some developers that you wouldn’t trust to write a Facebook applet to rate today’s celebrity gossip. Some developers have command over the problems and technology that they work with, and others just keep hacking until it appears to work. I’m talking about the former group.

I’m not really interested in XP enough to engage in a point-by-point debate. XP’s forte is the reliable production of mediocre results for small teams. There is a place for that in the world, and XP is adequate for that purpose. My issue is only with the degree to which other ideas have been crowded out by the bandwagon. If XP weren’t popular, I wouldn’t give a damn about it. If I do talk about it, it is only as a common point of reference in current methodology.

I’m looking for the limits of what is possible, and Lean and TOC are about searching for limits. TSP and DFSS are examples of the limits of current practice. Gilb’s work, past and present, shows much of the way forward.

How do you define a “higher caliber” developer? That is, how would you identify one and then see what type of process appeals to him/her.

What do you see are the distinctions between XP and Scrum planning and scheduling?

What do you mean by “weak” in “On-site customer + user story is an exceptionally weak requirements method”? Incomplete? Slow? Something else?

Does XP advocate pure emergent design by refactoring?

Why is pair programming antithetical to Lean?

Do you mean TDD is a subset or poor replacement for Design by Contract?

Is XP not a good development process because it’s missing certain practices? or because it doesn’t reliably produce good properties in a project or product? or something else?

TSP appeals to a higher caliber still, but they didn’t take up the kanban idea (yet). Nobody has ever claimed that TSP should be classified as “agile,” although I’d say that it still has a lot in common with Evo. I plan to demonstrate that TSP is perfectly compatible with Lean, then I plan on enumerating the things I think are wrong with TSP.

XP is weak in some of the same areas that Evo is strong, which is why I brought it up here. XP planning and scheduling are weak enough that nearly everyone replaces it with Scrum. On-site customer + user story is an exceptionally weak requirements method. Pure emergent design by refactoring is a weak design method. Sketching is sufficient for building backyard sheds, not skyscrapers. Pair programming is antithetical to Lean. TDD is a cheap knockoff of Design by Contract. No usability process. No reliability process. No security process. I pick on XP because people have become complacent about it, and that’s bad. XP is not the best development process, it’s not even a good development process. If we want to make progress as a profession, we have to challenge this.

The reason that I started this blog is that there is a whole wide world of ideas that are compatible with Lean that have nothing to do with the Agile methods to date. There are already plenty of cheerleaders for the status quo.

How does FDD appeal to a higher caliber of developers?

I found an neat table from an older Gilb book that describes the feature-driven decision practice: http://praxis101.com/blog/archives/000034.html

I think there’s a lot of value in the empirical nature of XP. Knowing my development capacity really helps minimize effort estimates and errors. But nothing beats the EVO method for getting a project moving, or rescuing one from overruns.

My experience in recruiting others to Tom and Kai’s methods is that most don’t believe that a feature and metric driven practice can move quickly enough. It’s hard to believe it if you’ve never tried.

-Bill A