I just posted this to the agile-testing list; I thought it was worth sharing. More test challenge to come!
//Begin Post
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.
Matt,
I think the problems you identify are just a few among the myriad possibilities. One point to consider: organizations don’t try to embrace Agile; people within organizations try to embrace Agile. People in organizations dealing with change do so at widely varying speeds, and often don’t have the same goals. It’s no wonder that the results are all over the map.
Customizing the methodology is a lot more than abstract thinking and modeling. It requires a huge understanding of how people change, and what changes are both acceptable to them and appropriate for a successful change in the particular time and place. It’s all so context-sensitive that it’s little wonder you don’t hear speeches about it at the Agile Conference. (You do learn about this stuff at the AYE Conference though. It’s just up to you to apply it to your context.)
My real reason for commenting, though, is your suggestion to offer telecommuting. While that might enable them to hire someone with superb technical skills but low salary expectations, I don’t see how it helps them make the Agile transition.
1. If they’re not already doing this, then it’s another change to assimilate.
2. If they’re previously all local, then this introduces the issues of distributed teams, which is as difficult or more so to learn than adopting Agile.
It seems to me that this is a solution in search of a problem. What am I missing?
“It seems to me that this is a solution in search of a problem. What am I missing?”
George, I’ve been working physically distributed for the past nine months, and I’ve never been more productive. Yes, to effectively leverage telecommuting workers, the staff will need some systems in place. I didn’t say that, so of course it was missing. 🙂