How to Sabotage Agile, Part III

Posted by Robert Merrill on November 16, 2009 under Agile BA, Agile Methods | Be the First to Comment

This is the third of three parts on how to sabotage Agile adoption in your company, especially for Business Analysts.

If you want Agile to succeed, don’t do this stuff.

If you want Agile to fail because you’re benefitting from the status quo, good luck with that, too. Just make sure you have each item covered, especially the last one.

• Find like-minded saboteurs at other companies, so you can say, “They tried Agile at BigCo, and it was a disaster!”
• When assigned to an Agile project as Business Analyst (BA) or Product Owner, insist that all communication from business people to developers go through you, “To keep a handle on scope and keep things consistent.”
• As BA, insist that developers ask you all business questions first, because, “You know the business better than they do, and they’re all really busy anyway.”
• As BA, if instructed to coach people on User Stories or Test Cases, call in sick. Or just do it badly (but don’t be too obvious about it). On break, tell the most frustrated-looking person, “The only reason we’re doing this Agile stuff is that the CEO read about it in an in-flight magazine.”
• Hope that your firm’s competitors have people like you in them. When the ship you’re on sinks, proving that the leak wasn’t in your end won’t keep you from getting wet.

In case you missed them, here’s
How to Sabotage Agile, Part I and How to Sabotage Agile, Part II.