It was never for the developers.
Your first sentence became correct after managers and MBAs co-opted the term and turned it into "AGILE" which has almost nothing to do with "agile".
Maybe we should call it !AGILE ;-)
In my limited experience, Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly.
You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you. Sprint review will show a decrease in completed tasks and everyone will wonder why. At the next planning you want to add stories without story points? The horror!
You are part of an Agile team and also have to do stuff for another team? Good luck closing your tasks without missing stuff that was assigned to the Sprint.
Daily meetings take more than 15 minutes? That's not how things should be!
Kanban is a much more reasonable approach, because its focus is on "flow" and not "whatever we decided three weeks ago without taking into account things outside of this team".
> Scrum usually comes with a bunch of people who think Scrum principles come from some holy book and act accordingly.
> You can't estimate how long your tasks will take because you are flooded by interrupts (coming from outside the Agile team or even from within)? Well, shame on you.
It sure has a book (in fact, many books), but that doesn't mean it should be treated as the <enter favorite holy book, if any>.
Before ITIL4, ITIL v3 (a famous IT service management framework) didn't mention Agile. Changes must be requested (including the actual configuration items you want to change), someone else evaluates them, if the risk is too high you need approval for a specific board, and so on.
Companies were following ITIL practices to the T, and some people said "don't you realize this whole thing is ridiculous in most cases?".
Cue to Agile. Sure, Agile itself promotes adapting to the environment, people not process,... But then Scrum with its rigid practices is treated as a sort of religion, leading some people to say "don't you realize this whole thing is ridiculous in many cases?". Pretty ironic.
> think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously.
I agree. Doing stuff and estimating stuff are clearly different skills. And it is well known that many programmers estimate time by doubling, or even multiplying by 10, the time they expect to require for a task. So you have some people who vastly overestimate, others who underestimate,...
If something is to hard to implement, maybe it is the problem.
If you use agile, and it doesn't work for you, it's because you did it wrong.
It's the law of attraction, in software development.
As a _philosophy_, Agile gets those things done. It's fine.
As a _process_, as most places that "do Agile", it exists for it's own benefit and not for what it _does_. In almost all cases, it's a people problem more than a process problem, but no process will solve those sorts of people problems.
Well kinda. There’s wisdom in crowds (sometimes). If it doesn’t just naturally gain adoption then that has to count as a negative. Maybe the positives outweigh the negatives, but I think that’s arguable.
It was never appropriate. It was created by consultants to sell consulting services. In that way, it's a huge success. As a practical development methodology, it's always been a disaster.
I found it quiet genius move from their sales teams. Because usually customer went well actually i could also use feature x, y and z that didn't made the MVP product.
This is not how it works. "All revolutions are conceived by idealists, implemented by fanatics, and its fruits are stolen by scoundrels" — Thomas Carlyle.
Dunno about the last, but I have gotten a bunch of value out of Beck's TDD book and Fowler's refactoring book.
Meanwhile Kent Beck [1]: "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"
This is an absolute nightmare for retention and recruiting. When I went to university to learn about computers and technology I always dreamed of writing user stories and doing other mostly pointless clerical work.
Now we have agile coaches (per team), agile leads (all teams' agile lead), scrum masters (the guy who does the meetings), and project owners (giving requirements), and lead project owners (planning) all trying to get developer time and attention.
Right size this, OKR that, attend this attend that. Wasn't agile always about finding what works best for the team and doing it, with consideration of tracking what works well and what doesn't, and refining the process to fix it?
Now it seems to be some sort of glorified job role, so even if the team get it right and run well they're patronised into attending non stop meetings from non technical staff trying to justify their jobs and whose own job role even states if the team is running well and self organising, then they need no involvement.
All I hear these days is, how can we fix that? And the team answers; the delay is off team, in either third parties, business itself, or we've worked around the bits that we can.
The dev team is now being asked to fix other teams' delay causing problems and then effectively silently shamed for not doing it week after week (because it gets raised again and again).
This is end game and wasting time if you're team reaches this point, yet the coaches still pound that shaming in like there's something that can be done in team. Of course these meetings aren't meant to do that, but when has human psychology ever been considered (being asked how to fix something a dev has no control over is now a common theme in questions I'm asked)?
IMHO agile in its current bastardised form should be taken out the back and shot. When it became a rigid set of rules (oh but "that's not how it's meant to be applied" is the war cry!) which promotes long term job roles preaching it, adds nothing to the teams' ability to adapt, and the team is already meeting most sprint goals and deliverables, the team has hit peak agility already.