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.
I got the idea for How to Sabotage Agile from a weather safety talk I once heard called “How to Get Hit By Lightning.” It’s more memorable and fun to read about what not to do.
- Tell the sysadmins, tech support folks, and in-house counsel that Agile means developers will be pushing code to production anytime they feel like it.
- Quote (or make up) inflammatory statements from famous Agilistas. “Sure, BAs, PMs, and QA people have a role on Agile teams–somebody has to make the coffee!”
- Tell the most introverted, opinionated developer in your shop that Agile will mean they will have to go out and gather all of the requirements themselves, with no help.
- Tell the most technophobic, opinionated business person in your firm that Agile will mean they will now have to talk to programmers, daily.
You’re in the middle. Don’t leave this to chance, do them all! See also How to Sabotage Agile, Part I and How to Sabotage Agile, Part III!
(This is from The BA Role in an Agile Environment, presented on 9/15/2009 at the Madison chapter of the IIBA).
The most effective weather safety talk I ever heard was called “How To Get Hit by Lightning.” By telling us what to do if we wanted to get killed, it communicated what to do if we wanted to stay safe, only in a far more engaging way.
So, in that spirit, How to Sabotage Agile.
- Encourage compromise of one or more of the load-bearing walls of Agile. When someone warns against this, say, “I’m just being pragmatic here. I want us to go Agile more than anybody, but we’ll never get it in the door if we’re zealots—don’t worry, we’ll tighten this up later.” Read more of this article »
I gave a talk by this title at the September meeting of the Madison IIBA. I promised to put some of the materials up as blog posts. Like most estimates, “when” was overly optimistic.
Here it is mid-November, and I’m just getting to it. As I did at the talk, I want to write about what you want to hear about. So here’s the list of topics—the product backlog—as I’m currently planning to write about them.
If you’re a Madison IIBA person and you’d like to see the order changed, register and comment (or email me) and I’ll change the sequence. (I won’t sell your name).
- I like my Waterfall and BRUF. How do I sabotage Agile in my shop?
- What skills does a BA need in an Agile environment?
- Tell me more about Facilitated Requirements Workshops.
- Tell me more about User Stories.
- How do Agile shops manage a project portfolio?
- How do Agile teams do QA?
- Tell me more about Test Cases and TDD/BDD.
- How do Agile shops handle documentation?
- What are the principles behind all Agile methods?
- Why should we use an Agile method?
- Why do Agile methods work?
- Which Agile method should we use?
- How can we tailor Agile to our environment?
- What happens to the specialists (DBAs, UI/UE specialists, architects, etc.)