This is not what the article is about. If you look at the Agile Manifesto, it says e.g.

- Individuals and interactions over processes and tools - Responding to change over following a plan

What you get in quite a few big companies following "Agile" with the air quotes is the opposite:

- Processes and tools over individuals and interactions - Following (and making) a plan over responding to change

Because that's what makes middle management happy.

So this perversion of "Agile", which is actually the opposite of Agile, is the FUNDAMENTAL problem.

I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are, frankly, ill-defined bollocks.

The principles are better but still suffer the same problem. If the most efficient way to convey information in a dev team is face to face why don't you come over here and I'll whisper my pull request in your ear. Jesus.

There's no point complaining about the perversion of a thing that was never very specific about what it wanted to be in the first place.

Once people (especially managers) get specific about what agile means to them it turns out it means very different things to different people. This is entirely the fault of the originators.

One benefit of Scrum (the catholic church to agile's christian sect) was that it was proscriptive and was specific. Unfortunately it's also a bit shit and its practitioner-priests LOVE to tell you that if it isnt working, well, You Probably Just Weren't Doing It Correctly.

thank you, Thank You, THANK YOU!

It is a useless set of vague platitudes which offered nothing but a sense of seeming aphoristic depth. How so many people fell for it is still a mystery to me. Instead of focusing on the core problem of Requirements gathering and Software Specification, well known trial-and-error approaches were dressed up as something profound and a whole industry was created out of thin air. People seem to have forgotten the works of Fred Brooks/Barry Boehm and that their iterative "Spiral Model" IS Agile. There is nothing new i could find in the "modern" Agile/Scrum movement except mindless emphasis on Processes/Tools which is insanity, eg; The position of "Scrum Master" is the very definition of a "Bullshit Job" and should be abolished forthwith.

Where I work there was a huge shift in this.

From Business analysts (BA), who usually had comp sci or engineering degrees, and an expectation to get PMP and CBAP / PMI-PBA / other BA certification to move up, were responsible for requirements.

Now we have product managers and scrum masters with a 1-3 day agile certification and no comp sci or engineering background who are responsible for requirements.

Nothing is worse than non-domain knowledgeable, non-technical people lording it over actual Technical Engineers who do the work.

I always recommend Dave Packard's 1960 "Speech to HP Managers" to every "Manager" - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...

Relevant Excerpt:

Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.

This is how great companies were built.

At least the Church only had confession once a week in private.

And treat this comment as an acknowledgement for all future occasions on which I quote you.

I wish I could upvote this more.

Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.

> I once had it used against me to justify not writing tests

If you thought of your work as a complex system where there are a lot of variables which have multiple underlying causes, then you would have been able to describe some undesirable effect as being heavily caused by not having writing tests. And really, this is why people don't get Agile--they don't see their work and their organization as a complex system.

Funnily enough the features of language which are ideally suited for flirtation and writing poetry and preaching religion or nationalism and other such "let your fantasy go wild and fill in the gaps" uses of language aren't as appropriate when you're doing engineering.

Law and contracts ARE different (more like engineering), incidentally. What is described as "legalese" actually exists because non-legal equivalent language is often insufficiently precise and subject to dangerous and costly misinterpretation. Mathematical discussion has the same problem to such an extreme degree that it's almost pointless using English at all most of the time.

>And really, this is why people don't get Agile

The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.

Yeah but that's not the point that I'm making, is it? What I'm saying is that people project their own meanings into language all the time regardless of whether the language is being used in deeply personal interactions or in professional settings; therefore you can't just fault the Agile manifesto for its supposed "ambiguity".

On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?

Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence:

> The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.

So then is it a problem with the manifesto or with the people?

That was MY point.

>therefore you can't just fault the Agile manifesto for its supposed "ambiguity".

You absolutely can. They didn't have to write it in an obtuse, ambiguous and metaphorical way that practically required people to project their own meaning. They deliberately chose to.

Scrum is a clear example of a methodology that is relatively (not completely) unambiguous. It's describing (in theory) a much more concrete form of "aspirational agile" and as such is at a lower risk of becoming all religious.

>On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?

It's a sliding scale. Flirting and poetry is way over on the far left with the agile manifesto. Scrum is further to the right. Legalese is further still to the right. Math further still. It's fairly self-evident that the level of specificity required in the language used varies depending on the task. Being too specific when you flirt is common sitcom grist and nobody's ever made poetry out of a shopping list.

>Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence: So then is it a problem with the manifesto or with the people?

It's the manifesto.

Beautifully said, you have a way with words!

The outputs they seek are emergent.

You also belittle scrum for becoming too specific.

Seems you’re still processing what to make of any of it.

Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs.

It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions.

No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality.

Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue.

The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details, but wanted some way to push people in "that sort of direction".

The net result either way was... well, a kind of religion.

>You also belittle scrum for becoming too specific.

No, I didn't belittle scrum for being specific. It's one of the good things about it. It is, however, a specifically defined bad way of running a team. We do need designed processes as specific as scrum, that are less one-size-fits-all and that have a more systematic and refined approach to software quality, estimation and design.

"Scrumban" is definitely an improvement, but even that is still lacking.

I'd like to see software team processes treated in many respects as a kind of "software to run teams", specifically meaning:

* That it gets iterated frequently and responds to feedback at every level (not just team, but philosophically - by its founders).

* That it's clearly and precisely defined.

* That there are a variety of different config switches depending on circumstances (e.g. number of people, skill distribution, are you building CRM or flying space rockets, etc.).

* That the individual pieces (e.g. retros, sprint planning) can be chopped and changed and upgraded/iterated on individually and yet still couple to each other sensibly - akin to the UNIX philosophy.

>Knowledge work is immaterial and should have no prescribed rails

No, anarchy is no good either.

> they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details

Money quotes!

I had attended a presentation by Kent Beck on "eXtreme Programming" well before the Agile/Scrum movement started and came away with the exact sentiments listed above.

Anarchy is no good.

Haha.

Your efforts are constrained by physical science, social objectives.

There’s plenty of structure to prevent anarchy.

But you would further impose problem solving constraints on others thought work.

Shit n hellfire; what a dumpster fire of a culture.

Would you say something as minimal as “E=mc^2” promotes anarchy? It hardly illustrates the full meaning of relativity.

Perhaps where you perceive emptiness and anarchy, others perceive correctness and order.

Like religion; one mans abstraction is another mans insanity.

The 17 authors of the manifesto.

>But you would further impose problem solving constraints on others thought work.

I would, yes. I've worked with a diversity of methodologies and several times with no explicit methodology all and in a team context we ended up a disorganized mess.

It’s not to bring order to chaos. It’s to afford shelter, food, and healthcare.

Sorry, not sorry.

Perhaps you’d be happier living as a hermit, where you can organize as you wish; everything just so! without the rest of humanity, that does quite a bit of the heavy lifting for you, interfering.

"What ineffable twaddle" !

I highly recommend to you the works of David Parnas, Barry Boehm, Fred Brooks, Gerald Weinberg for edification.

Start with the paper; "A Rational Design Process: How and Why to Fake It."

(1) The Manifesto is written in non-actionable terms.

(2) Many of the same people that initially attached themselves to the manifesto were already pitching canned processes, that may have been the outcome of agile process where they originated but did not put the critical feedback mechanisms more prominently than the low-level processes. So, those became the actionable versions of “Agile”.

It would be so much better if instead of the “X over Y” language, the Manifesto has spent a few words talking about how the less important things were subordinated to the more important ones.

The weird thing is that continuous, bottom-up, empirically-based process improvement wasn't an unknown concept at the time the Manifesto was written. It wouldn't have been hard for it to reference more concrete, actionable, concepts and practices.

I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “improvement” we will get is millions of dead and injured. But for whatever reason we allow freshly minted certified scrum masters to lecture seasoned professionals on process, to organise 19 meetings a day to discuss the differences between scrum and agile and, in general, to unleash havoc and destruction.

You should collectively have just refused to work for them in this case.

They're not called scrum masters but the healthcare industry is absolutely full of them. One peculiar thing about the covid crisis was, at least around this particular corner of the planet, in the all-hands-on-deck situation where everyone on the floor in healthcare had to help out, these people suddenly found other things to do. It was impressive to see what could be accomplished when everyone was focused on a singular goal, without a coach in sight. I'm sure there's a lesson there somewhere.

Concluding: It is certainly refreshing how efficient groups can be once a crisis forces all attention towards one single goal. (Perhaps unfortuntately) that is not a reliable (crisises are usually not predictable) nor sustainable (other goals tend to get neglected in crisis mode).

Since the purpose of a hospital is not to make money but to improve health-related outcomes, this is usually bad.

On the other hand, it turns out that focus on improving health-related outcomes by applying science and statistics works really well... and usually decreases costs, too.

This is no guarantee any more. Newly minted managers coming from a development position that have only ever worked in dysfunctional organisations (and got promoted from within) will only reinforce the existing bad practices.

Give it a few years.

I think the GP meant "in hospitals" as in "among medical people", doctors and nurses, not IT staff.

Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does.

Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners.

Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea".

Docker had the philosophy.

Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is...

>but insist to intercept every decision

Yes, because left to our own devices, developers will not contribute meaningful business value.

There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me).

