Why do people always say agile doesn't work and then tell some personal baggage story that clearly shows their company is doing it wrong. Is agile really to blame?
Agile, as in fast, periodic cycles of gathering requirements, design, implementation and release, is a good idea, especially when this matches your scenario.
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.
well, there is the 'scrum guide' so its not surprise imo [0]
> 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.
i think the fundamental issue of scrum/agile is thinking one can estimate accurately in the small/short-term and do it continuously. if you have deliverables every quarter for example, as long as they are delivered isnt everything else just superfluous?
>well, there is the 'scrum guide' so its not surprise imo [0]
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,...
Yeah wherever I've been, it has worked quite well? Where I've worked at the focus has been on short iteration cycles and delivering value to customers, and retros were used as a tool to identify where we can improve. We didn't have any rigorous process, just added and removed processes where we saw it was needed, didn't have any scrum masters either. Sometimes I've been in teams where we removed standups and grooming, when everything was crystal clear. Then later on, we added them again when we had new people and scope was less clear. I think that is in the spirit of agile, and it has worked decently where I've been.
Is it a wonderful process that would work with any team or is it a wonderful team that would make any process work, or maybe (what I think) has the team evolved a process that works based on influences like agile and team dynamics, and is probably still refining it.
Agile is like communism - everyone does it wrong but if done right it will work. Every single company doing agile sucks at it. All you need is to have a brief chat in the morning, and every couple of weeks go through what needs to be done and try to estimate things. Stuff not done spills over. Agile militarism is about turning software into manufacturing and it clearly doesn't work.
Way back around 2000, I worked at a company that used what most people would think of as an agile dev process, administered by the devs, for the devs, and it worked pretty well. It did the thing that a software process needs to do: let everyone know what was important, who was working on what, who needed help, and what needed to be done differently. And it was good.
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.
Making full time job roles around it imho is doing it wrong and this was an industry decision. Agile consultants (or fixed length contract) yes, full time roles, no unless they are going to start removing actual impediments in day to day work rather than remarking on them.
reply