| Pages: 1 2 3 |
keithb
Keith Braithwaite
Member
Posts: 19
Registered: 27 Sep 06
Location: London
Member Is Offline
|
![[*]](./images/grass/default_icon.gif) posted on 27 Sep 06 at 10:19 AM |
|
|
Where does this strength of negative response come from?
Just came across (and commented on) this blog post: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html I thought at first that it might be some subtle form of
satire, but apparently it's scincere and really quite venomous in places.
Why is this sort of thing still getting published? Who is doing the "bad Agile" that's causing relatively high profile developers like Mr Yegge to
write things like this?
Keith
Nothing I post here should be taken as a statement of Zuhlke policy
|
|
|
adrianh
Member
Posts: 4
Registered: 05 Sep 06
Location: UK
Member Is Offline
|
| posted on 27 Sep 06 at 02:26 PM |
|
|
| Quote: | Who is doing the "bad Agile" that's causing relatively high profile developers like Mr Yegge to write things like this?
|
I'm seeing more people talking and doing "bad agile" now not less. Popularity is breeding a whole class of people who are adding the buzzword to
their list with little or no understanding of what it involves... causing no end of pain for the folk who follow in their wake.
I'm not entirely sure if this is a better problem than the "huh?" response of a couple of years back :-)
|
|
|
wpietri
Member
Posts: 16
Registered: 05 Sep 06
Location: San Francisco, California
Member Is Offline
|
| posted on 27 Sep 06 at 03:42 PM |
|
|
I didn't read the whole thing, but I think some of the guy's emotional reaction is legitimate, even if a number of his points are actually
incorrect.
First, there has been a lot of hype around XP and agile methods. Extreme Programming is a great name for grabbing attention, and I'm sure Kent meant
well with it, as did promoters like myself who were VERY EXCITED to have a process that actually worked and was generally fun. Many people have a
natural and useful allergy to the latest fad. That may mean they miss things of substance, but it also lets them avoid a lot of junk. Had I heard
about XP through the press rather than through wandering into a JavaOne session where it was mentioned as a side note, I probably would have been
biased against it, too.
Second, a lot of companies really are applying agile methods in a top-down, Taylorist fashion that I think is antithetical to what agile methods are
really about. Often that's because they don't have more than a shallow understanding of agility and ignore the required culture changes. It's no
wonder that people in those organizations see it as Yet Another Management Fad. They're right: in those organizations, it is.
And third, a lot of people are doing what they were doing before and calling it "agile", one of what I'm sure are a long string of buzzwords meant
to distract from the actual situation.
So although I think he's wrong about agile methods, like Adrian I think people can reasonably have those opinions.
|
|
|
steve.freeman
Steve Freeman
Member
Posts: 3
Registered: 10 Sep 06
Location: London
Member Is Offline
|
| posted on 27 Sep 06 at 04:52 PM |
|
|
The irony is that the gossip from his employer is their ability to ship is not as golden as he makes out (surprised?). They have extraordinarily
clever people working there, but that's not always the same as the ability to get to production.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 28 Sep 06 at 06:48 AM |
|
|
While people don't understand what's going on, we can expect 'unenlightened bad' and 'unenlightened good' reports of agile
approaches. Where 'agile' is being done in an unenlightened environment we can expect 'bad agile'.
Unfortunately, talking about 'enlightenment' will make us sound like we're selling a religion. We need to get the message across, agile is not
about belief. It doesn't rely on belief to work. It relies on doing the right things for the situation; it's knowledge based. And since we cannot
rely on folk doing what's right for the situation all the time, we need to keep inspecting and adapting; keep increasing our knowledge, keep
increasing our ability to recognise 'not right'.
Being knowledge based is not a good idea to have to sell, because it highlights the unfortunate reality that the requisite knowledge is in short
supply. It's easier for somebody to rubbish the message than for them to take it to heart and then have to catch up on all the knowledge.
An unfortunate side effect of this is that it may well be that those teams who have already made it to 'good agile' are the ones who started with a
high knowledge quotient; the late majority and laggards might have a seriously big learning curve. We're in for "Interesting Times".
Paul Oldfield
Capgemini, Telford UK
|
|
|
gishu
Member
Posts: 27
Registered: 05 Sep 06
Location: India
Member Is Offline
Mood: Comfortably Dumb
|
| posted on 28 Sep 06 at 07:46 AM |
|
|
But as the author says..
Agile can't take the successes and blame the failures on the bumbling leads, claiming that they should know better.
We need to show that this is where you went wrong and this is how you can improve next time. Not sure though that would make a big diff coz a botched
project would trigger eradication of any remaining pro-agile feelings in the organization.
Given all the facts, numbers, processes in the world, every decision boils down to a judgment call.
|
|
|
gdinwiddie
Member
Posts: 40
Registered: 05 Sep 06
Location: Maryland
Member Is Offline
Mood: hunky-dory
|
| posted on 28 Sep 06 at 12:01 PM |
|
|
| Quote: | Originally posted by gishu
But as the author says..
Agile can't take the successes and blame the failures on the bumbling leads, claiming that they should know better.
We need to show that this is where you went wrong and this is how you can improve next time. Not sure though that would make a big diff coz a botched
project would trigger eradication of any remaining pro-agile feelings in the organization. |
I can't help but thinking that "showing that this is where you went wrong" is a rather non-agile way of approaching it. Granted, it's something I
would automatically do, myself, but I'm trying to get better. I don't think that you can hand people a new way of doing things. You
can help them discover it.
As Mary Poppendieck said in another forum topic, "lean is all about engaging ordinary workers deeply in designing and doing their jobs."
|
|
|
debhart
Member
Posts: 72
Registered: 04 Sep 06
Location: Toronto, Ontario
Member Is Offline
|
| posted on 29 Sep 06 at 07:27 AM |
|
|
Summary of the looooong Yegge blog entry on Bad Agile
For those of you with jobs :-) who don't have all day to read, you might like to see the one-page summary of Steve Yegge's "Good Agile, Bad Agile"
here...
Opinion: Take Agile Off Your Resume
http://www.infoq.com/news/yegge-good-bad-agile
I think there's something to his "drop the "Agile", focus on being agile," though the article misses the fact that what distinguishes Google's
style rather resembles the Agile Manifesto.
|
|
|
debhart
Member
Posts: 72
Registered: 04 Sep 06
Location: Toronto, Ontario
Member Is Offline
|
| posted on 29 Sep 06 at 04:47 PM |
|
|
TSS thread on the subject
This item on TheServerSide is also talking about the Yegge article:
http://www.theserverside.com/news/thread.tss?thread_id=42423
|
|
|
gishu
Member
Posts: 27
Registered: 05 Sep 06
Location: India
Member Is Offline
Mood: Comfortably Dumb
|
| posted on 30 Sep 06 at 12:03 AM |
|
|
| Quote: | Originally posted by gdinwiddie
I can't help but thinking that "showing that this is where you went wrong" is a rather non-agile way of approaching it. Granted, it's something I
would automatically do, myself, but I'm trying to get better. I don't think that you can hand people a new way of doing things. You
can help them discover it. |
I didn't mean to go all 'I told you so' on 'em. 
But my point was that agile involves a lot of thinking on your feet. This is a shift from the 'Do this, then do that and make sure you do this this
and this' cast-in-titanium processes.
I would like that someone study-reflect and point out why a agile-attempt went awry, instead of just discarding em as a 'can't think quick enough'
team.
I guess I want to reiterate "Lose... but don't lose the lesson"
-- Gishu
Given all the facts, numbers, processes in the world, every decision boils down to a judgment call.
|
|
|
RonJeffries
Ron Jeffries
Super Administrator
Posts: 126
Registered: 29 Aug 06
Location: Pinckney, MI
Member Is Offline
Mood: fascinated
|
| posted on 02 Oct 06 at 10:35 PM |
|
|
| Quote: | Originally posted by gishuBut my point was that agile involves a lot of thinking on your feet. This is a shift from
the 'Do this, then do that and make sure you do this this and this' cast-in-titanium processes.
-- Gishu |
Is there actually a process that works where people don't have to think on
their feet and pay attention?
|
|
|
craigatwork
craig davidson
Member
Posts: 17
Registered: 28 Sep 06
Location: Scotland
Member Is Offline
|
| posted on 04 Oct 06 at 03:51 AM |
|
|
| Quote: | Originally posted by RonJeffries
Is there actually a process that works where people don't have to think on their feet and pay attention? |
Works for who? For the large consultancies and the people they employ/engage, "just follow the rules" heavy weight processes work very well.
Providing a way to justify putting more people on a project and talking the budget up.
This is especially good as big processes provide high day rate experts such as Project Managers, Designers, Architects, Test Managers, Business
Analysts, Requirements Managers, Process Engineers, Tool Experts, Change Managers, Configuration Managers, Deployment Managers.
Then add in the tooling costs for such a big team for requirements management, modelling, change management, configuration management....
And the longer it takes to get the client to a running system the more billing time there is!
The customer might not do very well out of this. But everybody else seems to win. And customers seem quite happy, as they keep awarding the work to
the big consultancies despite a shocking failure rate.
Maybe this is where the strength of negative response comes from? Too many people with too much to loose.
|
|
|
dchurchv
Dave Churchville
Member
Posts: 4
Registered: 04 Oct 06
Location: San Diego, California
Member Is Offline
Mood: Zen-like calm
|
| posted on 04 Oct 06 at 08:20 PM |
|
|
Let's face it, there are only 2 kinds of people:
1. Those who agree with you
2. Those who don't.
It's pretty rare for either group to have a purely logical, reasoned, experiential, and unbiased basis for their beliefs.
So what I look at in this kind of blog post, assuming the writer isn't just trolling (which I don't think he was), is what he's actually
complaining about, versus who or what he is blaming.
So ignoring the inflammatory language, what I *think* I picked up was a cry for simplicity, personal responsibility, and emergent practice instead of
management-dictated processes that require lots of reading, external consultants, and training classes.
I remember complaining about the same thing when RUP was coming into fashion. Didn't make much difference at the company I was working for. "This
is going to improve our software processes and make them more predictable."
He (and other Google-ites) talk about the notion of different teams adopting whatever process they like (or none at all, I suppose). He has chosen
the "priority queue" process for his own team, which could certainly be called "agile" in its own way.
The idea that a skilled, experienced team of developers needs special training or outside consulting to be "agile" is what he seems to take issue
with.
In a sense, I agree that skilled people left to their own devices will probably come up with a working process, and possibly even an optimal one for
their specific context.
The Agile community seems increasingly eager to standardize terminology and practice by deeming things "agile" or "not agile", and of course,
certifying individuals as being "Agile" in specific processes. I'm not sure whether this positive or negative, but it does inspire blog posts.
As Agile goes mainstream, this kind of backlash is inevitable. And I don't suppose ignoring it will make it go away.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 05 Oct 06 at 08:58 AM |
|
|
| Quote: | Originally posted by dchurchv
The Agile community seems increasingly eager to standardize terminology and practice by deeming things "agile" or "not agile", and of course,
certifying individuals as being "Agile" in specific processes. I'm not sure whether this positive or negative, but it does inspire blog posts.
|
While I agree with most of your posting, I think this paragraph is open to dispute. One of the areas of consensus that seems to be emerging from the
"Measuring Agile" thread is that we cannot measure practices or processes to measure how agile, or not, a team is.
I guess that doesn't rule out other forms of certification (e.g. on a knowledge of a breadth of practices and their indicators and contra-indicators
of applicability).
Following the practices is not being agile. It might lead to being agile. Being agile is not (just?) following the practices. It might lead to
following the practices, where they are appropriate.
This thread is about one poster who saw many places where following the practices didn't seem to work, and saw another place where following other
practices seemed to work. It's not about following the practices. IMHO.
Paul Oldfield
Capgemini, Telford UK
|
|
|
craigatwork
craig davidson
Member
Posts: 17
Registered: 28 Sep 06
Location: Scotland
Member Is Offline
|
| posted on 05 Oct 06 at 09:20 AM |
|
|
| Quote: | Originally posted by PaulOldfield1
Following the practices is not being agile. It might lead to being agile. Being agile is not (just?) following the practices. It might lead to
following the practices, where they are appropriate.
|
Good post Paul.
This point helps me arrive at my current view:
You can be Agile.
You can do Practices.
And whilst they may influence each other they are also separate.
|
|
|
craigatwork
craig davidson
Member
Posts: 17
Registered: 28 Sep 06
Location: Scotland
Member Is Offline
|
| posted on 05 Oct 06 at 09:31 AM |
|
|
| Quote: | Originally posted by craigatwork
This point helps me arrive at my current view:
You can be Agile.
You can do Practices.
And whilst they may influence each other they are also separate. |
It just occurs to me I am a slow learner 
|
|
|
IljaPreuss
Ilja Preuß
Member
Posts: 96
Registered: 05 Sep 06
Location: Karlsruhe, Germany
Member Is Offline
|
| posted on 05 Oct 06 at 10:51 AM |
|
|
| Quote: |
The idea that a skilled, experienced team of developers needs special training or outside consulting to be "agile" is what he seems to take issue
with.
|
And who said that it does?
| Quote: |
In a sense, I agree that skilled people left to their own devices will probably come up with a working process, and possibly even an optimal one for
their specific context.
|
I agree that they will likely come up with something working. I wouldn't bet on them coming up with something optimal.
There are just too many things that could be tried, too many things that work great but are initially counterintuitive. Without getting a lot of help
from the outside - if only by participating in forums or mailing lists, reading books etc. - I seriously doubt that they'd be likely to even come
close to "optimal".
|
|
|
dchurchv
Dave Churchville
Member
Posts: 4
Registered: 04 Oct 06
Location: San Diego, California
Member Is Offline
Mood: Zen-like calm
|
| posted on 05 Oct 06 at 11:13 AM |
|
|
| Quote: | Originally posted by PaulOldfield1
Following the practices is not being agile. It might lead to being agile. Being agile is not (just?) following the practices. It might lead to
following the practices, where they are appropriate.
This thread is about one poster who saw many places where following the practices didn't seem to work, and saw another place where following other
practices seemed to work. It's not about following the practices. IMHO. |
Yes, I get that, but I think perhaps the blogger in question does not. And that was my concern - there may be a perception in the general software
community that Agile is defined by a set of practices - commonly those that XP codified.
Certainly when I mention the word to "non-believers", I get responses like "Well, TDD and continuous integration are good, but pair-programming
sucks".
I never hear "Ah, yes, I understand that Agile is more about philosophy, not practices".
Anyway, I blogged about this last week, so I won't go on and on, but I've found that popular perception quickly turns into practical reality.
Question: If everyone who's not doing Agile thinks it about the practices, does it matter what practioners believe? (Yes, it's a straw man question
:-)
P.S. I probably overstated the case by saying "The Agile community is eager to standardize on practices..." It's just a subset of the community.
|
|
|
dchurchv
Dave Churchville
Member
Posts: 4
Registered: 04 Oct 06
Location: San Diego, California
Member Is Offline
Mood: Zen-like calm
|
| posted on 05 Oct 06 at 11:21 AM |
|
|
| Quote: | Originally posted by IljaPreuss
| Quote: |
The idea that a skilled, experienced team of developers needs special training or outside consulting to be "agile" is what he seems to take issue
with.
|
And who said that it does?
| Quote: |
In a sense, I agree that skilled people left to their own devices will probably come up with a working process, and possibly even an optimal one for
their specific context.
|
I agree that they will likely come up with something working. I wouldn't bet on them coming up with something optimal.
There are just too many things that could be tried, too many things that work great but are initially counterintuitive. Without getting a lot of help
from the outside - if only by participating in forums or mailing lists, reading books etc. - I seriously doubt that they'd be likely to even come
close to "optimal". |
Ilja, I may be misunderstanding you, but your first comment seems to contradict your second.
You seem to be saying that a team of smart people needs outside help of some form to optimize their process. Which is what the original poster was
complaining about.
I don't disagree with the notion that outside help can be valuable, but maybe this is what is being perceived, however distortedly, as the
statement:
"A group of smart, experienced developers cannot be Agile without outside help".
|
|
|
RonJeffries
Ron Jeffries
Super Administrator
Posts: 126
Registered: 29 Aug 06
Location: Pinckney, MI
Member Is Offline
Mood: fascinated
|
| posted on 05 Oct 06 at 01:09 PM |
|
|
| Quote: | Originally posted by dchurchvI don't disagree with the notion that outside help can be valuable, but maybe this is
what is being perceived, however distortedly, as the statement:
"A group of smart, experienced developers cannot be Agile without outside help". |
I don't know what "Agile" means. I do know this: Every time I demonstrate TDD or refactoring ugly code to a team that has no training, their
reaction is the same: "Wow, I didn't know you did it like that!"
I learned at the hands of the best, and have studied the topic intensively for a decade. I still don't know everything, but I know a fair amount.
Much of it is counterintuitive: it's not like what I would have thought had I not been thrown in the briar patch.
I'm sure a team of intelligent, motivated developers who read the material, go to meetings and conferences, and work hard at it can learn a lot. And
yet ... "Wow, I didn't know you did it like that!"
|
|
|
gdinwiddie
Member
Posts: 40
Registered: 05 Sep 06
Location: Maryland
Member Is Offline
Mood: hunky-dory
|
| posted on 05 Oct 06 at 01:13 PM |
|
|
| Quote: | Originally posted by dchurchv
Ilja, I may be misunderstanding you, but your first comment seems to contradict your second.
You seem to be saying that a team of smart people needs outside help of some form to optimize their process. Which is what the original poster was
complaining about.
I don't disagree with the notion that outside help can be valuable, but maybe this is what is being perceived, however distortedly, as the
statement:
"A group of smart, experienced developers cannot be Agile without outside help". |
I'm not Ilja, but I don't see a contradiction in his statements.
Paraphrasing Diana Larsen, I think the
fundamentals of agile practices are iterations
constant communications
retrospectives or reflection
A smart team can certainly do this without outside consultants or training, but it can take them a really long time to converge on something really
good without outside help. I don't believe in the concept of "optimal," but reinventing the wheel is not the best route to get there in one
lifetime.
There's too much experimentation that's already been done. It's valuable to learn from the experiences of others, rather than to insist on doing
it all yourself.
| Quote: | Let's face it, there are only 2 kinds of people:
1. Those who agree with you
2. Those who don't. |
I'm not sure about that. 
|
|
|
IljaPreuss
Ilja Preuß
Member
Posts: 96
Registered: 05 Sep 06
Location: Karlsruhe, Germany
Member Is Offline
|
| posted on 05 Oct 06 at 06:02 PM |
|
|
| Quote: | Ilja, I may be misunderstanding you, but your first comment seems to contradict your second.
|
I don't think it does.
| Quote: |
You seem to be saying that a team of smart people needs outside help of some form to optimize their process. Which is what the original poster was
complaining about.
|
No. He was complaining about the "fact" that you "needed" outside help to "become Agile", which is quite different.
I'm quite sure that no team at google, or anywhere else in the world, is working with an optimal process. I'm quite sure that every team at google,
and everywhere else in the world, would be able to improve faster with outside help than without outside help - whether they wanted to become "more
Agile", "more RUP" or even "more waterfall".
Complaining about "needing outside help to become Agile" is a straw man, in my eyes. You don't *need* it, and that it does *help* significantly is
in no way specific to Agile approaches.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 06 Oct 06 at 08:00 AM |
|
|
| Quote: | Originally posted by dchurchv
Yes, I get that, but I think perhaps the blogger in question does not. |
Indeed, that was my tought, too. (I meant the blogger when I spoke about the poster).
| Quote: | | And that was my concern - there may be a perception in the general software community that Agile is defined by a set of
practices - commonly those that XP codified. |
The practices are important; they may lead to agility. Learn through doing, and all that. There would appear to be a problem, in that quite a few
teams attempt the practices but don't learn to be agile.
Other people see this happening, so we get blogs like the one that started this thread. They are not impressed when folk say, okay, you tried the
practices but didn't get it right.
There's something more than just the practices; something to do with the way people think about the work and the problems associated with it.
Something that leads people to hold the values as quoted in the manifesto. Wish I could bottle that and sell it... or even give it away.
Paul Oldfield
Capgemini, Telford UK
|
|
|
debhart
Member
Posts: 72
Registered: 04 Sep 06
Location: Toronto, Ontario
Member Is Offline
|
| posted on 06 Oct 06 at 05:09 PM |
|
|
Worse yet, this one came out later the same day http://jroller.com/page/fate?entry=the_death_of_agile and it's hard to believe it wasn't triggered by Yegge's blog, though it
doesn't reference it. WARNING this last is a link to "the bile blog" and it's rude beyond belief.
Unfortunately that's what passes for humour among some of our colleagues in our software profession. Seriously passive-aggressive humour, at that.
Both Yegge and Suleiman are "stars" of a sort, which suggests there's an anti-Agile camp already well formed (if poorly INformed :-)
I'm sure it's inevitable. I'm trying to decide whether I should care... when I asked them for constructive input, on another list, they packed up
their games and moved on, which indicates to me that they're more interested in entertainment than discourse.
|
|
|
ahcarter
Arthur Carter
Member
Posts: 4
Registered: 02 Nov 06
Member Is Offline
|
| posted on 02 Nov 06 at 06:47 PM |
|
|
Where does this strength of negative response come from?
Often described as having a lack of the "self-preservation" genes when it comes to expressing my opinions, I'm curious to see what response this
gets.
I'm a 30-year SW engineer/architect who is curious about agile methods and practices, done a fair amount of reading, understand why it works in some
situations, but have not used most of what is described as agile on any project. Here's my take:
I have a very strong knee-jerk, deep in my gut, negative reaction when I am told that the way I'm doing something is wrong. The longer I've been
doing it, and the more success I've had with the "offending" thing, the stronger the reaction. The feeling I get, rightly or wrongly, when reading
about how agilists want to "radically change the way things are done", feels a lot like (get rid of everything you are currently doing, with the
implication that it's all wrong.) You'll have to accept that I recognize the shortcomings that agilists are trying to address, but agilists should
also understand that even with the problems of BDUF, there are at least a few of us slow moving dinosaurs out here that, despite the problems, have
been able to successfully deliver outstanding software, on time, under budget that is really good. Do I think my current methods are the best? No. Do
I think agile techniques will work for me? Probably, sometimes. Do I have a lot of unanswered questions? Yes.
I think job one is figuring out how to convey that "this is a better way", without coming across as saying, everything you know is wrong (even if
that's what you really think). Many of us are resistant to change, having been burned, sometimes badly, by believing proponents of varying
philosophies on a large range of topics, promising unimaginable riches, and the end to all software development problems. Anyone remember Ada? (I'm
positive that will earn me some heat on the flame.)
I think the next hurdle, is figuring out how to answer, in a patient way, all those transition questions that we slow-adopters have. I think one of
the biggest causes of friction and sometimes failure for new ideas, is not providing a clear roadmap for transition from the old to the new. A lot of
us out here, no matter how much we may want to switch to agile techniques, still have to work within an existing structure that is not going to
embrace our newfangled thinkin'. We need a lot of help on how to integrate this new process into a mostly unreceptive environment in a fairly gradual
way, that ultimately provides us with the proof that it works.
Here's a sample "transition" question that I've not seen aswered anywhere, that I have no idea how to answer when confronted by "the old
guard".
Scenario: competitive bid, on gigantic project (say $1 billion dollars) involving 3 companies bidding together as a team. The entire project will be
under a single umbrella of management and development processes, but the work is spread out both geographically, and culturally across three different
companies. This program will involve one(or few)-time use software running on as yet to be designed or built, custom hardware
Question 1: How do you know whether you can accomplish the customer goals in their schedule and budget without doing comprehensive upfront resource
planning and scheduling, which (I think) implies a significant level of upfront design in order to understand the size and scope of the question?
Software and hardware development have to hit the integration dates in synchronization. In other words, how do you estimate your costs and resource
(people, manufacturing and development system) requirements in order to bid this fixed price contract without doing a lot of modeling and design?
The last point I'd like to raise, is that I've seen very little mention of applicability. Call me silly, but I get really skeptical and somewhat
sarcastic when anyone tries to tell me that something is the solution for everything. Under what circumstances are agile techniques NOT
appropriate.
Curious, interested, burned, skeptical and hopeful.
Arthur
|
|
|
| Pages: 1 2 3 |
RSS Feed