WE as engineers need to find a better way to engage management.

But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please

I beg to differ.

A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint.

You need this team lader role to keep the suits off your back, and to ensure the demands are achievable.

Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.)

> Yes, because left to our own devices, developers will not contribute meaningful business value.

I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.

That’s a view in many large corporates. However, in product focused companies and many startups every developer has to have a customer focused mind. Every single day.

We have to specialise at some point - not everybody that gets hired is going to be an ace industrial strategist. Few devs know how to qualify a sales prospect. If you have such people in management, then as a dev I don't want to do their job for them; they should set strategy and find good customers.

I guess we all have differing perspectives on this kind of thing; one's perspective is partly formed by one's experiences.

I'm not talking about startups - I never worked in one. But I've worked for quite a few companies with < 20 staff.

When I first started we would be doing 1-off feature requests "because the client would _really_ like it". Everything was justified because money and because "we cant afford to lose that customer!" in our SaaS product.

I saw our main product being neglected because we'd invest so much time in these 1 off features only 1 client would use. All we would ever do would be client features, I was going crazy. It took a lot of talking, and still to this day I have to get him to think in terms of the product instead of the individual client.

Now we make more money, have more clients, and better our product for everyone which in turn gets more clients to get more money.

Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable.

In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.

The project I work on has around 100 regular contributors, but also a few small teams, either volunteer or staff, who meet regularly and make sure things move forward in a coherent and sustainable way.

