Posted by Robert Merrill on March 2, 2010 under Agile BA | 
I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.
Here’s what the whiteboard looked like when we were done. (Click for a full-size view).
Whiteboard after a 3-h presentation about Agile methods by Robert Merrill and Q&A with three Business Analysts
We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.
I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.
This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping. Read more of this article »
Posted by Robert Merrill on November 16, 2009 under Agile BA, Agile Methods |
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.
Posted by Robert Merrill on November 12, 2009 under Agile BA, Agile Methods |
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!
