BAs in Transition

I feel like singing an old Bee Gees Song, I Started A Joke (which I can sorta do on my guitar). I wrote a blog about this sudden need for BAs to write Code. Before writing that Blog, I used to think requirements gathering and coding needed a Business Systems Analyst or Systems Analyst to do, and and far as I was concerned, those folks were worth the extra 10-20K a year.

I didn't realize this would raise so much thought in the LinkedIn Agile Alliance Discussion board (the link won't work unless you're a LinkedIn Member and are in the Agile Alliance- which is full of really good and really smart people).

The discussion is great because it raises my visibility (and visibility may = potential job) and good for you who comment (same reason, but you can scratch and bite and kick and scream, but I have to be gentlemanly and kind. It hurts.). It may also elevate the state of the art, which is never bad.

But the drift I'm catching is one that's bugged me for three or four years: What does the BA do in an Agile Project? I think I started to answer that question in a Blog earlier this week titled BAs, in an Agile Project?

And there are two ancillary issue floating around the Agile Ether and I name them here:

• The reason the BA role was created still applies. Even in Agile: translating jargon/goals and managing  expectations by identifying, documenting and testing requirements and business rules.

• There are two BA 'tracks' in IT- the Developer who wants the big bucks and become a Project/Product Manager (not realizing how little your actual hourly rate will be) and the Technical Writer Track- Writers who watched kiddie BAs grab fists of money. We said to ourselves, "I could do that." We read the Use Case Books, learned RUP/UML (artifact? gimme a break, how old do you really think I am?) and then read the XP, RAD and Agile books and talked amongst ourselves. Rhode Island isn't really a road and certainly isn't an Island (say Rhode Island out loud- it's an audio joke).
  

I don't think either BA background is better than the other- the Developer BA is more technically inclined and can handle Objects, Services and Web Applications better than the Tech Writer BAs. But the Tech Writer BAs have better business acumen (dunno why, but I think 'acumen' is a cool word), change management, client-facing and documentation skills. Both can abstract, both can write User Stories/Use Cases and other project documents (but the TW's documents will be more coherent, grammatical and prettier) and both can fill project voids as the SDLC runs its course.

The comments show that some folks have never had a BA on their team. That's a real shame because somebody still has to do all the things a BA does. Which usually means the Project Manager/Scrum Master (that ridiculous title- almost as stupid as my Six Sigma 'Green Belt-' these metaphors are sooooo silly) and or the Lead Developer have to do them. Which means a project is a Sprint rather than a Marathon and something is going to get short shrift. Kinda like my first bullet point? Some shops have come full circle.

I love Michael Duncan's comment that a waitress doesn't have to know how to cook- spot on Michael with a great analogy!

Powered by ScribeFire.