Steve Yegge's
blog post titled "Good Agile, Bad Agile" seems to have ignited one of those periodic feeding frenzies in the blogosphere. The comparison he makes between Agile and Scientology seems to have touched a nerve in many "agilists". The comments on Steve's post reveal a good deal of defensiveness, google envy and the occasional reasoned response.
Summarizing Steve's "anti agile" points (from a very long post), he says
- The Chrysler Project, which was the exemplar for agile projects failed badly.
- Mandatory 100% pairing sucks bigtime.
- Agile isn't scientific. (at best, any proof for "improved productivity" is anecdotal).
- There are a lot of flaky "agilists" trying to be "coaches" and sell books and seminars.
- These "seminar agilists" create an artificially polarized world where any process that isn't Agile(TM) is "waterfall" or "cowboy".
- Agile is very date driven, ignoring the human variations in productivity.
- If anyone puts forward an alternative process , the "defenders" of agile use one of two responses to oppose it
- "all the good stuff he described is really Agile"
- "all the bad stuff he described is the fault of the team's execution of the process"
Now all of this is true and valid, thoughtful criticism. And reasonable people can disagree and debate rationally. So why do people react so violently?
I believe this massive reaction came about because Steve called Google's development process "Good Agile" and what we know as "standard Agile", "Bad Agile".
More than the "truth" of these assertions, what is highly amusing is the outraged reactions of people who make a living selling "Agile solutions", either as individuals or as consulting companies. Like Islamist radicals opposing the "Islam is a violent religion" meme by burning embassies, issuing death threats and destroying public property, anyone who calls Steve names and say things like "but we have waaay dumber developers than Google so we have to make do with Agile" really undermine their own cause.
I was very much on the sidelines (I love watching a clueless mob tear itself apart as much as anyone else) till a
blog entry by (ThoughtWorker) Obie Fernandez claimed that the "real benefit" of Pairing was
"... pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit. When you're pairing, you simply HAVE to work all day...."
and
"As far as I'm concerned, all the other benefits you get from pairing like continuous review and knowledge-sharing are just gravy."
WTF?!!! And when I commented that "If the key benefit of pairing is that it keeps otherwise lazy developers' nose to their keyboards, the company needs to look more carefully at the type of people it hires than at its development methodology."
Obie said I was "sniping" and that the comment upset him.
Whoops! I didn't mean to "snipe" or otherwise upset anyone, least of all Obie. I was just saying that "you'll waste a lot of time unless you are pairing" is an incredibly feeble argument for the practice.
In my own experience, the benefits of Pairing (which does have benefits and drawbacks, like any other development practice) come from what Obie says is "gravy" - continous review and knowledge sharing.
In his latest blog entry Obie makes
an even more exotic claim - apparently Attention Deficit Disorder (ADD)is rampant in our workplaces and most of us suffer from it without knowing we do. And "pairing" apparently serves as an antidote. Whoa!!
"It's not about laziness -- it's about the predominance of ATTENTION DEFICIT DISORDER, whether diagnosed or not, acknowledged or not, ADD is affecting almost all of us, probably as a result of the tons of distractions that we are subjected to on a constant basis. Working on something with a partner works miracles for postponing non-essential distractions such as IMs and checking emails and blogs. Don't suffer from ADD at all? Well, good for you. Your type of people will be in the minority soon if you aren't already."
yes, Obie, you are right - partially. I don't suffer from ADD. :-) .That's the part you got right. Thanks for the concern! I can focus for however long I want on my work without being compelled to "check email or blogs".
"...Ohhh the temptation ... all those mails and blog entries ... They are CALLING to me .... can ... not ... resist ... I still have to another 10 minutes to finish my "daily Solid Eight Hours"... All these distractions .. Help meeeeee!! ...[voice fades]..."
Yeah right!
In my opinion, anyone who is seduced by these apparent "distractions" to the point where you can't get work done unless a "pairing partner" keeps you on your toes is in the wrong profession.
And oh, according to wikipedia ,
"Attention-deficit/hyperactivity disorder (ADHD) (sometimes referred to as ADD) is thought to be a neurological disorder, always present from childhood, which manifests itself with symptoms such as hyperactivity, forgetfulness, poor impulse control, and distractibility.[2] In neurological pathology, ADHD is currently considered to be a chronic syndrome for which no medical cure is available. Both children and adults may present with ADHD, which is believed to affect between 3-5% of the population."
So, anyway, I (as in "your type of people" :-) )am not in "the minority" after all. Most people in the world do
NOT suffer from ADD. Thank God!
more.
"ADHD is today generally regarded to be a non-curable neurological disorder for which, however, a wide range of effective treatments are available. Methods of treatment usually involve some combination of medication, psychotherapy, and other techniques".
Hmm we should probably add "pairing" to that list? :-) "The Agile Psychotherapist"... sounds like a killer book title.
Yeah Ok . Enough "sniping" at Obie.
Ok folks, listen up. Agile/XP is no panacea. It is just what worked for Kent Beck in certain contexts. The fact that there are a whole bunch of "agile consultants" both individuals and companies, out to part you from your money in exchange for the arcana of "True Agile" does not absolve you for thinking for yourselves.
lookup "Scrum" for an extraordinarily cynical MultiLevel Marketing scam. "Certified ScrumMaster" indeed! This is where the comparisons with Scientology gain traction.
Repeat.There is no silver bullet. The nearest to one is "hire good people and let them work the best way they can" . What they come up with will often look very different from "True Agile". If that is "Googlism" then so be it. Nuff Said.
And Oh, Steve, keep writing!
17 comments:
ROTFL !
gv
Actually the Certified Scrum Master thing is sort of an inside joke on certifications in general, and they even include a secret handshake.
Ravi, I'm sorry that I used the word sniping in relation to your comments. It carries an unnecessarily harsh and adverserial connotation. Please accept my apologies for that. In regards to your comments in this post, I have to say that I understand your views and agree with many of them. I stand by my opinion that pair-programming results in higher-productivity developers, and that is based on years of direct experience and observation (having caught the XP bug in 2000!)
I 100% agree with you that there aren't any silver bullets and in particular with your closing comments that the closest to one is to higher the best and brightest and let them sort out how they work best.
Obie,
dude! No harm done! I did NOT take offense to "sniping". I was a bit surprised, but that's all. No worries.
I thoroughly enjoy all your posts, even when I don't agree with them 100%. (And that's how it should be.) I always learn something I didn't know. (about ADD in this case for e.g.). So just write the way you see it :-)
I agree with you that Pair Programming does help tremendously as long as the people involved **choose** the practice.
I've noticed a tendency among those practising "agile" to get shrill and religious (I blogged about this before) and this is the only facet I oppose.
I used to be a "strict XP" type of person till I encountered problems which it couldn't tackle very well.
So... nutshell, I didn't take any offense at what you said. You don't need to apologize. :-)
Too bad I missed meeting you when you were in India. The next time we are in the same geographical location, beer is on me!
Cheers
Ravi, unfortunately I think you're right in general about your criticisms. In general I think agile is a set of very useful techniques, but there does seem to be a lot of flakiness being introduced. I think it's something that goes along with growth and success. I am sure that scientology was a wise and profound practice as well when it first started out, before all the movie stars jumped on the bandwagon! :) Ok, maybe not! :)
Ravi are you a workaholic ?
@Pranab
No I am not a workaholic :-) I can focus as long as I *want to*. How is that "woprkaholism"?
@James,
Manoj has offered to explain googlism and google envy. :-) So I'll just let him do it.
There is a general impression (especially among tech workers) that Google hires highly skilled professionals (including their chefs). Their work environment has also drawn praise for employee-friendliness and creature and intellectual comforts. People working in "standard" tech companies cannot help envying their more fortunate brethren who work for Google. Hence the phrase "Google envy".
Steve Yegge, who Ravi refers to in his blog, explained that Google follows a way or working which is significantly different from a currently popular way to work known as "XP". This contrasting methodology used by Google is referred to as "googlism". As you can see this is more a way of speaking rather than a definition.
A very amusing post, Ravi! You've long provided a voice of caution against slipping into a quasi-religious frame of mind about agile development. That's necessary, and becoming more necessary as the word "agile" becomes more widely used and abused for all sorts of purposes. Just be careful that you don't throw out the baby with the bathwater.
I can appreciate your passion, but when you resort to ridiculous extreme statements yourself, it weakens your argument. (Only worked for Kent Beck? Hmm.)
Not surprisingly, I disagree with your summary of seven points from Steve's piece, and with your assessment that "all of this is true." Steve is a very effective writer, and he's saying things you want to hear. Is that the definition of "truth?"
#1. The team on the "Chrysler Project" used the project as a proving ground for some of their ideas, some of which eventually made their way into the formal definition of XP. It's not the "exemplar for agile projects". That sort of statement is every bit as "religious" as the silver bullet promises you criticize. It also ignores learning curve time. That team was experimenting with new methods. Naturally, they didn't work perfectly the first time. NASA's first rockets fell over, exploded, or fell over and then exploded. The Saturn V worked perfectly every time. (Unless you're going to claim that was all staged. Maybe it's only a paper moon, after all.)
#2. Pairing isn't for everyone. It "sucks bigtime" from the point of view of people for whom it isn't. Why should that surprise anyone? Fortunately, there's plenty of other work around. Fortunately, too, there are plenty of people who enjoy pairing. Besides, agile doesn't require pairing. XP calls for pairing, but that's only one agile methodology. Also, I know of no project on which everyone paired 100% of the time; and, unlike you, I've worked on many projects that used XP rigorously. The purpose of the "100% pairing" statement is to encourage people to think of pairing as the norm rather than the exception. Rather than struggling to think of a reason to pair, the preference is to struggle to think of a reason not to pair. The Pairing Police won't come and arrest you if you choose to work independently on some task. After all, agile isn't about adhering mindlessly to some predefined process.
#3. Agile isn't scientific. Neither is any other software process or methodology. Some pretend to be based on "science", like CMMI and so forth. You can say agile isn't scientific, but you've got nothing scientific to offer as an alternative, so this is a non-argument. It's just white noise.
#4. Yep. Be wary of them, but also be wary of your own tendency to dismiss everything labeled "agile" just because of them. It demonstrates poor critical thinking skills. A more effective approach would be to recognize and dismiss the snake oil salesmen, but still to understand and use the practical ideas from agile.
#5. Yep. But the Agile(TM) part is a strawman. There's no such thing. There are branded methodologies and tools that call themselves agile, and maybe some of them really are, but agile itself is more a mindset about approaching problems flexibly than it is a rigid specification.
#6. Completely bass ackwards. Agile and lean processes and methdologies are based on human factors. Others, like traditional SDLC methodologies, take a mechanical view of workers, treating them as interchangable machine parts. They are based on the idea that anyone can succeed if only they follow the process as defined. It's the process that results in success, and the people are just trained monkeys.
That's the diametric opposite of agile thinking, which explicitly values people over process. A defined process may be useful, since it synthesizes the collective experience of many people in many projects so that we need not reinvent every wheel in a vain attempt to be "free thinkers", but only when applied in the right circumstances and then only when used correctly. In other words, a process is not a prison within which developers must toil, but a tool in the hands of the developers. If you were building something physical with tools in your garage, it's unlikely all the parts would fit together perfectly. You'd probably have to bend something a bit here, cut a notch there, and so forth. And you'd be perfectly free to cut yourself with your tools, if you chose to use them wrong. In the end, if you followed the instructions but never produced the thing you wanted to build, then the whole exercise was a waste. The point is that if the project fails, we won't get marks for saying we followed the process to the letter. Agile teams have the freedom to adjust the process when necessary, always keeping the goal in mind.
But to adjust a process effectively, people must understand how and why the guidelines defined by the process actually work. If they take an "anything goes" attitude because they think their environment is so utterly different from any other that they can't apply any lessons learned in other places, they're liable to waste a great deal of time needlessly re-solving problems that already have known solutions. All the different "contexts" you talk about are within a common general area - software development. They're not all totally unique universes. We can address the differences between one "context" and another more effectively by adapting a proven process than by starting from scratch on every project, because chances are we only need to adapt a few minor things to make it work. Throwing the whole thing away and starting over is just overkill.
#7. (1) The good stuff Steve described really is agile. At least, it's consistent with agile thinking. When you pretend that saying so is somehow a criticism of agilists, it's pretty weak logic. It only suggests you can't tolerate the thought that anything associated with the Hated Word might actually be positive. (2) Any tool can be used wrong, with predictable results.
Dave ,
making some weak arguments yourself aren't you ?
e.g. you say I said/implied "(Only worked for Kent Beck? Hmm.)" ..
when what I *actually* said was
"Ok folks, listen up. Agile/XP is no panacea. It is just what worked for Kent Beck in certain contexts."
how does that read as "XP worked only for kent " ?
bleh!
an example to make it clear.
"Running 5 miles in the morning works for me"
Add a "only" before the "for" and you have a different meaning.
Don't put words in my mouth/ add them to my sentences?
Thanks!
You say,
"I disagree with your summary of seven points from Steve's piece, and with your assessment that "all of this is true."
This is perfectly fine. Disagreement is the source of wisdom.
But "Steve is a very effective writer, and he's saying things you want to hear. Is that the definition of "truth?" is not.
You presume I am some sort of idiot who can't recognize being told what I "want to hear" (and how do you know what I "want to hear" anyway? A bit of presumption somewhere in there?
for "all of this is true" please interpret "true" as "true enough to make Steve's points valid enough to be worthy of consideration rather then dismissal " rather than "true always under all circumstances".
I will go through each of your points, subtract the personal "sniping" (sorry Obie couldn't resist :-D ) like ("It demonstrates poor critical thinking skills. " - when what you say i said is nothing like what i actually said) and address the remaining core.
let's try that
1' chrysler failure
ok let's see. Who defines "failure"?
As far as I know if your clients pay you a lot of money, are unhappy withthe delivered code,throw you out, scrap the system, attempts a rewrite, and makes jokes about xp being used in chrysler "once and only once" it *is* a failure, irrespective of the spin put on it by people who try to sell books and/or consulting services *AND* (boolean AND) point to chrysler as a "succesfull" project. See the "Chrysler was a success" slant in the **initial** books and articles about XP. Now the position has changed to "Xp REALLY worked but the morons at Chrysler don't get it and even if Chrysler failed XP/Agile works anyways"
Your convoluted arguments to establish the chrysler project as a "learning" process(and therefore a success) is weak. EVERY project , whether sucess or failure is a "learning process" (assuming intelligent people working on the project) as is EVERY rocket launch.
A particular rocket that explodes *is* a failure (unless the explosion was preplanned) , though it may provide "learning". It may be a *step* towards success but THAT launch is a failure (unless the failure was expected and had no adverse impact).
But yes, you have the freedom to believe that the Chrysler project was a stunning success or a "learning process" or whatever. *I* (and Steve I presume) believe it was a failure.
Point 2) I said (*that Steve said* )
"***mandatory*** **100%** pairing sucks big time".
When you quoted me in your response you left out the "mandatory" and 100 %. nice! "Some people" may like mandatory 100% pairing. Some people like being chained to a wall and whipped by fat women. So?
I was saying "Steve says mandatory 100% pairing sucks... and I (Ravi) agree".
That does not invalidate any masochists out there who would enjoy **mandated** **100 % ** pairing.
*I* certainly wouldn't enjoy mandated anything.
I'll rely on my own contextual judgement thank you.
3) Steve says Agile isn't scientific and I agree that is a valid point. I agree with you when I say that other methodolgies don't have any scientific prrof either. But that is exactly my point! Agile is just as good ..***or bad*** ... *from a proof pov* as any other methodology. All methodologies work for certain people n certain contexts. There is nothing that makes agile "truer" than anything else.
4) (I say ) Steve says 'There are a lot of flaky "agilists" trying to be "coaches" and sell books and seminars.' and I (ravi) agree.
I said nothing about what to do about these snake oil folks. I never said *all* agilists are flaky. Again you assign intent to me and you respond to your own interpretation of what you think I think (throw baby out with the bathwater), rather than what i actually said .
Iow i think it is true that there ARE a lot of flaky agilist snake oil salesmen. I did NOT say every agilist is flaky what exactly are you responding to?
5) (I say ) Steve says "These "seminar agilists" create an artificially polarized world where any process that isn't Agile(TM) is "waterfall" or "cowboy" and I (Ravi) agree.
where "these 'seminar agilists' " == the snake oil salesmen identified in the pevious point . Iow I am saying
"these snake oil salesmen would have you believe that there is a true agile only they know and you have to pay them for the "One True Way""
Since I never said that every single person who calls himself an agilist belongs to this subset of phonies , I fail to understand what you are disagreeing with. I agree with you that "agile itself is more a mindset about approaching problems flexibly than it is a rigid specification".
6)I say Steve says Agile is very date driven, ignoring the human variations in productivity.
No one (neither me nor steve) contrasted this with SDLC. Thus all your criticisms of sdlc and the argument that agile is superior to sdlc/whatver is *irrelevant* to this discussion. SDLC is NOT what is being compared to agile.
Steve contrasted agile with the *development process in Google*.
Compared to the process at google(as outlined by steve) agile is indeed "date driven" (with estimates and restimates and fixed duration iterations and release dates and so on etc). I would be interested in your reasoning that leads you to conclude agile is less date driven *than the process Steve outlines* .
Onwards. You say
"if they take an "anything goes" attitude because they think their environment is so utterly different from any other that they can't apply any lessons learned in other places, they're liable to waste a great deal of time needlessly re-solving problems that already have known solutions."
But that is precisely the point. Steve DOES think the environment in google is utterly differnt from the environments for which he thinks agile is suited. He thinks that if you have smart enough people, which google presumably has, they could work *totally differently* from anything "agile" and still write good code. Or are you saying that agile trumps whatever smart people think is appropriate for their environment? (the "whatever is good is actually agile" argument that steve so presciently identifies?) .
and what "lessons learned in other places" ? who decides what constitutes a "lesson" ? You ?
you say
"All the different "contexts" you talk about are within a common general area - software development. They're not all totally unique universes. We can address the differences between one "context" and another more effectively by adapting a proven process .. "
Hold!! what "proven process"?
Agile is no more "proven" than any other process Google may use. I thought you agreed that there is no "proof" for the superiority of Agile. Or are you saying that the folks at Google should adopt a process *you* think works, just becaue you think so, without any proof of any kind? Why not extend the same privilege of deciding what process to adopt or not to the folks at Google? They listen to the (snake oil) agilist blather.They read the books. They *then* reject it. Surely that is their privilege?
Let me repeat- Agile is NOT a proven process, by any agreed upon meaning of "proven". To refine that idea, It is not proven to **any greater extent** than the process Steve says the majority of googlers follow.Or are you saying that their process is "unproven"? :-) . God, I'd love to have "unproven" proceses that result in software like google's!
Agile has no "sacredness" that makes it the obvious default choice or the "process to adopt/adapt".
*You * may do that for your projects. That is your privilege. Don't force it on others or expect intelligent folks to accept it blindly.
In a nutshell, I believe you think either Steve or I am saying that Agile sucks in all circumstances. That is not what I say I am pretty sure that isn't what Steve said (but do feel free to communicate with him on what he thinks).
7) I have dealt with this before.
Obviously agile/xp/whatever works for some teams on some projects some of the time, like every other methodology out there. I have seen it work (in Thoughtworks - admittedly a conmpany on the cutting edge of agile practice and elsewhere ) *and* I have seen it fail (again in Thoughtworks AND elsewhere). So I am NOt one of those empty air heads opposing (or supporting) agile blindly.
All I am saying is, (repeating this one last time) "Think for yourself. Don't blindly trust the folks out there trying to separate you from your money by selling you books or coaching/consulting".
Thank You for your time.
Dave you say
"unlike you, I've worked on many projects that used XP rigorously"
Since you have no idea what I have worked on and whether I have or have not seen "rigorous" agile, the "unlike you" may be umm .. rude? had a bad day? :-)
>...how do you know what I "want to hear" anyway?
We have engaged in dialogue in the past.
>All methodologies work for certain people n certain contexts. There is nothing that makes agile "truer" than anything else.
Yes, that's right. That's why it's a non-argument. Repeating it again and again is just white noise.
>Iow i think it is true that there ARE a lot of flaky agilist snake oil salesmen. I did NOT say every agilist is flaky what exactly are you responding to?
Maybe it would be useful for you to ask yourself how you manage to give people like me that impression, if it isn't what you actually mean. Turning your stridency dial up to 11 doesn't seem to be doing the trick.
>I agree with you that "agile itself is more a mindset about approaching problems flexibly than it is a rigid specification".
I look forward to reading evidence of that agreement in your future material.
>I say Steve says Agile is very date driven, ignoring the human variations in productivity. No one (neither me nor steve) contrasted this with SDLC.
By harping on the SDLC comparison, you are side-stepping my response to the contention that agile methods ignore human variations in productivity. I mentioned SDLC as an example of the process that really does undervalue the human factor. I chose an example that neither you nor Steve had brought up. My bad...I didn't know that was a rule.
When you say "date-driven" I assume it's a reference to the idea of "time-boxing", which is basic to agile methods. In reference to an earlier question of yours, this is one of the ways I know whether you have worked on agile projects before. You could not possibly think "time-boxing" equates to "date-driven" if you had any real experience with agile development.
>Steve DOES think the environment in google is utterly differnt from the environments for which he thinks agile is suited.
I think so, too. In a post on my own blog, I mentioned that it sounded as if agile was being introduced in a situation where there was no particular problem with the current process. When you try to solve a problem where no problem exists, all the energy you put into your "solution" has to go somewhere. Usually, it ends up breaking something else. Since Google's process was already delivering satisfactory value, there was nothing to "fix" and therefore nothing to be gained by introducing agile methods.
But I still stand by the statement that most software development is similar enough that lessons learned by other people in other environments may be very valuable to us in our own environments. That is the point you seem to have missed.
>Or are you saying that the folks at Google should adopt a process *you* think works, just becaue you think so, without any proof of any kind?
See above.
>Agile is no more "proven" than any other process Google may use. I thought you agreed that there is no "proof" for the superiority of Agile.
I don't think there is any practical value in insisting on some sort of formal "proof," mathematical or statistical, about the value of a software development process. Inevitably, some people will accept such material and others will not. I wonder if their acceptance or non-acceptance is based on an objective analysis of the information.
I have shown skeptics spreadsheets given to me by customers of successful agile projects showing the financial results over 2 to 4 years of production use of the resulting software, and they still called it "anecdotal evidence". This means that there is no form of evidence they would accept, no matter what. There's just no pleasing some people; especially people whose minds are already made up.
There is plenty of empirical evidence that agile methods work well when applied to the right sorts of projects and when applied correctly. I have said the same thing many times, and your response always portrays me as some sort of evangelist trying to force people to do things in some particular way. Funny how people can latch onto a word or name, like "agile" or "Dave", and define it in any way they choose.
The odd thing about your characterization of me is that I actually work as an agile coach in my day job, and I never force anyone to do anything. My approach is to show them how a practice works and what its results are. Then they are in a position to make an informed professional decision about whether and when to apply that practice. Unless a person has had the opportunity to apply one of these practices correctly, with guidance, and to do it enough to see the benefits begin to materialize, they really aren't in a position to make an informed judgment about the value of the practice. They end up just ranting and raving.
Our statements appear to be more or less equivalent, but for some reason you only accept them when they come from your keyboard, and not mine. This is a great way to alienate your professional peers.
I know that agile methods are not proven to your personal satisfaction. You have made that abundantly clear.
>Let me repeat- Agile is NOT a proven process, by any agreed upon meaning of "proven".
Of course you repeat that. You have repeated it many times. You will repeat it many more. It is not a proven process by any meaning you personally accept.
>Don't force it on others or expect intelligent folks to accept it blindly.
Who said anything about forcing? Only you, in describing your strawman. I wouldn't expect intelligent folks to accept it blindly. I wouldn't expect blind folks to accept it intelligently, either.
>I have dealt with this before.
Dealt with it, or merely repeated a practiced mantra?
>All I am saying is, (repeating this one last time)
[biting my tongue]
>"Think for yourself. Don't blindly trust the folks out there trying to separate you from your money by selling you books or coaching/consulting".
That is excellent advice.
It's ironic that you don't see the beam in your own eye.
>>...how do you know what I "want to hear" anyway?
>We have engaged in dialogue in the past.
Hmm and this gives you telepathy! nice :-) afaik our "dialogue" has consisted of about 3 responses to blogposts (including this one). That is enough to enable you to predict my thnking. hmm fine , whatever...
>>All methodologies work for certain people in certain contexts. There is nothing that makes agile "truer" than anything else.
>Yes, that's right. That's why it's a non-argument. Repeating it again and again is just white noise.
Right. So Agile can be ignored etc for a better process. That's what Steve said! Someone was speaking of "proven processes which should be adapted etc" forgive my ignorance :-)
>>Iow i think it is true that there ARE a lot of flaky agilist snake oil salesmen. I did NOT say every agilist is flaky what exactly are you responding to?
>Maybe it would be useful for you to ask yourself how you manage to give people like me that impression, if it isn't what you actually mean. Turning your stridency dial up to 11 doesn't seem to be doing the trick.
pot. . kettle.. glassouses .. stones ?
seriously though you are grabbing your "impressions" froms omewhere other than what I write.
There is no stridency (except in your mind) . I give a rat's ass what "impression" you get. screw the "impression" and focus on your logic.
for some strange reason you are feeling personally attacked. Nothing I wrote in the post or any response is targeted at you . if something about "agile snake oil salesmen" hits too close for comfort, I suggest you examine * your* life.
>>I agree with you that "agile itself is more a mindset about approaching problems flexibly than it is a rigid specification".
>I look forward to reading evidence of that agreement in your future material.
I dare you to point out any disagreement with the "mindset" idea anywhere in my writing. I have always maintained that agile is NOt a rigid specification etc and have said so many times on this blog and elsewhere.
>>I say Steve says Agile is very date driven, ignoring the human variations in productivity. No one (neither me nor steve) contrasted this with SDLC.
>By harping on the SDLC comparison,
>you are side-stepping my response to the contention that agile methods ignore human variations in productivity. I mentioned SDLC as an example of the process that really does undervalue the human factor. I chose an example that neither you nor Steve had brought up.
Harping ? anyone calls you on irrelevancey and that is "harping" ? :) If I am brushing aside your weak claims of agile superiority wrt the SDLC strawman, that is because SDLC is a totally irrelvant comparison which no body (except you ) made. As Steve pointed out, "One of the (many) problems with Bad Agile is that they condescendingly lump all non-Agile development practices together into two buckets: Waterfall and Cowboy" .
Since Steve was contrasting Agile with the "google way" what matters is whether Agile undervalues "the human factor" *relative to* the process he outlined, not wrt teh sdlc.
>>When you say "date-driven" I assume it's a reference to the idea of "time-boxing", which is basic to agile methods. In reference to an earlier question of yours, this is one of the ways I know whether you have worked on agile projects before. You could not possibly think "time-boxing" equates to "date-driven" if you had any real experience with agile development.
Thank God you aren't an arbitrer of other people's experience.
again, think relatively. "date driven" == your dates drive what you work on. You might split semantic hairs about (good) "time boxed" vs "(evil) date driven.
Steve's point (whihc I agree to ) was that
"Traditional software development can safely be called Date-Oriented Programming, almost without exception.
Startup companies have a clock set by their investors and their budget. Big clients set target dates for their consultants. Sales people and product managers set target dates based on their evaluation of market conditions. ***Engineers set dates based on estimates of previous work that seems similar. ****"
that (which *is* how agile/xp works) was the key point And he (Steve) explcitly lays out a "least enregy" model of project completion to contrast. if you have data/logic to counter his claim, let's see it.
Again you are hearing things in that no one said. Time for whisky//sleep. Come back when you are thinking clearly.
>>Steve DOES think the environment in google is utterly differnt from the environments for which he thinks agile is suited.
>>I think so, too. In a post on my own blog, I mentioned that it sounded as if agile was being introduced in a situation where there was no particular problem with the current process. When you try to solve a problem where no problem exists, all the energy you put into your "solution" has to go somewhere. Usually, it ends up breaking something else. Since Google's process was already delivering satisfactory value, there was nothing to "fix" and therefore nothing to be gained by introducing agile methods.
*This * is an ***excellent** point. Insightful. I agree totally (fwiw).
>But I still stand by the statement that most software development is similar enough that lessons learned by other people in other environments may be very valuable to us in our own environments. That is the point you seem to have missed.
the "may" makes all the difference. In your last comment You said "We can address the differences between one "context" and another more effectively by adapting a proven process" .
That sounded like a very definite statement.
I asked "what proven process? " "what proof?"
yeah we *may* be able to. or we may not. Steve's team seems to have come down on the "may not" side. His opinion is just as valid as yours (or mine)
>>Or are you saying that the folks at Google should adopt a process *you* think works, just becaue you think so, without any proof of any kind?
>See above.
yes I don't see any answers to why you think agile is the "proven process"
whoch should be "adapted" .
>>Agile is no more "proven" than any other process Google may use. I thought you agreed that there is no "proof" for the superiority of Agile.
I
There is plenty of empirical evidence that agile methods work well *****when applied to the right sorts of projects and when applied correctly. *****
I TOTALLY agree. Steve is saying that his projects are not "of the right sort" for agile.hence, his rejection of agile is valid (granted the premise).
>>I have said the same thing many times, and your response always portrays me as some sort of evangelist trying to force people to do things in some particular way.
No "characterization as evangelist" is intended.
Why should I insult you so terribly? Where did I characterize *you* as ane "evangelist" or "forcer of people". Do show me any stament wher ei imply you are an evangelist/applier of force.
I disagree with some of what you say . I NEVER called you an evangelist or implied you were one. Again you are hearing things no one said.
>The odd thing about ****your characterization of me****
What "characterization of you"? I don't know you from Kent Beck. err. Adam.
I repeat i have NEVER charcterised you as ANYTHING. You are hearing things(again) which no one said or implied.
> is that I actually work as an agile coach in my day job, and I never force anyone to do anything. My approach is to show them how a practice works and what its results are. Then they are in a position to make an informed professional decision about whether and when to apply that practice. Unless a person has had the opportunity to apply one of these practices correctly, with guidance, and to do it enough to see the benefits begin to materialize, they really aren't in a position to make an informed judgment about the value of the practice. They end up just ranting and raving.
Again since I never claimed that you "force anyone to do anything" I don't see how your work ethic is relevant.
I know NOTHING about how you work and what is effective in your environment. If your clients are happy with what you do and their projects are more succesful, more power to you . Frankly, (from the quality of your thought , as expressed in your blog, which is all the data I have about you ) I would expect nothing less.
>Our statements appear to be more or less equivalent, but for some reason you only accept them when they come from your keyboard, and not mine. This is a great way to alienate your professional peers.
I do agree with some (most ) of what you say. I don't think we have significant disagreements about how agile should be practiced.
But yes I do disagree with you when you (a) attribute motives to me and tell me what I am thinking (b) when you imply that i said things which cannot be supported by my written statements.
Anyway if disgreements about methodologies and software practices cause "alienation", so be it. I think you are just too tired (see now Iam telling you what you *really* think) :-)
>I know that agile methods are not proven to your personal satisfaction. You have made that abundantly clear.
I don't think there can ever be a proof.We both agree that sw methodolgies are not science. We disagree on the implications of that lack of proof.
I was saying (contary to whatevr "impressions" you harvested) that agile is just as proven or unproven as anything else.
>>Let me repeat- Agile is NOT a proven process, by any agreed upon meaning of "proven".
>Of course you repeat that. You have repeated it many times. You will repeat it many more. It is not a proven process by any meaning you personally accept.
"Proof"" has a precise scientific meaning. There is no question of "personal acceptance".
And since we have laready agreed that Agile can work well in certain projects, I don't know why you are even trying to establish the "lack of proof".
Get over it.
>>I have dealt with this before.
>Dealt with it, or merely repeated a practiced mantra?
Hmm I though "agile coaches" were the mantra users? I am refusing to accept your "words of power" and calling bullshit.
>>All I am saying is, (repeating this one last time)
>[biting my tongue]
Don't bite down!! You aren't thinking clearly as it is . you wouldn't want to hurt yorself. Go take a pill.
>>"Think for yourself. Don't blindly trust the folks out there trying to separate you from your money by selling you books or coaching/consulting".
>That is excellent advice.
>It's ironic that you don't see the beam in your own eye.
beam in **my** eye? I am NOT the person selling "agile coaching" here :-).
By the grace of God I don't have to sell methodologies or buzzwords to make a living.
I am just a developer. Not a "coach" or methodologist.
Dave, this isn't going anywhere. I read and enjoy your blog. If you have nothing different (from what we've already covered) to say, its time to close this conversation.
Godspeed.
@Dave,
Just to stop this on a note of harmony..
I have NEVER targeted you as an "evangelist" or "forcer" or whatever. I get irritated when people presume to tell me what I "really" mean and what i "really" know.
Mea Culpa.
I guess.
Anyway, to the degree that any of my statements caused you distress ( I didn't intend any), I apologize.
I really appreciate the time and effort you take to respond.
I really don't have the time to pursue a flamewar. Too much work.
Hopefully we both know where we stand, and our areas of agreement and disagreement.
This thread of conversation is now closed.
Au revoir
>Where did I characterize *you* as ane "evangelist" or "forcer of people". Do show me any stament wher ei imply you are an evangelist/applier of force.
Okay.
1. "Or are you saying that the folks at Google should adopt a process *you* think works, just becaue you think so, without any proof of any kind?"
Rhetorical technique: Assertion posing as a question = implication.
2. "Hmm I though 'agile coaches' were the mantra users? I am refusing to accept your 'words of power' and calling bullshit."
The second person pronoun makes the statement personal.
>the "may" makes all the difference. In your last comment You said "We can address the differences between one 'context' and another more effectively by adapting a proven process" .
Exactly. Adapting (adjusting intelligently to fit the circumstances), not adopting (using as-is without thinking about it). It's the old 80/20 rule. There's no need to start entirely from scratch every single time.
I'm glad we agree on basics:
>>Paraphrased: Don't fix what ain't broke.
>*This * is an ***excellent** point. Insightful. I agree totally (fwiw).
>>There is plenty of empirical evidence that agile methods work well *****when applied to the right sorts of projects and when applied correctly. *****
>I TOTALLY agree.
>I do agree with some (most ) of what you say. I don't think we have significant disagreements about how agile should be practiced.
I'm sure we agree on fundamentals. That's why it's worth my time to participate in this discussion. It would be a shame to dismiss useful practices just as a reaction to sales hype or evangelism. The so-called agile backlash that's going on seems to me an overreaction to that problem.
>Frankly, (from the quality of your thought , as expressed in your blog, which is all the data I have about you ) I would expect nothing less.
Wow. An unexpected compliment. Thanks. Of course the feeling is mutual, or I wouldn't have been reading your blog in the first place.
I think you and I, the agile community, the folks at pliantalliance, and those who talk about FlexDev, all have the same values and goals in mind. It's wasteful and counterproductive for us to engage in a circular argument about words.
Too bad you've decided to terminate this thread of conversation, just when we were beginning to get somewhere.
Ciao.
@dave,
I'll let you have the last word. Your comment has been posted sans editing or a response.
It is quite late here half way round the world, so ciao and bonne nuit.
:-)
Ravi,
I see that the usual quota of dimwits have descended on your blog!
I admire your patience in trying to engage obvious trolls but perhaps you should just killfile them?
Post a Comment