> Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth.

That's not agile.

> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.

Maybe this is why so many people can't even try to do agile. It sounds bad. But it works great.

> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.

Oh that was it you're right. We have those documents but they are full of lies. Yet everyone can read it and believe it to be true in the way they want it to be.

In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing.

In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.

Author here.

Well I think this just proves we can slap "agile" onto anything. The people before agile actually wrote things with more substance than the manifesto.

The agile projects you worked on sound wonderful, and I would align "writing specs" with what you describe, at least in terms of the design doc.