Responding to change over following a plan
The whole point was to be agile enough to work in a manner that's most effective your team and organization - and even that may change on a project-by-project bases if different stakeholders are involved.
Responding to change over following a plan
The whole point was to be agile enough to work in a manner that's most effective your team and organization - and even that may change on a project-by-project bases if different stakeholders are involved.
There's no scope creep with agile, only responding to feedback.
So any actual working system can be stamped as "not agile" as surely there will be some aspect that is not perfect.
My favorite was "Customer collaboration over contract negotiation": a contract is there to protect both parties, so of course it will be central to a project and people will preferably stick to it, even adjust it when it doesn't fit the bill anymore. So in any case where things go wrong for whatever reason, we can inevitably say more collaboration was needed and that Agile principle wasn't respected.
That probably comes from the same sentiment as parents telling their kid to not fall from their bike, it's in human nature.
No, there is something concrete there: No managers. Traditionally those would be the concern of the manager. Agile says it best be the concern of the developers.
Which, of course, is Agile's whole deal. It is all about self-organization. The Twelve Principles goes into more detail about what to think about in the absence of managers; to ensure that developers take over the jobs that managers would traditionally do.
Ironically, it seems only managers have an interest in Agile, in a bastardized form, as a way to push their workload off onto others, but without giving up their paycheque. Which is also why we're seeing a death spiral now. With higher interest rates seeing businesses cracking down on the work being done, managers are finding it necessary to shape up and start doing their job again.
The one you will find in the Agile Manifesto and related writings. e.g. "Individuals and interactions over processes and tools"
The other is a top-down, upfront-planned, tool based, process heavy corporate method of task-based micromanagement. Usually in Jira.
There would be no point in killing Jira, as the management that wants what it does, would simply find a similar equivalent.