Why is it that the popularity of Agile processes appears to be in reverse order of their usefulness?
Tom Gilb’s ‘evolutionary delivery’ or Evo, dates back to the 1980’s and is more comprehensive and powerful than most of its imitators. But who uses Evo? Who is talking about it today?
There’s something odd about a software culture that is so obsessed with novelty and technological determinism that it perpetually loses the knowledge of the past in an endless pursuit of the reinvention of the wheel. The race in the 2000’s to “out-agile” each other and distance ourselves as far as possible from any crusty old notions of “software engineering” in the flight from some phantom bogeyman of the “waterfall” has resulted in the neglect of a great deal of hard-fought knowledge and wisdom from the great systems engineers of the 1960’s-1980’s. It’s our loss. We’re forgetting things that are better than what we think we know now.
There seems to be an uneasy feeling amongst parts of the Agile community that they’re running out of steam, that there aren’t enough new ideas. I think that’s true, and that there’s a simple reason for it: they bet on the wrong horse. XP is the weakest of the name-brand Agile processes, and it’s a dead end.
I don’t know if the Kanban idea will prove to be important or not, but I don’t think it is a coincidence that the strongest expression of that practice is coming from the FDD community rather than the Scrum/XP community. FDD is a better process than Scrum/XP, it appeals to a higher caliber of developers, and it never had the luxury of complacency.
But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice. And I sort of like the quirky presentation, because it forces you to put together the pieces for yourself, which you really ought to learn to do anyway. It’s more of a “patterns and practices of evolutionary delivery” book than a how-to.
Tom and Kai Gilb also have an excellent website over at http://www.gilb.com.
Kanban discussion
Bill Anderson | 22-Dec-07 at 5:25 pm | Permalink
Corey, I’ve known Tom Gilb and his work for more that 20 years and I think that his POSEM is a gold mine, and one well worth reading.
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
Corey Ladas | 22-Dec-07 at 6:03 pm | Permalink
Ha! That table is great, reminds me a lot of Analytic Hierarchy Process.
Development Driven Development (part 2) :: Fat Penguin | 29-Dec-07 at 4:20 pm | Permalink
[...] believe there are benefits of agile practices in software development, but had also just read the Tom Gilb’s “evolutionary delivery,” a great improvement over its successors post at Lean Software Engineering and also had just learned about a couple more agile software [...]
Jason Yip | 07-Jan-08 at 2:07 am | Permalink
Why is XP the weakest?
How does FDD appeal to a higher caliber of developers?
Corey Ladas | 07-Jan-08 at 1:41 pm | Permalink
FDD is highly capable in analysis and planning, and therefore appeals to developers who are more capable in analysis and planning. FDD speaks to those who realize that modeling has value, and that building models doesn’t mean building one giant model at the beginning of the project before getting on with the hacking. FDD’s feature grammar makes it a good companion for lean because it reduces estimation overhead (waste) and facilitates production leveling.
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.
Jason Yip | 13-Jan-08 at 12:49 am | Permalink
More questions…
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?
Corey Ladas | 13-Jan-08 at 9:58 pm | Permalink
Hi Jason,
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.