I've had one great experience working in an "Agile" team using the Extreme Programming method. I have fond memories of pair programming, starting work by writin

I've had one great experience working in an "Agile" team using the Extreme Programming method. I have fond memories of pair programming, starting work by writing tests with the business analysts, and focus on principles : DRY, YAGNI, no hesitation to refactor what needs to be. The driving forces were those principles. My other experiences with SCRUM, on the other hand have either been deeply dysfunctional, or just plain devolving into churning tickets. The driving force were metrics, velocity, charts. I agree with one of the conclusions of that article (but not the title) : Agile has been taken over by SCRUM, for most people now Agile = SCRUM. However SCRUM is so successful precisely because it fits into the existing hierarchical structures, it gives the impression of control to managers who don't understand what software development is about, and it avoids having to profundly question corporate organization. It's at its core a management technique. If all implementations of SCRUM get it wrong, then SCRUM itself must be wrong. I think an alterative way of doing things would be to create small teams that incorporate both programmers and business people, without product owner or project managers or hierarchy. The work would be focused on one specific project and driven by principles of craftsmanship. I've yet to try this idea in the real world...