It is true, agile may not sound innovative anymore. Nevertheless, the principles are sound. If you care about your craft, keep practicing it.
edit:grammar
I don't know if I've ever been wholly convinced that certifications do more good than harm, especially in Soft things like Product Management (as opposed to something more clear, like plumbing).
Certifications (well, depend on the cert) for "soft things" are generally used by companies to get everyone talking the same language.
I'm a code/architect guy, with a make-it-work-now personality, so I'm more used to say "let's get Bob to fix this shit".
But my girlfriend is into IT process, and we're getting an ITIL certification together, because where she works (HP) they do a lot of ITIL. So she and her team talk about how the "Service Desk" should scalate "Change" to a "Problem" or "Incident", which I think are all funny words, but helps everyone to get into the same flow together and makes communication easier.
I like my way (d'uh), but that's because my way of doing things have worked so far for my things that needed to be done (pretty philosofical statement!), while obviously her ways have worked for her. In the end, if it's delivered, and the client pay and he's happy, I could care less what's the terminology.
In short: everyone has co-opted the names! That's not doom. Just chalk up another victory and let's come up with some more names. Pair those with versions of the practices that big companies will be too corpulent to implement, and let's have another go!
The author is as bad as those he makes fun of -- he has a list of things that obviously CAN'T be agile and uses that as a discussion point. Agile RUP? Been around for years. The true-blue RUP guys will tell you RUP has always been agile, it's just never practiced that way and the corporate pointy-heads make it into a monster. Agile Maturity Model? Lots of companies already have one. Maturity model just means some way of measuring how well the teams are doing. Certification? Heck, this certification bandwagon has always been lucrative, and now it's just getting worse.
Agile works because agile has always worked, even before there was some lame-ass marketing phrase called "agile". That means your grand-dad working on the Apollo moon shot probably used some agile techniques, as did guys on the Manhattan project.
He's absolutely right that corporate America is killing agile. But they've been killing agile for so long it isn't funny. This is a problem that has to do with really smart people and their desire to measure and control. It's really a problem with, guess what, us. As technology wonks we're the first to want to create a new metric or standardize something that doesn't need standardizing.
As for the proliferation of certifications, do what I do: just say no. I'm not going to play that game. When you ask me about agile, I'll happily share the actual projects and work I produced, but I'm not going to spend good money buying useless pieces of paper.
Start with the wiki page but remember that the one thing that all agile teams do is _adapt_. So be careful you don't get in the mindset of "I have to do X, Y, and Z and then I'll be agile" Better to think of it like "I see from the literature and people I trust that X, Y, and Z work for a lot of teams. I should really try that on my next team to see how it does"
The worst offenders are people who are successful! Then they take the X, Y, and Z as gospel and try to make them fit on their next team, whether or not they make any sense at all. We get this "well, my last team was agile and we did X, so we absolutely must do X on this project!" That attitude usually ticks everybody off and is counter-productive. Don't be an agile zealot! It's a buffet, not a happy meal.
Remember -- always adapt, and use the literature as starting points for things to try on each project. Read lightly and spend more time experimenting and evolving. Agile is really simple, but people try very hard to make it complicated and screw it up. Beats me why.
"Agile works because agile has always worked, even before there was some lame-ass marketing phrase called "agile". That means your grand-dad working on the Apollo moon shot probably used some agile techniques, as did guys on the Manhattan project."
OTOH, one problem with "agile" is that it tries to blur the line between itself and anything that was successful. Hence there is never a failed agile project.
"Oh the project failed? that because they didn't do "true" agile."
or the even more insidious, "Oh Toyota has great production processes? That is because they are "agile"
or "The Apollo moon shot went off well? they must have been agile. "
In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen.
"No True Scotsman" is a constantly recurring theme in the various agile mailing lists.
A "methodology" that never fails, and never acknowledges failure (except when practitioners do something that isn't "true agile"), is something that is very suspicious from an engineers pov.
This is not to invalidate your (Daniel's) many good points. Just something to be aware of, especially when dealing with people who vend development methodologies for a living. Most of the agile "gurus" can't code for nuts.
"In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen."
Yes -- you are absolutely correct.
To be specific: agile is incremental, iterative development, emphasizing the social aspect instead of the process measurement aspect of technology development. Agile is also a marketing term and not a branded, concrete system of anything. People have books on agile everything. Because of that, it can best be thought of as an ideal that teams strive to reach.
This means that there is no "pure" agile team. Instead you are looking for agile aspects of a team -- which means that most high-performing teams are going to have some. Agile best practices are simply those practices which most teams will naturally evolve over time. You can pick them up and save yourself some evolution.
"Most of the agile "gurus" can't code for nuts."
A lot of them haven't coded in years, if ever. They're professional teachers, or book writers, or "celebrities". I'm working now with a large corporation as an agile coach (I code regularly) and we've got a couple of guys who are hard-core TDD zealots. Problem is, none of them have coded a real honest-to-god production system in the last five or ten years. One guy has never coded. Yet they're the first ones to tell other teams what they need to do to improve. They read a book or attend a seminar (usually by some other guy who hasn't coded in years) and suddenly they know what everybody else should be doing. That's not saying that TDD won't work -- it's saying that to help a team you really need to be actively working on a team and not be a wonk. I remain dubious of TDD, but that's me.
Beware of well meaning teachers and non-hackers who start getting the agile religion.
14 comments
[ 3.4 ms ] story [ 135 ms ] threadI'm a code/architect guy, with a make-it-work-now personality, so I'm more used to say "let's get Bob to fix this shit".
But my girlfriend is into IT process, and we're getting an ITIL certification together, because where she works (HP) they do a lot of ITIL. So she and her team talk about how the "Service Desk" should scalate "Change" to a "Problem" or "Incident", which I think are all funny words, but helps everyone to get into the same flow together and makes communication easier.
I like my way (d'uh), but that's because my way of doing things have worked so far for my things that needed to be done (pretty philosofical statement!), while obviously her ways have worked for her. In the end, if it's delivered, and the client pay and he's happy, I could care less what's the terminology.
The author is as bad as those he makes fun of -- he has a list of things that obviously CAN'T be agile and uses that as a discussion point. Agile RUP? Been around for years. The true-blue RUP guys will tell you RUP has always been agile, it's just never practiced that way and the corporate pointy-heads make it into a monster. Agile Maturity Model? Lots of companies already have one. Maturity model just means some way of measuring how well the teams are doing. Certification? Heck, this certification bandwagon has always been lucrative, and now it's just getting worse.
Agile works because agile has always worked, even before there was some lame-ass marketing phrase called "agile". That means your grand-dad working on the Apollo moon shot probably used some agile techniques, as did guys on the Manhattan project.
He's absolutely right that corporate America is killing agile. But they've been killing agile for so long it isn't funny. This is a problem that has to do with really smart people and their desire to measure and control. It's really a problem with, guess what, us. As technology wonks we're the first to want to create a new metric or standardize something that doesn't need standardizing.
As for the proliferation of certifications, do what I do: just say no. I'm not going to play that game. When you ask me about agile, I'll happily share the actual projects and work I produced, but I'm not going to spend good money buying useless pieces of paper.
You don't really need a book. The Agile page on Wikipedia and links to the descriptions of the different flavors are all you need.
The worst offenders are people who are successful! Then they take the X, Y, and Z as gospel and try to make them fit on their next team, whether or not they make any sense at all. We get this "well, my last team was agile and we did X, so we absolutely must do X on this project!" That attitude usually ticks everybody off and is counter-productive. Don't be an agile zealot! It's a buffet, not a happy meal.
Remember -- always adapt, and use the literature as starting points for things to try on each project. Read lightly and spend more time experimenting and evolving. Agile is really simple, but people try very hard to make it complicated and screw it up. Beats me why.
OTOH, one problem with "agile" is that it tries to blur the line between itself and anything that was successful. Hence there is never a failed agile project.
"Oh the project failed? that because they didn't do "true" agile."
or the even more insidious, "Oh Toyota has great production processes? That is because they are "agile"
or "The Apollo moon shot went off well? they must have been agile. "
In most cases, such similarity evolves from having overbroad generalizations and/or squinting from various angles till some vague similarity is seen.
"No True Scotsman" is a constantly recurring theme in the various agile mailing lists.
A "methodology" that never fails, and never acknowledges failure (except when practitioners do something that isn't "true agile"), is something that is very suspicious from an engineers pov.
This is not to invalidate your (Daniel's) many good points. Just something to be aware of, especially when dealing with people who vend development methodologies for a living. Most of the agile "gurus" can't code for nuts.
Yes -- you are absolutely correct.
To be specific: agile is incremental, iterative development, emphasizing the social aspect instead of the process measurement aspect of technology development. Agile is also a marketing term and not a branded, concrete system of anything. People have books on agile everything. Because of that, it can best be thought of as an ideal that teams strive to reach.
This means that there is no "pure" agile team. Instead you are looking for agile aspects of a team -- which means that most high-performing teams are going to have some. Agile best practices are simply those practices which most teams will naturally evolve over time. You can pick them up and save yourself some evolution.
"Most of the agile "gurus" can't code for nuts."
A lot of them haven't coded in years, if ever. They're professional teachers, or book writers, or "celebrities". I'm working now with a large corporation as an agile coach (I code regularly) and we've got a couple of guys who are hard-core TDD zealots. Problem is, none of them have coded a real honest-to-god production system in the last five or ten years. One guy has never coded. Yet they're the first ones to tell other teams what they need to do to improve. They read a book or attend a seminar (usually by some other guy who hasn't coded in years) and suddenly they know what everybody else should be doing. That's not saying that TDD won't work -- it's saying that to help a team you really need to be actively working on a team and not be a wonk. I remain dubious of TDD, but that's me.
Beware of well meaning teachers and non-hackers who start getting the agile religion.