Hacker News Reader

Comment by dragonwriter | Hacker News Reader

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

View on HN

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