If that's true in an organization, its only because either management has failed to hire developers that can self organize, or management has constructed structures and incentives which inhibit self-organization by developers. Usually, both. Often deliberately, because line managers are often more comfortable passively recieving directives from above and crafting directives for below than any other mechanism of management, since this minimizes conflicts with those in organizational power positions.

Problem is that the industry is full of untrained individuals who hustled their way ”fake it until you make it” and will use all their political and manipulatoy clout to justify their positions and fight back any attempt at effective process engineering.

It is very convenient then to shift attention to inadequacy of others.

I don't understand how your vision of things is not also contributory to a strong divide.

Heard of Linux?

Can you find one dev that has ever disagreed with this?

Get to rewrite the micro services, Kotlin, Cassandra, Kafka, mongoDb hardly documented, back into C# on top of SQL Server when the teams have left for the new jobs after haved pimped up their CV.

You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.

If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.

Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there.

If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.

Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff. Apple even changed the language to one that (unlike Typescript) is not backwards compatible. Complaining about the JS ecosystem evolving too fast is anachronistic, that happened more than 8 years ago.

No they haven't. You still write them in Delphi or Free Pascal / Lazarus just the same way you did ten years ago.

Oh, you meant "the way of writing native Windows apps" with Microsoft tools? Yeah, well... Heard the old joke about the guy who complains, "Doctor, doctor, it hurts when I do this!"? My answer is the same as the doctor's: Well, don't do that then.

