Seven Things I Hate About Agile • Hacker News Board

Re: Seven Things I Hate About Agile

#81

Post by saraid216 » Wed, Aug 22, 2012, 6:18 PM UTC

DanielBMarkham wrote: post #12

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 itera…

> 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.

Re: Seven Things I Hate About Agile

#82

Post by wpietri » Wed, Aug 22, 2012, 6:19 PM UTC

"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.

Re: Seven Things I Hate About Agile

#83

Post by wpietri » Wed, Aug 22, 2012, 6:19 PM UTC

saraid216 wrote: post #81

DanielBMarkham wrote: post #12

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 itera…

> 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.

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...

Re: Seven Things I Hate About Agile

#84

Post by wpietri » Wed, Aug 22, 2012, 6:22 PM UTC

peeters wrote: post #51

> 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 sponsore…

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."

Re: Seven Things I Hate About Agile

#85

Post by rada » Wed, Aug 22, 2012, 6:24 PM UTC

natrius wrote: post #68

rada wrote: post #48

Earlier quoted context omitted.

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.

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).

Re: Seven Things I Hate About Agile

#86

Post by wpietri » Wed, Aug 22, 2012, 6:26 PM UTC

JoeAltmaier wrote: post #76

peeters wrote: post #51

> 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 sponsore…

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 s…

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.

Re: Seven Things I Hate About Agile

#87

Post by wpietri » Wed, Aug 22, 2012, 6:30 PM UTC

einhverfr wrote: post #43

mindcrime wrote: post #22

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…

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 fo…

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.

Re: Seven Things I Hate About Agile

#88

Post by pacala » Wed, Aug 22, 2012, 7:07 PM UTC

jschuur wrote: post #33

pacala wrote: post #17

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

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 k…

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 =====

Re: Seven Things I Hate About Agile

#89

Post by dbshapco » Wed, Aug 22, 2012, 7:09 PM UTC

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?

Re: Seven Things I Hate About Agile

#90

Post by stcredzero » Wed, Aug 22, 2012, 7:14 PM UTC

juan_juarez wrote: post #79

stcredzero wrote: post #73

> 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 becau…

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.

Those two sentences need some more exposition to connect.