Over the weekend, there’s been some discussion on the interweb about why Agile is “failing”. James Shore (Agile consultant and author of the book Agile Development), wrote a post on his blog about the perceived Decline and Fall of Agile:
“…many people who call me already have Agile in place (they say), but they're struggling. They're having trouble meeting their iteration commitments, they're experiencing a lot of technical debt, and testing takes too long.”
He goes on to describes why these teams are struggling (emphasis mine):
“But they aren't working in shared workspaces or emphasizing high-bandwidth communication. They're don't have on-site customers or work in cross-functional teams. They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.
These teams say they're Agile, but they're just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It's the reward, not the method.”
The big selling point of Agile has always been that it will let you, well, be agile. Employ an Agile process (like Scrum), and you’ll have a happy customer who will be allowed to influence the project and change the direction it is taking along the way. As James writes, however, this is the result of employing an Agile process, which implies that there is some input required to produce this result. In a follow up succinctly titled Dirty Rotten ScrumDrels, Uncle Bob Martin puts it in layman's terms, explaining that “it is neither the purpose of scrum nor of CSMs to make engineers out of us, or to instill the disciplines of craftsmanship within us. That’s our job!”
Go figure – developing great software requires competent, dedicated engineers. StructureMap author Jeremy D. Miller follows upwith the recipe you and I need to follow in order to cook up a tasty soup of Agile:
“You wanna work adaptively instead of the ol' fashioned plan driven method? Fine, but you've got to make that adaptability safe. You need rapid feedback cycles to know when you're getting off the rails (customer demos, TDD, Continuous Integration, automated acceptance tests, static code analysis or some sort of equivalent). You need to take steps that make continuous design methods safe and effective (simple design, a constant attention to design fundamentals like the SOLID principles, and an intolerance for technical debt). And your team needs to be retrospective about its work to make adaptions as they become necessary.”
I’ve written about this before; you cannot reasonably expect to successfully employ an Agile process if you aren’t writing Agile code.