The naïve thing to do when you’re a manager is to manage more in response to problems. When you start out with an agile process, and you manage more / manage harder, you end up with no agile process at all.

Scrum masters / agile coaches are very hit or miss. Just like managers, just like programmers. Management takes the blame because their failures have a larger blast radius.

Agile is Dead - https://m.youtube.com/watch?v=a-BOSpxYJ9M

Here’s a blog post by him: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html

If that’s not following a plan over responding to change, i don’t know what is.

Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem.

By being easy to adopt, software lends itself to an iterative design process, where you adopt it multiple times based on the iterative feedback of the customer. But this means that at the end of the design process, you can skip the manufacturing part, as you've already built the software during design.

Alternatively you could argue that this is too expensive, inefficient and slow, and you need some design before you begin to manufacture software. Modeling tools could help here, e.g, low code tooling like CAD tools in fysical product design.

Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.

(And I think for completeness' sake the next two need to be included too.)

Early in my career somebody said something like "make sure you distinguish between <<what they (customers) want>> and <<what they need>>.". This thought stuck with me for years and in my opinion has been reposible for success I witnessed.

It's important to unwrap "what they want" so you, as developer, can apply more first principle thinking to arrive at "what they need".

BAs have tendency to project their own solutions, however when unwrapped so you see the problem that needs solving, you may arrive at solution that is simpler (like orders of magnitue is not that rare in my experience), reflects reality better, takes advantage of somehow hidden from BAs PoV system internals etc.

Agile enouraged dialogue is the platform where those ideas can surface.

Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be.

So the same mismatch is bound to happen anyway.

And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery.

Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios.

EDIT: several typos

Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.

I have always appreciated product managers who effectively intermediated customers, had deep domain knowledge, managed stakeholder expectations, learned how to interpret what they said (and ignore what isnt relevant), asked the right questions, prioritize effectively and output to me a nice set of, de-noised, ordered, precise answers to the question "what do I do next?"

It's a rare skill. It boosts my productivity immensely when done right. It removes cognitive load from the developer.

Even when POs make mistakes and misinterpret requirements I still appreciate that being somebody else's problem. It quells my anxiety immensely and lets me focus on developing the thing right without having to worry about whether Im developing the right thing.

These agile ideas only work in an ideal world of "we are all friends here".

The skunkworks teams the developed the Apple MAC is one very good example.

The majority will rather pick other vendor that doesn't propose such change into their internal processes.

Unless they are asking for consultation on how to change work processes, that is.

"I thought this was your job" is something I've heard a few times from clients when we have sent over wire frames or beta applications.

Especially in B2B and technical realm it is feasible to actually plan in every sense of the word "plan" a new product - business, tech, etc. Of course the plan must be malleable on the facts on ground. And probably is incorrect on a few places. But never the less, a plan that will get a business from place a (no product, but strong understanding of customer needs and business plus strong technical savvy) to place b (final product, customers, revenue etc).

I've seen this many times, both in startups with a new product and new customers (automotive software) and established companies that just expand their existing portfolio (cad software).

I'd say the "not an accident" is feasible if these facts are in place:

- enough A-team players (tech,business,sales)

- healthy culture (that facilitates long term growth and can focus on the product without too much politics)

- understanding of customer business

- identified an OBVIOUS need for the customer

- strong engineering org (can be just a few coders that get things done or larger)

So I agree, you can't train for these requirements like you can train airplane pilots.

But I do claim you can have enough understanding that is the current org in possession of these qualities. And if it is, it's a very reasonable risky investment to try to create a product for the need.

For internal customers or in B2B settings getting the actual users and outcome owners involved early is vital - but they are often poorly incentivized to get into the action as there are layers of business mangers etc in place that are supposed to stand in (but lack the detailed knowledge).

What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge.

You gather and freeze requirements. You write a massive plan and plenty of specs. You code accordingly. You deliver.

Time to working software is long and a lot of the effort that goes into specs is wasted, especially for design specs.

Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1:

> The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date.

> When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door.

> This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ...

This is as far from building a bridge as you can get. The next page of the book starts:

> [1.1] What is Rapid Development?

> To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week.

Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.

> > To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi.

Huh? Did you get the year wrong, or was he referring to a brand-new / not yet released / tool as a "standard" for some segment of his audience? AFAICR, Delphi was introduced in 1995, or at the very earliest, late 1994. Feels weird that he should mention it in a book published in 1994.

Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.

From what I can tell, that assertion is common in Agile advocacy.

But from my experience as a professional software developer in the 1990s, and from reading stories about software development, waterfall was not used at Apple, Be, Commodore, Data General, Infocom, Microsoft, VisiCorp, and more.

That's not to say no one used a (modified) waterfall model. Simply that I haven't found evidence that it's meaningful to say it was the standard development model. [1]

[1] Technically, DOD-STD-2167A's apparent bias towards waterfall was a "standard", but I don't think that's what most people mean in this context, and in any case it was replaced by MIL-STD-498 in 1994, well before the Agile Manifesto.

I don't see much value in debating this. It seems clear to me that the people who wrote the Agile manifesto have experience in working in such, or similar environment and reacted to change it. And clearly that way of working was widespread enough and enough of a pain point to strike a cord. Certainly, when I first read the manifesto it struck a cord and I understood exactly where they were coming from. I think it is spot on.

What raises my hackles is the lack of any qualifiers, given how rarely it's used in the projects I know about.

The objective function is some function of the quality of the product, as measured by the customer, and the work put in. The gradient evaluation is then the process of determining which feature gives the most bang for the buck, implementing it, and repeating.

But gradient descent has problems with local minima. So if that's what Agile is, no surprise it doesn't do surprising projects - even if the customer does know what they want. If the programmers are too inexperienced and it's not just a CRUD, then you'll end up with something like Jeffries' TDD Sudoku solver.

Lean is.

Agile is “It would be nice to do what works for your team in your particular challenges, not some pre-packaged one-size-fits-all processes sold by consultants. Now, here’s a bunch of pre-packaged one-size-fits-all processes, and an army of consultants selling them.”

You push decisions as far out as possible and gather feedback from individuals every step of the way.

This is what allows the greatest amount of flexibility.

The biggest problem with agile is that it assumes all problems can be put off to the last minute.

I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result.

This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)

I don't disagree, though I firmly believe Agile does a much better job of dealing with the problem you state than any other software development methodology that has been attempted before.

Is it perfect? of course not. As a methodology, is it better for building software than methodologies that have been used to build enormous physical structures for generations? Undoubtedly yes.

As far as I'm aware, there currently isn't anything better for building complex software with changing requirements (i.e. the real world).

The only thing that is less likely to have the building team and customer come to the same conclusion is to add many more layers in between.

I’ve seen where that ends. It’s not a good place.

If that were true the customer never drop you for the competition. The customer will drop you in a heartbeat.

The customer cannot express what they want in a language you can articulate which is something amazingly different. As a product manager you need to account for that.

It's a way to meeting actual business software needs, much more suited to custom development for one customer than product development, which necessarily requires some additional insight into what the market wants.

That's pretty much all you can do. How you organize it only matters insofar as it makes your team effective - sprints, waterfall, XP whatever... is kind of a toss up and context dependent.