[InternetOfStuff]

> This quote is the best part of the article:

> > "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".

This quote is silly.

To me, agile is just good engineering practice, applied to software. Of course mechanical engineers apply its principles, and have for decades before the term Agile was coined.

And as such, this practice is far older than software.

The Apollo space programme is my favourite example: the ultimate goal remained fixed (man/moon/before end of decade), but all steps of the way were discovered and redefined over the programme's course.

Mission objectives were changed depending on what was learned, often even in flight.

This was a very nice and agile (and sensible) approach, regardless of what it was called.

[mattmanser]

You're just offering your own special definition of "agile", that of course doesn't fit anyone else's definition, and especially any agile consultant's.

Of course, even more ironically, it doesn't fit the original agile manifesto:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

https://agilemanifesto.org/principles.html

[pipelineist]

> You're just offering your own special definition of "agile",

I'm not so sure.

What's the official definition? Don't give me the manifesto, that's just an implementation of common sense in development, as applied to software.

As a trained mechanical engineer (maybe that's why the quote about mechanical engineers irked me especially), the agile manifesto just reads like good engineering practice to me.

And indeed the signatories of the manifesto expected to start a huge discussion on what agility meant for any particular team or product, and how to best live up to its principles.

> of course [it doesn't fit]

That was uncalled for.

> and especially any agile consultant's.

I'm (something akin to) an agile consultant though :-)

Also, just to point out: maybe my definition of Agile diverges from canon. That's OK. I don't care to follow the canon, I care to do right by those who I've been asked to support.

> Of course, even more ironically, it doesn't fit the original agile manifesto:

> > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

I'm not sure how you came to that conclusion.

How is "welcome changing requirements" a bad fit for "changed the mission objectives (as new information emerged)". Clearly the [competitive advantage/likelihood of success] was increased? In fact the entire programme was shaped such that change was explicit part of the plan.

I've stared at this quote for a while now, and I still can't see the contradiction.