Seven Things I Hate About Agile(blog.assembla.com)
blog.assembla.com
Seven Things I Hate About Agile
http://blog.assembla.com/Seven-Things-I-Hate-About-Agile/
123 comments
Oh yeah, I remember all those Morning Stand-Up Comedy Meetings at Salesforce.
Oh I thought Salesforce.com was doing well with Scrum.. Are you saying it was mostly a farce there or..?
PA
PA
I like how the opening point is ageism. Really classy.
Author here - I can make an observation about old people because I myself am 49 years old. I'm not making a value judgement about older people. That would be ageism. I'm observing that the attendees "agile" events tend to be older than most programmers, and even most IT staff. That's just demographics. Why is that? That affects a lot of things.
I can make an observation about old people because I myself am 49 years old
That doesn't make any logical sense. All that suggests is that you have n=1 experience with people over the age of forty.
As for observing that agile events in your neck of the woods are full of older people, there are many, many possible explanations for this and your blog post advances one without providing evidence that it is anything other than confirmation bias.
One thing I would do before making a statement like that is attend some other methodology events and check out the ages. If you go to a CMM conference, how old are the people? How about a PMP Institute gathering?
You may find that older people are more interested in methodologies while younger people are more interested in technologies. You might not, but your essay does nothing to establish that your explanation carries more weight than my conjecture.
And if my conjecture is correct, your point really should be that "Excessive interest in methodologies has the smell of death." That might be true!
I am not saying you're wrong, only that your essay is not persuasive on this one point.
That doesn't make any logical sense. All that suggests is that you have n=1 experience with people over the age of forty.
As for observing that agile events in your neck of the woods are full of older people, there are many, many possible explanations for this and your blog post advances one without providing evidence that it is anything other than confirmation bias.
One thing I would do before making a statement like that is attend some other methodology events and check out the ages. If you go to a CMM conference, how old are the people? How about a PMP Institute gathering?
You may find that older people are more interested in methodologies while younger people are more interested in technologies. You might not, but your essay does nothing to establish that your explanation carries more weight than my conjecture.
And if my conjecture is correct, your point really should be that "Excessive interest in methodologies has the smell of death." That might be true!
I am not saying you're wrong, only that your essay is not persuasive on this one point.
I don't make a conjecture about the reason that agile events skew to an older crowd because I really, really don't know why it is true. I do know that it changes the whole perception of the effort. So, I have to be careful when I use the word "agile". It's got a demographic implication that isn't positive, isn't "us" for many younger people. You can argue about the wisdom of my saying it this way, but the word has a real demographic and emotional association. This article is a chance to express my doubts about the word "agile". It's done. I'll be more positive from here on out.
CMM and PMP are basically anti-agile. They are useful, but useful for projects that just shouldn't be agile. The fact that agile events attract a similar demographic isn't a positive, in my opinion.
CMM and PMP are basically anti-agile. They are useful, but useful for projects that just shouldn't be agile. The fact that agile events attract a similar demographic isn't a positive, in my opinion.
It's got a demographic implication that isn't positive, isn't "us" for many younger people
Compared to what, exactly? What development management practices do have an "us" demographic for younger people? One possibility is that you will reply and name one or more named practices with a "young" demographic, and I will accept your point.
The other possibility is that there really isn't a development management practice that has a "young" demographic, that young developers just aren't into spending a lot of time thinking about practices.
If the second case is true, I really believe it undermines your point. If young developers don't really align towards any particular named repeatable practice, Agile is no better and no worse than anything else on account of the age of the people interested in it enough to attend events. It isn't worth "hating" agile for its lack of traction any more than hating PERT charts or Theory of Constraints.
Compared to what, exactly? What development management practices do have an "us" demographic for younger people? One possibility is that you will reply and name one or more named practices with a "young" demographic, and I will accept your point.
The other possibility is that there really isn't a development management practice that has a "young" demographic, that young developers just aren't into spending a lot of time thinking about practices.
If the second case is true, I really believe it undermines your point. If young developers don't really align towards any particular named repeatable practice, Agile is no better and no worse than anything else on account of the age of the people interested in it enough to attend events. It isn't worth "hating" agile for its lack of traction any more than hating PERT charts or Theory of Constraints.
My hunch is one of the main reasons people who attend Agile events tend to be on the mature side is because they've have families so they can't (and don't want to) spend their weekends at beer-fuelled hackathons and have seen that the root of software project success & failure is in the processes rather than the tools.
That kind of stuff is pretty boring for the younger generations who are still caught up in the idea that shiny technologies and gargantuan coding sessions can save the world and make them all billionares.
That kind of stuff is pretty boring for the younger generations who are still caught up in the idea that shiny technologies and gargantuan coding sessions can save the world and make them all billionares.
You are either a hypocrite or cannot remember your own writing. "The smell of death" permeates agile gatherings, because the attendees are largely over 50. That's not a statement of fact. It might have been a factual statement, had you written that the attendees were animated, rotting corpses.
You associated old people with "the smell of death." I consider that a value judgement: Old people: Agile has the smell of death on it.
If you want to see a lot of young people then go to a 48-hour hack-a-thon. That's a development methodology where you'll find fewer 40-50 year old devs.
You find mostly older devs at meetups about process and methodology not because it's and old and boring subject. Rather, because they're the ones who are concerned about process and methodology and are more likely to be at a management level.
You find mostly older devs at meetups about process and methodology not because it's and old and boring subject. Rather, because they're the ones who are concerned about process and methodology and are more likely to be at a management level.
As I explain above the oldies are there because their 401ks tanked and they had to get back into the workforce somehow without programming skills. Hence, the Agile Coaches in the AARP set
Women can be misogynistic. Where are you getting your sense of the demographics of "most programmers," anecdata?
I don't think it's ageism. It's a good observation.
Unfortunately, as you progress up the ladder in the industry, you're more likely to be attending conferences in a management capacity. I know this as I'm right there now.
The younger people here are doing, not attending conferences.
Unfortunately, as you progress up the ladder in the industry, you're more likely to be attending conferences in a management capacity. I know this as I'm right there now.
The younger people here are doing, not attending conferences.
"..the smell of death" isn't ageism??? I happen to agree that any good conference's should represent a cross-section of that industry. But the fact is that software development in particular tends to discard older professionals as not valuable.
Newsflash: Younger people get older too and still enjoy coding for fun and profits. And many of them are just like younger people, trapped in aging bodies.
Just because you're not seeing younger people at agile related events, doesn't mean they're not using agile methods where they are 'doing' stuff.
Just because you're not seeing younger people at agile related events, doesn't mean they're not using agile methods where they are 'doing' stuff.
>> Just because you're not seeing younger people at agile related events, doesn't mean they're not using agile methods where they are 'doing' stuff.
I second this. If you're using conference attendance as a measure of the effectiveness of agile methods, you may have missed a point somewhere.
I second this. If you're using conference attendance as a measure of the effectiveness of agile methods, you may have missed a point somewhere.
[deleted]
[deleted]
At its core agile leads to being able to ship at small intervals and be... uhm... agile enough to adapt to market/business changes. What's not to like?
[deleted]
I cant decide if this article is sarcasm or not. It makes me think about how there is no methodology that is the savior of developers everywhere. You may be able to find some operational efficiency choosing one methodology over another, but at the end of the day you either have developers that can write the code, or not.
> It makes me think about how there is no methodology that is the savior of developers everywhere.
nothing beats a good team of programmers. http://programming-motherfucker.com/
nothing beats a good team of programmers. http://programming-motherfucker.com/
I really think this guy have had some very annoying situations on agile-teams. At least it is what pops the most out of the blog post.
He actually contradicted himself a lot of times: - "old people": Being a developer for a relatively small period of time, but I really have a hard time talking about agile with old developers. At least is what happens here at São Paulo/Brazil. - "stagnation": Agile is not Scrum. How about XP, TDD, etc? He says there is not much action in agile-world by arguing that people spend their time making lots of non-agile tools. Without a proper explanation of what he is talking about it is almost hopeless to try on and get something out of this point. - "Imposing values": Contradiction again. First he complain about having to accept values. He even say that values are not important at all to productivity and collaboration by saying that goals are important. I may be wrong here, but goal could quite easily be considered a value in the same context.
I won't even continue on this list since I am just probably pissed with the whole thing, but I really would like to have a discussion on this to see in what page we find ourselves.
It is really sad to just read complains without any solutions or proper presentation of the problems. It makes everyone who really put some grasp on agile teams or tools look like a moron by offering a mysterious solution. It just looks like a TV show to me, not a tech or even a blog post.
He actually contradicted himself a lot of times: - "old people": Being a developer for a relatively small period of time, but I really have a hard time talking about agile with old developers. At least is what happens here at São Paulo/Brazil. - "stagnation": Agile is not Scrum. How about XP, TDD, etc? He says there is not much action in agile-world by arguing that people spend their time making lots of non-agile tools. Without a proper explanation of what he is talking about it is almost hopeless to try on and get something out of this point. - "Imposing values": Contradiction again. First he complain about having to accept values. He even say that values are not important at all to productivity and collaboration by saying that goals are important. I may be wrong here, but goal could quite easily be considered a value in the same context.
I won't even continue on this list since I am just probably pissed with the whole thing, but I really would like to have a discussion on this to see in what page we find ourselves.
It is really sad to just read complains without any solutions or proper presentation of the problems. It makes everyone who really put some grasp on agile teams or tools look like a moron by offering a mysterious solution. It just looks like a TV show to me, not a tech or even a blog post.
Hey I am trying to recruit good devs in Sao Paulo, but I am kind of clueless where to start. If you get a chance I would love to chat. Cheers. My e-mail is [email protected]
It's not sarcasm. It's a chance for me to unload the real doubts I have had about using the word "agile". I'll be more positive from here on.
That is really great to hear, it would be awesome to really read some real stuff besides analogies. By real stuff I mean situations, so all people can learn from them.
Pair programming was invented and evangelized by developers, and are its most ardent defenders at every vendor I know that offers Agile services. ThoughtWorks' sales folks hate selling pairs, for the obvious reason that most clients don't love the idea of buying them.
Even ThoughtWorks has/had developers who don't particularly like or believe in pair programming, but go along because it comes under the company's proclaimed orthodoxy umbrella most of the time. (ex TWer, so I know whereof I speak).
I used to champion pairing when I used to work at TW, and used to be puzzled at why some (very talented) TW developers thought it was all hogwash, but TW is a fine company in many ways and you eventually learn to tune out the extremes of the company's (Roy's ;) )eccentricities and get on with the work. You need to do this at any company, nothing specific to TW really.
In many teams, pairing is loosely practiced.In others, 100% pairing is the norm. So it all depends, even at TW.
That said, you have a point in that TW has some very strong and vocal proponents of 'pure' pairing. I used to be very gung ho about agile dev when I was at TW. These days I know better.
just my tangential 2 cents, and not really contradicting anything you said, just qualifying it a little.
I used to champion pairing when I used to work at TW, and used to be puzzled at why some (very talented) TW developers thought it was all hogwash, but TW is a fine company in many ways and you eventually learn to tune out the extremes of the company's (Roy's ;) )eccentricities and get on with the work. You need to do this at any company, nothing specific to TW really.
In many teams, pairing is loosely practiced.In others, 100% pairing is the norm. So it all depends, even at TW.
That said, you have a point in that TW has some very strong and vocal proponents of 'pure' pairing. I used to be very gung ho about agile dev when I was at TW. These days I know better.
just my tangential 2 cents, and not really contradicting anything you said, just qualifying it a little.
I would say 100% pair programming would be a highly draining experience! may result increased productivity, but at what cost!
Pair programming's biggest win is that it keeps me on task & not arguing online about whether or not Agile practices work.
I usually vote up Agile attacks, because I love to hear developers talk about the difference between good and bad Agile.
But it's getting a little old. It seems the world is full of cranky, half-informed folks who get a little coffee in them and suddenly are ready to make grand pronouncements about the entire state of things (Love the self-recursion here)
Seriously, one last time. Agile is best practices around iterative and incremental development. It's not a standard, it's a marketing term. Because it's not a standard, criticizing it is like criticizing "good ice cream". What's good ice cream? Any damn thing you'd like it to be. Perhaps the author has a larger criticism of how stupid we all can be when implementing change. If so, get in line. There are a lot of us.
Scrum is a standard, and it's not changing anytime soon. You can call that a good or bad thing, but it's a very small subset of Agile, so it sounds more like a separate topic to me than the entire world of Agile.
I hate the way we implement change in technology organizations. Part of the problem we have, unfortunately, is that everybody feels themselves an expert on stuff they read about in a book and maybe saw it done badly a couple of times.
The more I think about this article, the more I feel like it's 95% marketing and 5% fluff. Apologies to the author if they are serious, but something is a bit off here. Not worth flagging by any means, but I'm not upvoting it.
ADD: Bit of a meta-note. Just this morning I wrote a story on some ideas about how to handle Subject Matter Experts in Agile teams. (shameless plug: http://www.whattofix.com/blog/archives/2012/08/who-moved-my-... ) The use of the word "Agile" in my article was very useful: it identified the topic as best practices around SMEs in iterative and incremental work. It is a dry topic, and I didn't claim to have all the answers, and it was more narrowly-targeted, so it didn't get a lot of traction. That's understandable.
But what I see happen over and over again is that wild hand-waving criticisms get a lot of traction on place like this because they can emotionally engage a larger audience. Practical targeted stuff? Not so much. So for the average developer who's just out of school and never has worked on an Agile team? I'm not sure they're receiving a very balanced look at things if all they read are from places where things are voted up or down based on emotional impact. It's another interesting and counter-intuitive side-effect of the voting/ranking system.
But it's getting a little old. It seems the world is full of cranky, half-informed folks who get a little coffee in them and suddenly are ready to make grand pronouncements about the entire state of things (Love the self-recursion here)
Seriously, one last time. Agile is best practices around iterative and incremental development. It's not a standard, it's a marketing term. Because it's not a standard, criticizing it is like criticizing "good ice cream". What's good ice cream? Any damn thing you'd like it to be. Perhaps the author has a larger criticism of how stupid we all can be when implementing change. If so, get in line. There are a lot of us.
Scrum is a standard, and it's not changing anytime soon. You can call that a good or bad thing, but it's a very small subset of Agile, so it sounds more like a separate topic to me than the entire world of Agile.
I hate the way we implement change in technology organizations. Part of the problem we have, unfortunately, is that everybody feels themselves an expert on stuff they read about in a book and maybe saw it done badly a couple of times.
The more I think about this article, the more I feel like it's 95% marketing and 5% fluff. Apologies to the author if they are serious, but something is a bit off here. Not worth flagging by any means, but I'm not upvoting it.
ADD: Bit of a meta-note. Just this morning I wrote a story on some ideas about how to handle Subject Matter Experts in Agile teams. (shameless plug: http://www.whattofix.com/blog/archives/2012/08/who-moved-my-... ) The use of the word "Agile" in my article was very useful: it identified the topic as best practices around SMEs in iterative and incremental work. It is a dry topic, and I didn't claim to have all the answers, and it was more narrowly-targeted, so it didn't get a lot of traction. That's understandable.
But what I see happen over and over again is that wild hand-waving criticisms get a lot of traction on place like this because they can emotionally engage a larger audience. Practical targeted stuff? Not so much. So for the average developer who's just out of school and never has worked on an Agile team? I'm not sure they're receiving a very balanced look at things if all they read are from places where things are voted up or down based on emotional impact. It's another interesting and counter-intuitive side-effect of the voting/ranking system.
>>What's good ice cream? Any damn thing you'd like it to be.<<
Therefore -- What's Agile? Any damn thing you'd like it to be.
Therefore -- What's Agile? Any damn thing you'd like it to be.
Eh, maybe. You could not offer "good ice cream" for sale and instead deliver cookies.
Unless you go to a molecular gastronomy restaurant where they are as likely to serve you good ice cream in the form of a cookie or a cookie in the form of good ice cream.
But yeah I see what you mean and in general agree with you.
But yeah I see what you mean and in general agree with you.
[deleted]
Agile is best practices around iterative and incremental development. It's not a standard, it's a marketing term. Because it's not a standard, criticizing it is like criticizing "good ice cream". What's good ice cream? Any damn thing you'd like it to be.
Excellent analogy. If best practices and incremental development are like good ice cream, then Agile is like Tasti D-Lite™. What's not to like?
Excellent analogy. If best practices and incremental development are like good ice cream, then Agile is like Tasti D-Lite™. What's not to like?
Gelato Classico FTW! Anyone can load up their ice cream with sugar, but it takes some care and devotion to be able to feature fresh creaminess!
There's a useful analogy to the current discussion in there.
There's a useful analogy to the current discussion in there.
I agree with you, but personally I'm a little torqued at the 'over 50" comment. Hrmmm.
The author seems surprised that a meet-up about development process and methodologies is mostly older, experienced devs rather than young hipsters. It doesn't take a genius to figure that one out.
I know it's so surprising to encounter ageism in the startup world. ;)
> It's not a standard, it's a marketing term.
It's not being marketed very well. People don't seem to actually know what it is; that reads "marketing fail" to me.
It's not being marketed very well. People don't seem to actually know what it is; that reads "marketing fail" to me.
Depends on whether you're trying to buy something specific or whether you want to buy magic beans. These days, it's mainly buyers of magic beans:
http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
Agile attacks are almost always clueless, ill-informed and incoherent rants such as this one.
There's a lot of valid and interesting criticism of particular Agile methodologies and practices, but full frontal attacks on Agile in general are usually just malicious link-bait such as this one.
There's a lot of valid and interesting criticism of particular Agile methodologies and practices, but full frontal attacks on Agile in general are usually just malicious link-bait such as this one.
I'm not a big fan of agile either but "over 40" == "the smell of death"? Seriously? Not a convincing, or classy, opening line. And this was posted by the CEO of Assembla.
At first I thought it was an attempt at humor, but it wasn't! It's funny how if you take the prejudice away it actually makes the opposite point he's trying to make, i.e.
"Do you notice how as people get more and more experience in the industry they start to gravitate more towards agile processes?"
"Do you notice how as people get more and more experience in the industry they start to gravitate more towards agile processes?"
Totally agree, it hurts my heart that something this poorly written is a top post on HN.
Paging Wil Wheaton...
The main problem is the illogic of it: "if young people don't flock to something then it must be wrong." Wrong.
I don't agree with agile either but I actually have reasons. But to be fair, the article did say "Seven Things I Hate ...", it didn't say "Seven Good Reasons to Avoid Agile". The thing the article leaves out though is a reason for me to care about the fact that he hates something.
I don't agree with agile either but I actually have reasons. But to be fair, the article did say "Seven Things I Hate ...", it didn't say "Seven Good Reasons to Avoid Agile". The thing the article leaves out though is a reason for me to care about the fact that he hates something.
It's not death, it's 2-Nonenal
The thing that doesn't work for me in Agile: being treated like a baby and spoon fed little bits of work with little room for responsibility, initiative, creativity and a personal touch. Agile is great if you are a mediocre manager and you want to run a place full of replaceable cogs, but not so great if you want a place that pushes the boundaries and consistently goes the extra mile
The thing that doesn't work for me in Agile: being treated like a baby and spoon fed little bits of work with little room for responsibility, initiative, creativity and a personal touch.
Agile doesn't prevent any of those things. Actually, "agile" doesn't "do" anything, since "agile" is just an adjective that describes a set of values that a number of development methodologies have in common.
Agile doesn't prevent any of those things. Actually, "agile" doesn't "do" anything, since "agile" is just an adjective that describes a set of values that a number of development methodologies have in common.
You describe the opposite of Agile. Agile is all about ownership, responsibility, self-direction. It, (at least scrum) gives way more control to "producers" (devs, designers, etc) than "managers".
But, of course (almost) no one does scrum cause sales/customers want up front signed contract listing exactly what will be done and exactly when.
But, of course (almost) no one does scrum cause sales/customers want up front signed contract listing exactly what will be done and exactly when.
The thing that doesn't work for me in Agile: being treated like a baby and spoon fed little bits of work with little room for responsibility, initiative, creativity and a personal touch.
For the "agile" teams I've worked on, the developers have had the most input as to the breakdown of tasks compared to anyone else. So, no one was "spoon-feeding" me work. I would see what the goal of a feature would be and the team would discuss the best way to break that feature up so that work could be done.
For the "agile" teams I've worked on, the developers have had the most input as to the breakdown of tasks compared to anyone else. So, no one was "spoon-feeding" me work. I would see what the goal of a feature would be and the team would discuss the best way to break that feature up so that work could be done.
To a certain extent, agile tries to narrow the scope of a sprint, in order to ship more rapidly. For people that have a grander vision of what they want to build this may seem narrowing to constantly be reminded of the MVP. If the product you're creating is a commercial thing, or just something that will thrive based on its adoption in the marketplace, feature creep can be damaging, and it's helpful to have someone keep you focused on making that next shippable version.
That's inevitably going to piss some people off who are bubbling with ideas and want to implement them all. As a product manager with an active imagination, I've been in that situation, and I'm slowly recovering :)
That's inevitably going to piss some people off who are bubbling with ideas and want to implement them all. As a product manager with an active imagination, I've been in that situation, and I'm slowly recovering :)
Agile
A play in 3 sprints
Characters
A: rockstar developer
B: developer
C: intern
===== Sprint 1 ======
A: To a certain extent
B: agile tries to narrow
A: the scope of a sprint
A: in order to ship more rapidly
B: For people that have a grander vision
B: of what they want to build
===== Curtains, ship iteration 1 =====
===== Sprint 2 ======
A: this may seem narrowing
A: To be constantly reminded of the MVP.
A: If the product you're creating is a commercial thing
B: or just something that will thrive
A: based on its adoption in the marketplace
B: feature creep can be damaging
===== Curtains, ship iteration 2 =====
===== Sprint 3 ======
A: and it's helpful to have someone to keep you focused
A: on making that next shippable version
B: That's inevitably going to piss some people off
C: who are bubbling with ideas
A: and want to implement them all.
C: As a produce manager with an active imagination
A: I've been in that situation
B: and I'm slowly recovering
Chorus: :)
===== Curtains, ship iteration 3, move on to the next project =====
A play in 3 sprints
Characters
A: rockstar developer
B: developer
C: intern
===== Sprint 1 ======
A: To a certain extent
B: agile tries to narrow
A: the scope of a sprint
A: in order to ship more rapidly
B: For people that have a grander vision
B: of what they want to build
===== Curtains, ship iteration 1 =====
===== Sprint 2 ======
A: this may seem narrowing
A: To be constantly reminded of the MVP.
A: If the product you're creating is a commercial thing
B: or just something that will thrive
A: based on its adoption in the marketplace
B: feature creep can be damaging
===== Curtains, ship iteration 2 =====
===== Sprint 3 ======
A: and it's helpful to have someone to keep you focused
A: on making that next shippable version
B: That's inevitably going to piss some people off
C: who are bubbling with ideas
A: and want to implement them all.
C: As a produce manager with an active imagination
A: I've been in that situation
B: and I'm slowly recovering
Chorus: :)
===== Curtains, ship iteration 3, move on to the next project =====
So who the hell are Assembla and why should anybody care what they have to say? All I'm seeing here is a lot of misinformed ranting. Sure, there's a kernel or two of truth hidden away in there, but most good rants have that. I don't see that TFA makes any sort of interesting point or arrives at any real conclusion that's helping anybody make a decision though.
Oh wait, I'm almost 40, so I guess I'm too busy decaying into compost to know anything about this stuff. Never mind me..
Oh wait, I'm almost 40, so I guess I'm too busy decaying into compost to know anything about this stuff. Never mind me..
Yeah, I stopped reading at "Old People", and I am not even in that demographic. Wholesale discounting all wisdom in an entire segment of people with lots of experience in the very field you work in is rarely a good idea. I mean what's up with Knuth being so old? Some young guy should finish out TAoCP and show him how its done.
Agreed.
It looks like the author was getting some heat for that point.
http://blog.assembla.com/assemblablog/tabid/12618/bid/87899/...
If you take him for his word, I'm sure he didn't mean anything by it (he says he's in that demographic). But I can't say that I'd let him off the hook that easily. Off-hand comments like this almost always come back and bite hard.
It looks like the author was getting some heat for that point.
http://blog.assembla.com/assemblablog/tabid/12618/bid/87899/...
If you take him for his word, I'm sure he didn't mean anything by it (he says he's in that demographic). But I can't say that I'd let him off the hook that easily. Off-hand comments like this almost always come back and bite hard.
"Off-hand comments like this almost always come back and bite hard"
If he has influence over hiring / firing, the first age discrimination suit is going to be fun. Stupid blog or e-mail comments give lawyers way too much ammunition in hostile workplace claims.
If he has influence over hiring / firing, the first age discrimination suit is going to be fun. Stupid blog or e-mail comments give lawyers way too much ammunition in hostile workplace claims.
Here's my take on the "Olde Agile Coaches".
Around 2000 the stock market tanked, and a lot of these old agile coaches were seeing their retirement go away.
They didn't have any meaningful programming skills to bring to the workplace, but they needed some income.
So what did they do? Become agile coaches!
That's why most agile festivals look like an AARP convention, and why they drone on about Zen parables and radical 70s leftism.
PostAgilist
Around 2000 the stock market tanked, and a lot of these old agile coaches were seeing their retirement go away.
They didn't have any meaningful programming skills to bring to the workplace, but they needed some income.
So what did they do? Become agile coaches!
That's why most agile festivals look like an AARP convention, and why they drone on about Zen parables and radical 70s leftism.
PostAgilist
And it isn't even true. 'Agile' is appropriate especially for young people who need an entertaining and motivating environment to be productive. The 'social' aspects make Agile appealing to most of them.
That part struck me too.
On the other hand, agile is the anathema of good data modelling and it causes productivity gains early on which lead to ossification and inflexibility later. This doesn't mean that there is now room for agile development, just that it needs some boundaries.
One of the key areas we are trying to move with LedgerSMB is a solid, well-engineered database (not nearly there yet) with a framework for developing agile applications built on top of it.
I suspect that as we get older we start valuing conservative, iterative processes more and that may be a part of the age thing. However, regarding data management it seems like we keep chasing the same lessons over and over that we have been chasing since the 80's. In the 80's it was relational databases vs special purpose ones. Then it was relational databases vs object oriented ones. The object-relational databases started to take off followed by a backlash. Now it is relational (dumb relational) vs object-relational (smart relational) vs NoSQL (object oriented databases 2.0).
Yeah, this is a great idea. Let's speed up our development time right now by closing all sorts of doors for the future and ensuring that we have to handle legacy object models going back to whenever we started our project!
On the other hand, agile is the anathema of good data modelling and it causes productivity gains early on which lead to ossification and inflexibility later. This doesn't mean that there is now room for agile development, just that it needs some boundaries.
One of the key areas we are trying to move with LedgerSMB is a solid, well-engineered database (not nearly there yet) with a framework for developing agile applications built on top of it.
I suspect that as we get older we start valuing conservative, iterative processes more and that may be a part of the age thing. However, regarding data management it seems like we keep chasing the same lessons over and over that we have been chasing since the 80's. In the 80's it was relational databases vs special purpose ones. Then it was relational databases vs object oriented ones. The object-relational databases started to take off followed by a backlash. Now it is relational (dumb relational) vs object-relational (smart relational) vs NoSQL (object oriented databases 2.0).
Yeah, this is a great idea. Let's speed up our development time right now by closing all sorts of doors for the future and ensuring that we have to handle legacy object models going back to whenever we started our project!
On the other hand, agile is the anathema of good data modelling and it causes productivity gains early on which lead to ossification and inflexibility later
If you stop refactoring. So you know what? Don't stop.
At the beginning is the project when you know the least. About your tech, about your product, about your customers, about your competitors and partners. The best design decisions are made with the most information. Ergo, all design decisions should be delayed as long as possible.
The only question is how we responsibly delay design decisions. The answer for me is lots of automated tests and a willingness to refactor as we see ways to improve our designs. Plus a bunch of other agile technical practices.
If you stop refactoring. So you know what? Don't stop.
At the beginning is the project when you know the least. About your tech, about your product, about your customers, about your competitors and partners. The best design decisions are made with the most information. Ergo, all design decisions should be delayed as long as possible.
The only question is how we responsibly delay design decisions. The answer for me is lots of automated tests and a willingness to refactor as we see ways to improve our designs. Plus a bunch of other agile technical practices.
This works only if you use an RDBMS (instead of a NoSQL solution) and you use it as a very dumb data store. For large classes of applications you lose far more than you gain. The reason is that you are FORCED to refactor your data with an RDBMS.
As soon as you move outside the RDMBS storage model with agile development something very icky happens. Old data structures stick around until actively cleaned up using processes which may take a long time to complete. If you have half a billion documents in Mongo DB created and used by your agile app, you are going to have to have your application handle those data-structure-wise forever. Every new change then creates an additional corner case that must be perpetually handled.
As soon as you move outside the RDMBS storage model with agile development something very icky happens. Old data structures stick around until actively cleaned up using processes which may take a long time to complete. If you have half a billion documents in Mongo DB created and used by your agile app, you are going to have to have your application handle those data-structure-wise forever. Every new change then creates an additional corner case that must be perpetually handled.
I don't get why you think NoSQL solutions are exempt from refactoring and maintaining data quality. I've happily done that with non-SQL stores.
No matter what development approach you use, you will eventually have to deal with change. No interesting application hits v 1.0 and sticks there. The only question is whether you embrace change, which is the Agile approach, or whether you resist it. If you resist it, you change in big lurches when circumstances force it. Having tried both, I favor the former regardless of what storage mechanism I'm using.
No matter what development approach you use, you will eventually have to deal with change. No interesting application hits v 1.0 and sticks there. The only question is whether you embrace change, which is the Agile approach, or whether you resist it. If you resist it, you change in big lurches when circumstances force it. Having tried both, I favor the former regardless of what storage mechanism I'm using.
Refactoring your data structures is different though, is it not? In an RDBMS, you have to migrate your data when the schema changes, correct?
If you have, say, 100 million records in Mongo DB and you decide you need to refactor your data schemas, how long will it take you to do that?
The problem is that an RDBMS is very rigid typically on data input but very flexible on data output. if you change data input you MUST migrate data with it. MongoDB and others are very flexible with data input but what you get out is more or less what you have told it to store. This is a very different problem. You lose the ability to continue to refactor your data structure semantics beyond a certain point. This is not really the case with an RDBMS.
BTW, I have started to get PostgreSQL object-relational modelling and it is amazing. I suspect that although the barrier to entry (due to knowledge requried) is high, multiple table inheritance ought to allow far more agile development of database schemata than standard relational models allow, and at the same time do full intelligent database stuff.
If you have, say, 100 million records in Mongo DB and you decide you need to refactor your data schemas, how long will it take you to do that?
The problem is that an RDBMS is very rigid typically on data input but very flexible on data output. if you change data input you MUST migrate data with it. MongoDB and others are very flexible with data input but what you get out is more or less what you have told it to store. This is a very different problem. You lose the ability to continue to refactor your data structure semantics beyond a certain point. This is not really the case with an RDBMS.
BTW, I have started to get PostgreSQL object-relational modelling and it is amazing. I suspect that although the barrier to entry (due to knowledge requried) is high, multiple table inheritance ought to allow far more agile development of database schemata than standard relational models allow, and at the same time do full intelligent database stuff.
Again, I'm not seeing the problem.
100 million records may take a lot of time to update, but so what? It's not like you make major schema changes to the same data every day. If you write your code to read either format v1 or v2 and to output v2, the migration can begin gradually. When you're sure it's working well, you start a low-priority job that reads old records and migrates them. Eventually, all data is in v2, so you can ditch the reader code for v1.
100 million records may take a lot of time to update, but so what? It's not like you make major schema changes to the same data every day. If you write your code to read either format v1 or v2 and to output v2, the migration can begin gradually. When you're sure it's working well, you start a low-priority job that reads old records and migrates them. Eventually, all data is in v2, so you can ditch the reader code for v1.
When you're sure it's working well,
Translation: We cut out the time on managing our schema and sped up our development, and this meant we got to spend it all back and more managing schemaless storage!
Translation: We cut out the time on managing our schema and sped up our development, and this meant we got to spend it all back and more managing schemaless storage!
If you don't like NoSQL stores, don't use 'em. Either toolset is fine with an agile approach, though.
I'm not really following your argument. Why would Agile shut doors to future change? It seems like one of the core tenets of Agile is to embrace the concept of change and willfully eliminate legacy models as you are able.
I also think it's very naive to think of NoSQL as purely OODB 2.0. It is getting used for a lot of different things, that IMO are inappropriate for it. On the other hand, the movement is intended to solve a very different set of problems (DBs with various ACID levels depending upon scalability and durability requirements), from those solved by OODBs (API improvements that weren't), and traditional RDBMS systems.
I also think it's very naive to think of NoSQL as purely OODB 2.0. It is getting used for a lot of different things, that IMO are inappropriate for it. On the other hand, the movement is intended to solve a very different set of problems (DBs with various ACID levels depending upon scalability and durability requirements), from those solved by OODBs (API improvements that weren't), and traditional RDBMS systems.
But NoSQL is pretty much based on the idea that you store data from your application in a way which is close to the internal data structures, is it not? Since you aren't dealing with the ability to do on-the-fly, ad hoc transformation (the RDBMS and ORDBMS model) then you are limited more or less to a transactional state persistence layer, which is what the OODBMs's were intended to be. It doesn't really solve any of the problems that beset the OODBMS and other app-specific storage layer. It does solve all the problems that OODBMSs solved and a few more.
I can't see why one wouldn't see NoSQL as essentially a continued outgrowth of the OODBMS movement to be honest.
In essence for complex data it seems to me you have two choices:
1) Insist on rigidly mathematically defined input, allow ad-hoc transformation on output. Input is rigid, output is flexible, or
2) Be flexible with input, and allow some transformation both in input and calling on output. Input is flexible but output is pretty rigid.
the first is an RDBMS, and possibly the array-native databases in the NoSQL world, while the second is the OODBMS, and the vast majority of NoSQL products.
I think this fundamentally gets us to Stonebraker's 4-fold division, where on the left hand side you have simple data:
With query = RDBMS Without Query = Filesystem
On the right hand side you have complex data (nested structures and the like):
With query: ORDBMS Without Query: OODBMS
I don't think there is any question that the key problems of operating without declarative queries that can transform data reliably on data output (and this requires fixed schemas for data input) are the same whether you are dealing with OODBMS's or NoSQL db's.
I can't see why one wouldn't see NoSQL as essentially a continued outgrowth of the OODBMS movement to be honest.
In essence for complex data it seems to me you have two choices:
1) Insist on rigidly mathematically defined input, allow ad-hoc transformation on output. Input is rigid, output is flexible, or
2) Be flexible with input, and allow some transformation both in input and calling on output. Input is flexible but output is pretty rigid.
the first is an RDBMS, and possibly the array-native databases in the NoSQL world, while the second is the OODBMS, and the vast majority of NoSQL products.
I think this fundamentally gets us to Stonebraker's 4-fold division, where on the left hand side you have simple data:
With query = RDBMS Without Query = Filesystem
On the right hand side you have complex data (nested structures and the like):
With query: ORDBMS Without Query: OODBMS
I don't think there is any question that the key problems of operating without declarative queries that can transform data reliably on data output (and this requires fixed schemas for data input) are the same whether you are dealing with OODBMS's or NoSQL db's.
> But NoSQL is pretty much based on the idea that you store data from your application in a way which is close to the internal data structures, is it not?
IMO, it's not. Try BigTable on Google App Engine, or HBase for some examples. IMO, these are often more difficult to relate to a programming model than a traditional RDBMS due to their inherent limitations. Of course, their structure is one of Columns/Rows as well.
One of the problems with describing NoSQL as a movement is that there are a broad range of solutions to a broad range of problems that are being covered by the same terminology.
On the other hand, I suppose there are quite a few NoSQL solutions that do not require structured input data and therefore may appear attractive to people who don't want to maintain rigid structures for data input. That's always seemed like more hype than reality to me, though. I've had pretty good experiences with evolving schemas within PostgreSQL and other SQL systems, and the challenges faced (data migration, dealing with old data in the model, etc) were essentially the same that I would have faced with something like a MongoDB system. I don't really see the advantage of NoSQL there at all. I can also see how they could be viewed as essentially OODB 2.0, and they may very well fall by the wayside for a lot of the same reasons.
IMO, it's not. Try BigTable on Google App Engine, or HBase for some examples. IMO, these are often more difficult to relate to a programming model than a traditional RDBMS due to their inherent limitations. Of course, their structure is one of Columns/Rows as well.
One of the problems with describing NoSQL as a movement is that there are a broad range of solutions to a broad range of problems that are being covered by the same terminology.
On the other hand, I suppose there are quite a few NoSQL solutions that do not require structured input data and therefore may appear attractive to people who don't want to maintain rigid structures for data input. That's always seemed like more hype than reality to me, though. I've had pretty good experiences with evolving schemas within PostgreSQL and other SQL systems, and the challenges faced (data migration, dealing with old data in the model, etc) were essentially the same that I would have faced with something like a MongoDB system. I don't really see the advantage of NoSQL there at all. I can also see how they could be viewed as essentially OODB 2.0, and they may very well fall by the wayside for a lot of the same reasons.
You think you have problems? I am 40 and one of those silly "girl" people:
Pair programming is like those girls that go to the restaurant bathroom together.
In Andy Singleton's universe, I should just go die already.
P.S. Used Assembla on a client. Very subpar tool, IMHO.
Pair programming is like those girls that go to the restaurant bathroom together.
In Andy Singleton's universe, I should just go die already.
P.S. Used Assembla on a client. Very subpar tool, IMHO.
This sounds like an allegation of sexism, but I don't really see it.
Geek Squad CEO, 7 Things I Hate About Tech Support:
Irate callers are just like those black people who don't tip at restaurants.
Now do you see it?
(Obviously, I made that up. Apologies to Geek Squad and their CEO who I am sure would never say such a vile thing).
Irate callers are just like those black people who don't tip at restaurants.
Now do you see it?
(Obviously, I made that up. Apologies to Geek Squad and their CEO who I am sure would never say such a vile thing).
Nope, still don't see it. Women tend to go to the bathroom together far more frequently than men do in my neck of the woods. It's a stereotype, but I don't see how it's a harmful one to perpetuate, unlike your example. Would it bother you if people assumed you wanted to go to the bathroom in a group? If so, is this a common concern?
Are you offended that the author is making fun of certain girls (the particular girls who go to the bathroom together) or that the author is making fun of girls (a group in which a subset go to the bathroom together, and you don't want to be associated with that subset)?
Oh you.
What do [Scrum Masters] do?
I'm sorry, but if you don't know the answer to this question, you're not familiar enough with agile to write intelligently about it. If you're going to write about a technique, you should at least know the basic concepts, whether you agree with them or not. And pretending ignorance for effect doesn't add much to the discussion.
I'm sorry, but if you don't know the answer to this question, you're not familiar enough with agile to write intelligently about it. If you're going to write about a technique, you should at least know the basic concepts, whether you agree with them or not. And pretending ignorance for effect doesn't add much to the discussion.
Personally, I think one can learn enough about agile to apply it usefully without ever learning what a "scrum master" does. Maybe this goes back to the discussion of process vs. best practices.
Maybe. But it's a pretty critical role, and if no one on the team is filling it (or even aware that the role is needed), you're losing out on most of the benefit of agile. To the point where it's not really what people mean when they refer to the Agile process.
[deleted]
I totally agree about the scrum master role. I have never understood the need for a scrum master when there are product managers and tech leads. Scrum masters usually don't have technical or product experience. I think some product managers just hire scrum masters to do their grunt work.
For me, scrum masters have always been regular members of the team who had the added responsible of organizing the meta-scrum aspects of the work. They scheduled the planning, retro, etc meetings as well as set up the task board once work was decided upon. They made sure meetings and stand-ups were running smoothly and stayed on point.
I could see where a person whose entire job description was "scrum master" would seem superfluous, but I have yet to work somewhere where that was the case.
I could see where a person whose entire job description was "scrum master" would seem superfluous, but I have yet to work somewhere where that was the case.
Anyone care to explain what the author mean by: "Pair programming is like those girls that go to the restaurant bathroom together."? It sounds like a funny analogy but it's just pure gibberish. The point of the article seem to be to get reactions, not tell you anything about Agile.
I genuinely agree. In a former life I was promoted from software developer to lead dev/scrum master, and I can tell you the dev part of the job moved completely to the background, making room for something more of a secretary job: planning poker roundups, doing the scrum board task dance, doing the numbers game on estimated and effective man-hours, etc. Overhead.
I don't say agile development is a bad thing. But some managers tend to be led by cool buzz words and obey the manifesto way to strictly.
Agile development is different for every team and situation, not a one-stop-shop everyone should adhere to.
I don't say agile development is a bad thing. But some managers tend to be led by cool buzz words and obey the manifesto way to strictly.
Agile development is different for every team and situation, not a one-stop-shop everyone should adhere to.
Statistically speaking, the "young" startup founder is a complete stereotype. The over-50 crowd which this article refers to as "having the stench of death" actually starts and runs more successful startups than the under-30 crowd. So, to be fair, those "hot" startups you love, that have a business plan worth more than just "build it and they will come" in it, are most likely run by someone over 40.
Also, anyone that knocks "Agile" has not had much experience in the enterprise sector. Yes, it has overhead - but in a larger (500+ employees) company that overhead is absolutely crucial to maintaining uniformity amongst all divisions and ensuring all "players" in the game are on the same page.
Also, anyone that knocks "Agile" has not had much experience in the enterprise sector. Yes, it has overhead - but in a larger (500+ employees) company that overhead is absolutely crucial to maintaining uniformity amongst all divisions and ensuring all "players" in the game are on the same page.
I dislike agile and scrum not because I think they're bad ideas - in fact, there are some good ones in there. The problem is they're so doctrinaire. A "manifesto", scrum masters, agile consultants, etc are all there to enforce processes that don't always make sense for any given team or organization, and they detach you from the reality of actual productivity. Didn't assign the right number of points to your scrum story? Didn't break things down into tasks properly? Velocity fail? If these are your problems, then you're focusing on the wrong things.
I agree with there being lots of old people in the community of agile-enthusiasts. My theory is that this is because most young people have never worked for a large company with lots of top-down processes and agile is just the default/what comes naturally.
This is somewhat similar to the issue of the Cathedral and the Bazaar in software engineering. Most young people have never even seen a Cathedral and just consider the Bazaar model the default.
Edit: No offense to anyone in that demographic btw. I have great respect for everyone involved in that community, I just don't think it is very interesting for kids that never knew anything else
This is somewhat similar to the issue of the Cathedral and the Bazaar in software engineering. Most young people have never even seen a Cathedral and just consider the Bazaar model the default.
Edit: No offense to anyone in that demographic btw. I have great respect for everyone involved in that community, I just don't think it is very interesting for kids that never knew anything else
> Pair programming is like those girls that go to the restaurant bathroom together. What are they doing?
Why don't you ask somebody who pairs, rather than writing an uninformed rant against it?
> If you are customer, you pay twice as much and you get churn.
Oh I get it, you're approaching and commenting on all of Agile from your software-as-contract-work perspective. Let me enlighten you: most software isn't sponsored by a single customer on a per-diem basis. But while we're here, let me say this: if you truly think you get half the productivity from a pair, then you fundamentally misunderstand the gains of pairing.
> I recommend a more efficient alternative – review pairs. Person A and person B use a code review system to review each other’s code before release. You get the same benefit without the neck cramp and the BS.
There is more to benefit from pairing than just on-the-go reviewing. There is also the fact that you retain your focus much easier, you spread technical knowledge when you shuffle your pairs, etc.
But on the subject of reviews, your reviews are also much better because they benefit from FULL context, and the suggestions and modifications are made EARLIER (which is much less expensive than getting to the point of being ready to commit and having to refactor everything).
Oh and about the neck cramp remark: do you really expect your devs to pair without having mirrored monitors, two keyboards, etc?
Why don't you ask somebody who pairs, rather than writing an uninformed rant against it?
> If you are customer, you pay twice as much and you get churn.
Oh I get it, you're approaching and commenting on all of Agile from your software-as-contract-work perspective. Let me enlighten you: most software isn't sponsored by a single customer on a per-diem basis. But while we're here, let me say this: if you truly think you get half the productivity from a pair, then you fundamentally misunderstand the gains of pairing.
> I recommend a more efficient alternative – review pairs. Person A and person B use a code review system to review each other’s code before release. You get the same benefit without the neck cramp and the BS.
There is more to benefit from pairing than just on-the-go reviewing. There is also the fact that you retain your focus much easier, you spread technical knowledge when you shuffle your pairs, etc.
But on the subject of reviews, your reviews are also much better because they benefit from FULL context, and the suggestions and modifications are made EARLIER (which is much less expensive than getting to the point of being ready to commit and having to refactor everything).
Oh and about the neck cramp remark: do you really expect your devs to pair without having mirrored monitors, two keyboards, etc?
Pair programming reminds me of the issue of trying to pair up for video games. Either you find somebody much better than you, or much worse. Because the spectrum is large, the chance of a good match is nil.
In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I stay late and do my real work.
In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I stay late and do my real work.
I like to pair with people who are as good, but I'm also happy to pair with people who are much better or worse.
When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing.
That's a short-term personal productivity hit, but for me it has always been a long-term team win. There's no faster way to get somebody up to speed. And the sooner they learn The Right Way to do something, the less I'll have to clean up their novice WTF-bombs later.
When it's somebody better, that's pure fun. I learn a ton, I get to see somebody good at work, I pick up tricks, and I end up with a detailed understanding of a colleague's strengths.
When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing.
That's a short-term personal productivity hit, but for me it has always been a long-term team win. There's no faster way to get somebody up to speed. And the sooner they learn The Right Way to do something, the less I'll have to clean up their novice WTF-bombs later.
When it's somebody better, that's pure fun. I learn a ton, I get to see somebody good at work, I pick up tricks, and I end up with a detailed understanding of a colleague's strengths.
All well and good, but there is actual work to get done. In the short term, I will get more done without the friction of a 2nd person to tutor. Much more work. Order of magnitude more work.
In the short term? Sure, in the short term you don't need tests, either. Or readable code. Or version control. Or colleagues. Or multi-letter variable names.
Any software development approach works in the short term. In which case, do what you want. But if you're looking for a sustainable approach to building a product, sometimes you have to sacrifice short-term personal productivity to gain in the long term.
Also, "order of magnitude" is a sign you're doing it wrong. Worst case for me is circa a 30% hit; if somebody is sufficiently novice, then they're mainly along for the ride while I code and explain as I go.
Any software development approach works in the short term. In which case, do what you want. But if you're looking for a sustainable approach to building a product, sometimes you have to sacrifice short-term personal productivity to gain in the long term.
Also, "order of magnitude" is a sign you're doing it wrong. Worst case for me is circa a 30% hit; if somebody is sufficiently novice, then they're mainly along for the ride while I code and explain as I go.
then you need to confront your situation and resolve it satisfactorily, because staying in late to get your "real" work done is means to an end, remember you have a "life"!
Kind thought, thank you. But sometimes my life IS my startup, and thats the choice I have made.
I was only referring to your bad "pair programming" experience, in that you felt it held you up from actually getting stuff done, that's just wasted effort.
However, my experience is that pair programming would work well in a senior/not as senior pairing, with the caveat, you need to have capacity on your projects to roll with this also technique.
regarding you choosing to sweat on your startup, fair play thats your choice, and possibly a good one if that's what you are passionate about. hopefully your end goal/mission is not just to make loads of money though!
However, my experience is that pair programming would work well in a senior/not as senior pairing, with the caveat, you need to have capacity on your projects to roll with this also technique.
regarding you choosing to sweat on your startup, fair play thats your choice, and possibly a good one if that's what you are passionate about. hopefully your end goal/mission is not just to make loads of money though!
Personally, I love pair programming and do it for my own projects when I get the chance. So his cynical "charge twice as much" doesn't hold.
However, it is hard to do right. A while back I put together a list of 21 ways to hate pair programming: http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra...
One of my colleagues summed it up as "third-draft code in first-draft time."
However, it is hard to do right. A while back I put together a list of 21 ways to hate pair programming: http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra...
One of my colleagues summed it up as "third-draft code in first-draft time."
Most of these complaints apply to any workplace or group that advertises itself to follow a certain methodology.
Half the problem with places calling themselves "Agile" is the need to advertise to the world the process you use to do what you do.
Half the problem with places calling themselves "Agile" is the need to advertise to the world the process you use to do what you do.
"Old People"
I find an interesting contrast between his conclusion on Agile conferences versus my 42 year old self. He sees a lot of old people and concludes this must not be a good thing. I see a lot of "old" people and conclude my elders might have learned something over their careers which I might get a leg up on by listening to what they value.
I wonder how many lessons older programmers learned in the resource constrained 8-bit or mini-computer days could have help some of the youngster programming these smart phones?
// for a comedic take on youth http://www.youtube.com/watch?v=UKUZ42T9diU
I find an interesting contrast between his conclusion on Agile conferences versus my 42 year old self. He sees a lot of old people and concludes this must not be a good thing. I see a lot of "old" people and conclude my elders might have learned something over their careers which I might get a leg up on by listening to what they value.
I wonder how many lessons older programmers learned in the resource constrained 8-bit or mini-computer days could have help some of the youngster programming these smart phones?
// for a comedic take on youth http://www.youtube.com/watch?v=UKUZ42T9diU
I am biased, but it is hard to take someone who is talking about stagnation seriously when his blog ends in aspx.
> Old people: Agile has the smell of death on it. If you go to an “agile” event you will see few people under the age of 40 and many over 50.
This has the smell of ad-hominem on it. How about a little evaluation of the ideas?
> Most organizations which use the word "agile" are using the word precisely because they are NOT agile, and want to be more agile.
Again, this is basically just saying, "It can't be cool because the cool kids aren't in on it." How about an evaluation of the ideas, not the marketing?
> I don’t think values have anything to do with productivity or collaboration. The Americans and the Russians didn’t share many values, but they teamed up into a mighty fighting force during WWII because they shared a goal.
I abhor this attitude. You meet people who are all about "making use of you" at "startup weekend" type events. Values aren't so necessary for productivity in general, but shared values are necessary for productivity in areas where quality and attention to detail are paramount.
> If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time
So you are evaluating a practice by the scummiest abuse of the practice? I think this reveals something, but not so much about the practice.
This has the smell of ad-hominem on it. How about a little evaluation of the ideas?
> Most organizations which use the word "agile" are using the word precisely because they are NOT agile, and want to be more agile.
Again, this is basically just saying, "It can't be cool because the cool kids aren't in on it." How about an evaluation of the ideas, not the marketing?
> I don’t think values have anything to do with productivity or collaboration. The Americans and the Russians didn’t share many values, but they teamed up into a mighty fighting force during WWII because they shared a goal.
I abhor this attitude. You meet people who are all about "making use of you" at "startup weekend" type events. Values aren't so necessary for productivity in general, but shared values are necessary for productivity in areas where quality and attention to detail are paramount.
> If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time
So you are evaluating a practice by the scummiest abuse of the practice? I think this reveals something, but not so much about the practice.
I'd say the fact that orginizations using the work 'agile' not actually being agile goes hand in hand with old people at "agile" events. People that do it actually do it, people that want to talk about how they should be doing it just talk about it.
Interesting to see that comments of these articles are full of "no true scotsman" arguments.
Since you are interested in logical fallacies, please don't forget that committing a logical fallacy (such as "no true scotsman") does not invalidate the conclusion (in this case: that the author really isn't doing it right).
https://en.wikipedia.org/wiki/Argument_from_fallacy
https://en.wikipedia.org/wiki/Argument_from_fallacy
"I don’t think values have anything to do with productivity or collaboration."
That is possibly the dumbest thing I have ever read. I have never seen a tight, productive team that didn't have certain values in common. It need not be explicit. (Indeed, being explicit about it is often a sign of problems.) But it has to be there.
His counter-example, supply chains, are notoriously difficult to manage. The people who are best at that, like Toyota, often work very hard to encourage shared thinking and shared values across company boundaries. And the notion that in-team relationships should look to the US-Russia relationship as a model is redonkulous.
Updated to add:
That line strikes me as a classic example of "I don't notice X in action, therefore X is {stupid|unimportant|useless}." Which I've certainly done in the past, but as an old fogy I've taken my lumps enough to learn a little caution.
That is possibly the dumbest thing I have ever read. I have never seen a tight, productive team that didn't have certain values in common. It need not be explicit. (Indeed, being explicit about it is often a sign of problems.) But it has to be there.
His counter-example, supply chains, are notoriously difficult to manage. The people who are best at that, like Toyota, often work very hard to encourage shared thinking and shared values across company boundaries. And the notion that in-team relationships should look to the US-Russia relationship as a model is redonkulous.
Updated to add:
That line strikes me as a classic example of "I don't notice X in action, therefore X is {stupid|unimportant|useless}." Which I've certainly done in the past, but as an old fogy I've taken my lumps enough to learn a little caution.
The title is provocative (it's a numbered list, and a rant!) but the author would have been better served with "Seven Ways to Make Agile Better", for no other reason than taking a positive slant. Agile can be built on, its not necessary to tear it down to the foundations first. The article wasn't helpful or illuminating and full of strawmen -- the author is attacking their own definitions of Agile.
Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a reference probably only fortysomethings will get) and once was mistaken for latetwentysomething by someone who was bad at guessing ages, good at flattery, or some of both. But please read the following with full consideration of the biases of age, from which youth is wonderfully immune.
Agile is essentially about shortening feedback cycles. The problem with waterfall was that work products were reviewed when 'complete', when change costs were high and commitments large. Decompose the work products into smaller chunks (backlog items and tasks) and review more frequently -- Sprints (every N weeks), standups (daily), pair programming (realtime). Every work product in a waterfall cycle, not just code, can be decomposed into smaller tasks -- design documents etc. can be constructed iteratively and incrementally, in parallel or sequentially (the latter meaning you can overlay Agile on top of waterfall) with tight and layered feedback cycles.
There are many artifacts, but dwelling on their structure and nature without reference to their essential role leads to superficial criticisms.
When something is broken in Agile always return to the fundamental question of how well the feedback cycle is working and how to fix it. Sprint reviews not providing value? Are they being used for feedback or have they become demo days? Has the standup become a daily status report?
Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a reference probably only fortysomethings will get) and once was mistaken for latetwentysomething by someone who was bad at guessing ages, good at flattery, or some of both. But please read the following with full consideration of the biases of age, from which youth is wonderfully immune.
Agile is essentially about shortening feedback cycles. The problem with waterfall was that work products were reviewed when 'complete', when change costs were high and commitments large. Decompose the work products into smaller chunks (backlog items and tasks) and review more frequently -- Sprints (every N weeks), standups (daily), pair programming (realtime). Every work product in a waterfall cycle, not just code, can be decomposed into smaller tasks -- design documents etc. can be constructed iteratively and incrementally, in parallel or sequentially (the latter meaning you can overlay Agile on top of waterfall) with tight and layered feedback cycles.
There are many artifacts, but dwelling on their structure and nature without reference to their essential role leads to superficial criticisms.
When something is broken in Agile always return to the fundamental question of how well the feedback cycle is working and how to fix it. Sprint reviews not providing value? Are they being used for feedback or have they become demo days? Has the standup become a daily status report?
Andy has observed that people under the age of 40 don't talk about "Agile" as much as people over it. I have NOT made this same observation, but I have a theory about a possible reason that Andy has observed it.
People over 40 call it "agile development". People under 40 call it "programming". The people over 40 remember doing it differently -- we remember the nine month efforts to write requirements documents that then must not be deviated from even if it is necessary to save the project from failure.
People over 40 call it "agile development". People under 40 call it "programming". The people over 40 remember doing it differently -- we remember the nine month efforts to write requirements documents that then must not be deviated from even if it is necessary to save the project from failure.