With respect to all involved, I've so far worked on two projects using scrum, and hated it both times. The biggest problem for me is something I haven't seen to

With respect to all involved, I've so far worked on two projects using scrum, and hated it both times. The biggest problem for me is something I haven't seen too many people mention here - scrum apparently goes hand-in-hand with feature-driven development. Some list of requirements is divided up into small vertical slices through the software, which are drip-fed to the team via the backlog; the end result is akin to building a house in vertical slices. It's possible to work like this but very difficult and without near-prescient levels of foresight on the part of the team leads to large amounts of otherwise unnecessary rework, especially when the requirements inevitably change, which is supposed to be where 'agility' comes into its own. That's not agile, it's clumsy and wasteful. Far better in my experience to spend time analysing the requirements as a whole, to distil the essence of what's being developed, and design a set of components that express that essential nature in a flexible way, such that the features arise out of the combination of those components rather than being developed in isolation and then mashed together as the project progresses. Accept as a given that intial requirements are just a best guess, and design accordingly - to cram piles of poorly-thought-through code through reams of unit tests is to fight this reality, not to embrace it (note that this is not to rag on unit testing itself, which, like any good tool, is extremely useful when deployed appropriately). Doing this kind of analysis up front and then developing the components using scrum - that would probably be OK, but I've yet to see or hear of anyone doing that. As for the process side of scrum: stand-ups are fine if they are kept very short and simply used to express and work through problems, but this appears to require active policing to prevent people rambling, and the retrospectives again are potentially useful, but in my experience turn into long awkward sessions of scratching around to find items for the 'things that went well/went wrong/would change' lists - and more often than not 'things that went well' could be summed up as "we all did our jobs". Celebrate genuinely awesome results, sure, but as a software developer, I don't need or want a pat on the back just for developing software successfully. Overall I would say that the principles of scrum sound nice but when they meet real people the results are somewhere between mediocre and painful.