Comment Re:Good idea, hard to implement in the real world. (Score 2) 507
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
Cannot be restated often enough.
I've worked in a shop that started doing "Agile" development after years of more waterfallish practices. This essentially meant that we started to get customer requests organized in an Agile toolset and then had a sprint planning meeting to negotiate the value of the various requests so that we could start work on them. Standups often took a half an hour for 6 people, including the PM, who unfortunately doubled as the scrum master. It wasn't terribly agile, and it didn't buy us much other than better tracking of issues.
And I work now at a medium sized company that does everything with some variation on Agile methodology (with some Kanban thrown in). We use Agile as the base framework for our development, but we adopt other practices that make sense, and we've agreed as developers (with the PM) on how it works best for us. Standup was 15 minutes this morning for a (largish) team of 9 developers - and that included some non-standup topics that snuck in. Retrospective for a two-week iteration is an hour to 1.5 hours. Planning is also about that long, including tasking - but we have one or more one hour grooming sessions during the iteration to keep our work backlog properly sized and ready to go. We code review each other's work, we communicate openly, and we know what's going on and how our work fits in with the overall product line because of that. It just works, and from a psychological standpoint it's good for morale to see the progress being made.
The difference is in committing to the actual goal of Agile - producing working code in manageable bits while minimizing unnecessary overhead. It's easy to go off the rails by misunderstanding Agile or half-assing it - you just have to get it right.