I believe nobody told management about the cost of Agile: Management gives up control of the scope. It is the developers who decide how much they will do until the next deadline. If management refuses to give this up, then Agile becomes a farce.
In the words of the manifesto, what management does when it rejects the committed scope of a sprint is contract negotation instead of customer collaboration. The contract in Scrum is: Stakeholders (including management) decide stories and their priority (usually indirectly through a product owner) but the team decides how much they commit to for a sprint.
Agile is a useless term... it’s basically a virtue signal for business.
Where did "commitment" even come from? Not that the manifesto is a sacred document but it's not mentioned there. It's something that got bolted on later as a way of extracting more labor from developers by exploiting optimistic estimates and bravado in sizing exercises (something else that got bolted on by consultants as far as I can tell).
Scrum, in some of it's fundamental practices, is antithetical to agile but this tension is actually great because it justifies a parasitic priestly order in the form of consultants
This commitment is a Scrum thing. In a business environment there is no way around some commitment between parties.
I’d argue that one of the best systems to manage development is kanban in its purest form. Just the board, broken down into backlog, doing, and done — possibly with a sub column for ‘doing’ to represent “blocked”
For developers who run into snags, and can’t really nail down accurate estimates, it means all you need to do is break down tasks into manageable chunks, and work on one at a time. For managers organizing coordinated work effort with mercurial resources, it means a continual ability to communicate immediately to everyone what is most important to work on and to see where every one is at with work. And for customers with fickle requirements, they get to mess around with undone work as much as there’s like... might still turn out to be a shit project, but annoys everyone less in the process.
1. It’s dead simple
2. It can be constantly picked at without really affecting current work of development resources (assuming tasks are broken down into small enough units)
3. The state of the project can be quickly gauged at any time
4. Metrics can be generated with minimal (or no) disruption.
Where even kanban fails is that it is employed by people who feel an overwhelming need to tinker with it. No, we don’t need due dates on almost every single task. No, we don’t need complex software for it that takes 5 steps to create a ticket, where 2 would do. No we don’t need meetings about what we did... they can be 5 minutes and only need to address anyhing blocking us.
Everything else that people think they need from an organization system for development is either redundant, irrelevant, or is better suited to not belonging as part of a formal process that all parties need to adhere to.
+1 I have done kanban and scrum and my experience is that kanban can generate the metrics that management wants without all the useless scrum meetings, jargon, and so on. Making sure that tasks are roughly the same size is the only tricky part.
Tricky for sure... but even if they’re lopsided, there’s opportunity for refinement as the process moves along: too small, well your getting things done ahead of estimation. Too large and just chop it up smaller and throw those tasks on the backlog at the top.
Stuck with a Trello board full of crusty old mildew as have a PM who suffers from combination of inability to complete a sprint with over enthusiasm to start a new sprint.
Who can run a marathon by sprinting one hundred meters back to back to back to back to ... ad infinitum ad absurdium.
Self reflection is a key attribute of any sane system.