3 ms·

Agile, as in fast, periodic cycles of gathering requirements, design, implementation and release, is a good idea, especially when this matches your scenario. I

by arter4 3y ago

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".

andrekandre 3y ago
> 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? [0] https://www.scrum.org/resources/scrum-guide https://www.scrum.org/resources/scrum-guide
- arter4 3y ago
  >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,...

by arter4 3y ago

andrekandre 3y ago

> 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? [0] https://www.scrum.org/resources/scrum-guide https://www.scrum.org/resources/scrum-guide

arter4 3y ago
>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,...