I just posted this to the agile-testing list; I thought it was worth sharing. More test challenge to come!
I have seen many organizations try to embrace agile, compromise, and fail. ( See “Big Agile Up Front“) That’s not a failure in Agile; it’s something like what /I suspect/ Ron would call “We tried baseball, and it didn’t work.”
As I see it, several problems mash together here:
(1) It turns out the problem of customizing a methodology introduces a lot of unintended consequences. And no, doing it “by the book” won’t eliminate the problem; instead you’ll get someone /elses/ intended consequences. Will those match your values? Who knows?
So tailoring knowledge work requires a great deal of abstract thinking, modeling skills, experience and team buy-in – which is what I try to focus on in my work. Yet few authors/speakers address the space of customization and dealing with change in a meaningful way. Of, you’ve got Diana Larsen and Dale Emery and a few others, but I think there is opportunity here for us (as the agile community) to do more.
That sounds like a great proposal for a talk or Six at Agile 2009.
I’m just saying …
(2) Many organizations live in areas that are not next to a world-class CS school, peg salaries at 50% of market average /for the area/, have work that isn’t all that interesting, and won’t pay for relocation. I’m not sure I have a fix for this; they’ve designed their own kind of special cocktail. A superb kind of technical leader can /help/ pull and organization like this out of the mire, as can superb individual contributors.
My fix for this is invariably, to offer telecommuting, and you can hire the world for a fraction of the cost.
(3) North America is locked in the same command-and-control mindset that won us WWII and made Ford a Billionaire. It’s kind of hard to fault that. The only problem is that way of thinking is about fifty years out of date and can no long compete globally.
(4) Most American employees work inside a system that rewards certain types of behaviors. When people behave in the way they are rewarded (or have been in the past for years), can we really blame them?
These are just a few of many barriers to agile adoption, just as GM and Ford and Chrysler have struggled to adopt continuous improvement and anything like the Toyota Production System on the assembly line.
Or, to quote Lee Copeland: “If you measure the wrong thing, and you reward the wrong thing, don’t be surprised if you get the wrong thing.”
How we deal with that is up to us.
UPDATE 1: Hey, I’ll be in Detroit, Jan 14th, speaking at the Great Lakes Software Process Improvement Network on just this subject! You can’t beat it with a stick!
UPDATE 2: Personally, I find it easy to trade off my personal process, and I find it pleasurable. Above, when I say “freakishly hard”, I mean the cognitive process of taking something like Scrum or XP, adapting it to an organization’s context, making compromises to suit the VP of Sales, the VP of operations, and the director of engineering – then trying to roll it out to a large organization. The unintended consequences of those tradeoffs tend to get you. My ideas on alternatives are what I hope to contribute to the panel discussion at GL-SPIN in January.