Ross Petit, an experienced developer, PM, and program manager working with ThoughtWorks, recently published an article on the common failure points of going Agile. On the face of it the practice of going Agile shouldn't be too arduous. In fact, often the Agile approach requires less process and procedure than more traditional methods of software development. So where does it go wrong? If the processes are followed how do projects end up with technical debt, unshippable code and all the other nasties that going Agile is supposed to avoid? The author details some mythical agile shortcuts:
We write unit tests, but it doesn't matter if they pass or not
Writing unit tests and automating them into the build is an obvious best development practice. While many people are willing to write unit tests, they are not necessarily diligent about maintaining them.
We pair, but only when we have trouble
Pairing is often considered a "nice to have" rather than an absolute necessity. The reality is that pairing maintains consistent throughput of Agile teams, as well as the great team benefit of knowledge sharing.
The work we do doesn't lend itself to Agile "stories" so we track to technical tasks
Teams define work not as an end to end story but as a task. Requirements are structured as statements of technical activity for developers, not as user-valued features understood by the customer. Often its easier for technical teams to produce collections of technical tasks and try to pass them off as Agile stories.
Petit concludes: "A shortcut is the longest distance between two points." It seems half-done Agile may be even worse than the monolithic procedure it's aiming to replace.
