>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 <ente

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