Comment by wgerard | Hacker News Reader

Comment by wgerard | Hacker News Reader

The problem, obviously, is not Agile.

This will, naturally, cause hairs on necks to rise waiting to scream back "What are you talking about? Of course Agile is the problem!" But really, the problem is that any business trend/fad is inevitably doomed to become a hollow shell of what it was intended to be.

Or more pointedly: Businesses don't really want to overhaul their development process, and any new process integrated will inevitably become just an extension of whatever they were doing before. This is basically what the article's saying without directly saying it.

I mean, the very first phrase in the Agile manifesto is:

> Individuals and Interactions over processes and tools

And yet see how many anecdotes in this thread are about how the most annoying part of Agile is the rigid adherence to certain processes. If 1 week sprints are too short, change them to 4 week sprints. Figure out the cadence that makes sense for your team. That's what Agile is supposed to be about.

Regardless of whatever Large Co wants to call their development process, let's stop calling it Agile and start calling it what it really is: Waterfall with a Kanban board and shorter deadlines.

> The problem, obviously, is not Agile.

Sure, any true Scotsman can see that.

What reason do we have to believe that Agile is so great, if (as you point out) most business aren't actually doing Agile?

> What reason do we have to believe that Agile is so great, if (as you point out) most business aren't actually doing Agile?

Read the anecdotes on the other end. People who have reached the shining city the article describes. It's a nice place to be. There are a few in this thread alone. I've personally experienced it as well. It's great.

> Sure, any true Scotsman can see that.

To continue the analogy, this is roughly the equivalent of declaring myself Scottish because I'm wearing a kilt and playing bagpipes. I have no connection to the country of Scotland presently or historically, but I'm doing the things that Scottish people are stereotypically associated with, so I must be Scottish, right?

At that point, I think it's fair to call my bluff.

>Sure, any true Scotsman can see that.

I call BS. Yes, the "any true Scotsman" fallacy can happen in a discussion.

But it's also true that some things are presented as X but are not X, and it's not a fallacy to point this out.

Here the parent specifically called attributes of Agile that are there in the original manifesto, but are not adhered.

That's not shifting the definition (which is what a no true Scotsman is about), it's about pointing that a thing doesn't adhere to the original definition it was supposed to hold.

>What reason do we have to believe that Agile is so great, if (as you point out) most business aren't actually doing Agile?

That's an orthogonal question. Agile might be great or bad.

But we can't deduce from businesses doing something non-agile and calling it Agile whether agile is good or bad.

At best we can deduce that Agile has a tendency to be wrongly applied.

> Individuals and Interactions over processes and tools

Indeed, it's my experience this is often ignored, along with "ditch what doesn't work for you". I've seen countless articles (and job descriptions!) claiming, for example, that "pair programming" is the sine qua non of Agile; if you don't do it, you're doing something wrong. Or "sure, use what works for you, except if you don't follow these guidelines you are on your own".

I, for example, consider pair programming extremely exhausting. It works for me in very short spans and very limited applications; pushed too far it makes me consider switching jobs.

Isn't agile based on the idea that engineers are fundamentally interchangeable, and so doesn't everyone involved need to establish some fairly significant cognitive dissonance in order to implement agile "correctly"?

It's fairly obvious that engineers are not fungible, and that an entire process centered around that idea, is not only degrading and disrespectful, but an outright lie that needs to be propped up by illogical thinking, and faith-based arguments.

I'm not sure how you determine what is true, but using empirical evidence and sound reasoning is how I prefer to be presented with justifications for a process change. So far, I haven't seen any research showing that agile is an effective management system.

> Isn't agile based on the idea that engineers are fundamentally interchangeable,

No, “people and interactions over processes and tools” is based on exactly the opposite.

OTOH, most concrete methodologies sold as “Agile” do seem grounded in the interchangeability of workers (not just engineers, though those are the primary workers involved), but the idea of concrete development methodology (instead of metamethodology that specified how a group adapts dev. methodology to group needs) usable “as is” by multiple organizations is directly contrary to the Agile Manifesto.

Doesn't “people and interactions over processes and tools” seem a little bit like fox news trying to sell itself as "fair and balanced" or those multi-level marketing campaigns like "it works!"

The core premise seems like it's pushing a human-centric idea really hard only because it actually removes the humanity from it.

Getting hounded every day to try to justify your existence in a company does not sound human-centric to me.

> Doesn't “people and interactions over processes and tools” seem a little bit like fox news trying to sell itself as "fair and balanced"

No, because the Agile Manifesto isn't a slogan for a concrete methodology, it is the explanation of a set of values.

The concrete methodologies come from different sources than (and post-date) the Manifesto; the Manifesto wasn't written to sell them.

It's true that there is a mismatch between the values articulated in the Agile Manifesto and the concrete methodologies that bill themselves as “Agile”, but that's not due to the Manifesto being a dishonest sales pitch for the methodologies, it's because the methodologies are dishonestly appropriating the label associated with the Manifesto.

I agree there's a mismatch between the Agile Manifesto and most of the concrete methods described as "Agile", especially when it comes to how much individuality is valued. I am not at all convinced it's fair to blame this entirely on the methodology side. The eXtreme Programming book was published in 1999 (and had been talked about before then). Scrum is a little harder to pin down, but a book was published in 2001 (around the same time as the Agile Manifesto), but the ideas were definitely circulating before that. There were other concrete methodologies which fed in, _e.g._ Alistair Cockburn's "Crystal" methods, which seem to have faded away.

In any case, the people pushing the methodologies overlap very substantially with the people who originally signed the manifesto.

But it's not really the methodologies themselves as the approach to methodology that is problematic, and of the major “Agile” methodologies, only Scrum really bakes the inflexibility in to the first party approach to the methodology (if you aren't following every jot and tittle of The Scrum Guide™ under the guidance of a certified Professional Scrum Master™, you aren't really doing Scrum.)

Most “Agile” methods are fine starting points for adapting a methodology to your team needs, which is the only thing a published methodology should be if one takes the values of the Agile Manifesto seriously. But the even where they aren't actively pushed as rigid, one-size fits all, certification and standardization driven monoliths like Scrum, they tend to fail to actually address Agile application...

Scrum isn't the only offender. By-the-book XP is pretty rigid about some things, too (collective ownership and pairing in particular).

Agree that the consulting/certification industry makes things worse. Again, that overlaps with the signatories for the original manifesto.

Scrum and DSDM significantly predate the manifesto with Ken/Jeff and Arie all signatories.

Reply on news.ycombinator.com