Mike tells us:
Although there are many ways to sabotage your agile project, for convenience we have grouped them into four categories: management issues, team issues, product owner issues, and process issues. In each instance, we will cite an example of someone who successfully caused agile failure, list the general guidelines for failure that the example is meant to demonstrate, and then list alternative techniques you can try to help you replicate the process. We hope this approach will allow you to fail quickly and avoid potential success.
Wow! I wonder if it is as easy as Mike would have you believe? Failure may actually be easier than success with over 20 ways to do it. Such diversity!
Here's a few of the better ones:
Bookmark this on Delicious
- GUIDELINE 3: Equate self-managing with self-leading and provide no direction to the team whatsoever
- GUIDELINE 8: Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on
- GUIDELINE 9: Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.
- GUIDELINE 12: Replace a plan document with a plan “in your head” that only you know.
- GUIDELINE 16: Slavishly follow agile practices without understanding their underlying principles.
- GUIDELINE 20: Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.