Charlie Audritsh just put up a short, interesting piece about agile development. His main point seems to be that he likes agile, and he is just one technical contributor in a larger organization, (specializing in performance testing), but he is going to try be as influential as possible.
I think it's great, and I've added his site to my blogroll.
My take on Agile is a little different than most. I don't think you *have* to have everyone in the same room, 100% customer availability, 100% pair programming, a big set of index cards, and so on.
Yes, in general, if an organization uses the practices well, I think they will be better off than with heavyweight methods. Still, in my book, those things are outward appearances - physical manifestations of an inner change in values. In other words, hopefully they demonstrate that the organization is choosing quick iterations and high-volume communication methods because it follows the principles and values of the agile manifesto.
Then again, it's possible that the organization is just practicing Cargo Cult Software Engineering.
In my mind, Agile isn't "Yes", or "No", it is "More Or Less." More important to me than practices 2, 3, and 4 on the Extreme Programming checklist are questions like "Does this organization respond to change? Can they make the tough decisions and live with the consequences?"
To me, the little poster and note that Charlie put up is one of the more mature decisions any individual technical contributor can make; and I'm not just saying that because I have one my cube that is signed "HoyZa." :-)
Friday, October 27, 2006
Subscribe to:
Post Comments (Atom)
1 comment:
Thank you Matthew! Thanks for the link and kind comments, and wow, thanks for blog rolling me! Wow, guess I better think of something else to post about then, huh? ;-)
Yeah, those are pretty much my points. I want to work agile in a place that is not agile, but I'm beginning to think they would like the ideas here if they knew about them. There is a lot of common sense here about how to do software well, in ways that will work practically. It seems a point of pride here (ANGEL Learning) how closely, and really collaboratively, we work with our customers. Pride in the close and open relationships we have with them.
You make an excellent point about using agile/xp techniques because they reflect an organizations underlying values, or a genuine desire to do software better, rather than just throwing them all together to see if it helps. "Cargo cult software engineering" -- I like that! ;-) Just displaying the trappings of agile is not really going to help, I could not agree more.
It's not important to be able to proudly say "we are Agile". What is important is if agile just describes well how we work. And that is "more or less", yes. Using the techiniques that help and leaving any that don't, which as I understand is how any methodology should be implemented. Not lock, stock, and barrel, one size fits all, and imposed from the top down, as they too often seem to be.
Post a Comment