I think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agi

I think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agile". It doesn't help that several books, blogs and consultants try to convince you this is the case. The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything. This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money. Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are: * Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense * Stop building systems or components, and start thinking about everything as user stories Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again. Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess. However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.