The magic of “agile” is that partnership with the customer and shared accountability.

That’s difficult to codify, especially in contracts for delivery. “Agile methods” more often than not translate into hiding a complete lack of planning in a bunch of mumbo jumbo.

It doesn't have to. It would be ideal of course.

The point is that there are always stakeholders and product owners - it just makes that explicit. If the PO is acting as a proxy for the stakeholder (customer in this case) that's ok.

Of course the PO might be wrong... but with small iterations that should be found out quickly and adjusted for.

Principle 4 of twelve: "Business people and developers must work together daily throughout the project."

https://www.agilealliance.org/agile101/12-principles-behind-...

It would be odd if "business people" just meant the developers' upper management within their firm; supervising costs and parking spaces; but not those without a stake in using the software that results, say.

Business people doesn’t mean customers however. Which was my point.

In fact the only time the customer is mentioned is in principle one: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Business people absolutely should be involved - product owners & stakeholders (or a proxy for them).

That’s fundamental but again: business people != customers.

You seem to think stakeholders/product owners are devs direct managers too. That’s rarely the case, if ever, on any functioning agile team I’ve seen. They’re orthogonal to each other.

I think I answered this possible objection, but you've ignored that. Also, I made a distinction between stakeholders and devs direct managers, rather than conflating them.

I don't believe I can be of further assistance to you.

Your answer fell short and is contradicted by the agile principles. Your distinction was practically meaningless given your later usage.

You were never any “assistance”. You had nothing of substance to add.

> I think the author left out something.

He made it quite clear, it's his conclusion:

Now, each iteration offers not only the chance for project management to be exercised, but more specifically, to ensure that it is exercised by capturing the appropriate, timely information from all the appropriate stakeholders.

Emphasis mine.

Not only is that vague, it's not the same thing. Polling stakeholders isn't embedding or involving.

Interesting perspective on what Agile is supposed to accomplish. From my anecdotal experience, it does not however, nor do I believe it will change.

The issue is one of buy-in. For it to work, everyone involved, client, management, development, qa, design, everyone has to be on board with the agile way of doing things. Without that, you have development working in the agile manner, believing in good faith that everyone else is too, and then the second a snag gets hit, then that all goes out the window, and development is usually the one left holding the bag and punished with overtime.

Right. Sturgeon's law, I guess. Agile Theatre is more common than Agile, just as security theatre is more common than security. So I'd say both above comments are accurate.