I didn’t use those buzzwords because I wasn’t referring to any “methodology.”   The task of writing computer software is not at all like hunting a jackalope, where you have to sneak up on the thing.   It is something that for a variety of reasons must be delivered in-stages and with a nimble, flexible approach.   And it is an extremely delicate contraption, as any machine would be if it had an unlimited number of “degrees of freedom” in its movements – which computer software basically does have.

You can be “nimble” and “deliberate” at the same time.   In fact, the more deliberate you are, the more nimble you can be.   I have seen “agility” in the manner of Ginger Rogers (“doing everything that Fred Astaire ever did, only backwards and in high heels”) ... and “agility” in the manner of a staggering drunk.   Both groups claimed to be practicing the latest thing.

“We develop our software using the XYZZY methodology!”   Unfortunately, you have to follow that with the question, “... and exactly what does that mean to you and your team?”   At some times, it is a characteristic of a process that is ticking along like a fine watch.   At other times, it is excuses.

If you're doing the plumbing for a house, you can determine specific requirements: master bath, guest bath, main floor powder room, kitchen, laundry.

Each has well known standard components; bathroom has a bath or shower, powder room doesn't, kitchen has a dishwasher but laundry doesn't.

Piping, elbows, etc are available in a small variety of materials and sizes, usually only those acceptable by local building codes.

Basically, it's a well-defined job, though there's always the opportunity for change as things start being installed and you try physically moving between fridge and stove.

Software projects are not well-defined. You not only assemble pieces into systems, you have to first create the systems and components and sub-components. Imagine if you had to create all your nails, screws, bolts, clamps, and make your own glue before you could assemble a cupboard.

I respectfully dissent.   If a software project “is not (yet) well-defined,” then one has no business writing code for it.   It isn’t “a project” yet, at all.

You can figure out where to put the stove and the fridge ... and you’d better be careful to do just that, because the fridge needs 110v power but the stove is 220.   If you now want to go back and change your mind, you’re gonna have to call in the electrician, and re-do all of the tile (and buy more tile), and ... and ...   Oh yeah, and the vent-hood is going to have to be moved, which means that the layout of the entire second floor is going to have to be re-done ... and ... and ... And if we do that, we have to get the structure reinspected ... and ... and ...

Which is why you learn very quickly to make up your mind and stick to it whenever you are dealing with contractors!

But, yes ... stop and consider.   How many software-project cost overruns do occur because someone didn’t like where they put the stove?   It’s easy to see the physical implications of change to a physical structure.   You realize that you are playing dominoes.

Also...   let’s be less melodramatic here:   we don’t actually have a metal-forge out in the backyard, and no one is collecting iron ore to dump into a blast furnace in the basement.   We use a tremendous number of “stock components.” (CPAN is stuffed with them.)   We use toolkits of all kinds.   Sure, our contraptions are built of thousands of moving parts, instead of merely dozens.   But we do not start from scratch.