Agile Anti-Patterns - Failure Modes in the Implementation of Agile Methods
Articles in this series are about how new-comers to Agile Methods can find themselves not performing as well as expected. The articles are an attempt to classify some of what I have learned since starting on the Agile path eight years ago.
Having been involved in several projects in which the team had recently made the change to Agile Methods, I have had occassion to see several unfortunate, and decidedly non-agile aspects of the implementation.
When the team is eager to do better and has the discipline to change in a controlled way, there is a learning opportunity. Whether the results are of general use or not is another issue; Alistair Cockburn has noted the frequent non-applicability of methodological imperatives taken from one team and imposed on another.
With this in mind, the articles in this series should be taken as advisory or cautionary. Their purpose is to describe what we have observed and what successful, corrective action was taken. Each could be written in the extended Alexander form used by Brown et al in Anti-patterns: Refactoring Software, Architecture and Projects in Crisis ( but I hesitate to give them that formality, so I have presented them in a more anecdotal form.