But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment.
Not something you have conferences about.
Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
Sort of the opposite of agile.
> Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work
Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
But you can't change the process to be not-Scrum.
Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand?
Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints.
Ultimately if the overhead is too much we used the retrospectives to remove it.
The problem is if you're the only one in the team that wants some change - then you cannot force it.