The concrete "how it's done" and the "culture" of the people involved - how they behave with each other - will influence your experience with them much more tha

The concrete "how it's done" and the "culture" of the people involved - how they behave with each other - will influence your experience with them much more than the ideas behind these methodologies. I've had a very positive personal experience with them, and I can give you a point of view as to how they work and why they can be a positive way of working. Regarding the "standups", for example, they are definitely not meant to be about "micro-managing", "signalling process" or any kind of "status report" (definitely not to a manager!). The idea behind these kind of agile methodologies is to allow teams to self-organize. The standups are meant to be a brief way for the team members to catch up with each other, and seek help if necessary. There's no need to say anything if you don't feel that you need to sync with your team members, and it's definitely a way for managers to control what you are doing. When done right, they are short, concise, helpful and positive. The same idea applies to the "retrospectives". Don't call them that if you don't want, but it helps to get together as a team and see what you want to change in the current "way of doing things" - and it's good to actually have the autonomy to change it!... About the concept of "sprints". Dividing work in sprints is both about planning and, again, about self-organization. It's about fairness in a way: leaving developers the time to deliver something, in a way, "protected" from route changes and with a clear goal of something to deliver. But it's also about not setting up goals too far in the future. Because the goal is set up in (usually) a couple of weeks time, the results can be analyzed and the product, or whatever, developed incrementally, with management reviewing the progress bi-weekly. You wouldn't want to set a goal three months in advance and discover at the end of that period all the things that you assumed were one way that were actually not that way. "Agile" touches several points and one of them is that during work it's important to talk face-to-face about requirements and how whatever you are building is meant to work. That is, as others have commented in this thread, that it's a good thing to have a conversation during development with whoever is the representative of the product side of things to solve doubts, instead of relying on a list of requirements. That's, from my point of view, less bureaucratic than a formal process. The regular meetings are also meant to be lightweight and to the point. You don't have to have a highly formalized process to "point" tasks. The underlying idea is to try to allocate a reasonable amount of work to a certain period. That also does not mean that bugs or unexpected issues can't be fixed during the sprint - there are ways to make all that work. You have to understand what all these practices are for, the ideas behind the whole thing, to do them right. And you have to work with people that behave in a certain way, that have a certain good will, that have a certain working culture, the righ experience, etc. The particular circumstances will make all the difference. I think that seeing some of the answers in this thread it seems a little bit discouraging, but, in my humble opinion, one just have to be lucky, find the right company and the right people to work with. I hope that my personal perspective helps.