I’m rocking this BA gig!
Some time in the past: So I’ve been a BA for a couple of years now, I’ve got my head around all the different types of specifications we write for different types of features. We’re talking documents where the basic template (with no information filled in) runs to 15-20 pages. I’ve learnt to add every piece of information possibly relevant into the document, because otherwise, the developers and testers will tear it apart at the walk-through. So in other words, I’m doing a stellar job as a BA and I have been encouraged and rewarded for this at suitable moments by the company I work for.
Side note: Yeah I can say with hindsight (20/20, yo!) that what was adjudged a stellar job for a BA in that workplace is so far away to the standard I have in mind today. And it makes me weep when I see BAs doing all those things I used to, when I didn’t know any better.
We’re going to be adopting “Agile”
Picture this: The room is full of staff that have ‘gathered around’ on the development floor. An announcement is imminent if not highly anticipated – we’re going to be restructuring development (yes, again). And yes, the anticipated restructure is indeed happening, but this time, there is a new flavour in the mix, and it’s called AGILE.
Everyone rushes back to their desks and starts searching. I’d say googling, but this was a while ago, we could have been Yahoo!ing for all I recall. The overwhelming result seems to be one exemplified by the classic Dilbert strip.
Obviously, management had decided that we were no longer panicking enough when restructures were announced, and they had to really up their game.
Actually, you don’t fit in
Okay, confession time: I love change. I embrace change heartily, and even my self-involved narcissist had realised that restructure after restructure meant that management was trying to fix a problem, even if I didn’t know what the problem was. So of course I was jumping up and down in glee, and delighting in the information that we’d be learning lots of new stuff and trying new processes. Then I made the mistake of trying to figure out how I could be a kick-ass BA in the Agile world. Boy, was I in for a shock.
Apparently, there was no such thing as a BA in Agile or SCRUM.
There was article after article in the Agile realm that made it clear that the BA role was overrated, and would be shared by Product Owners and developers in the new Agile world. No documentation was needed, the team shared all the analysis tasks and no detailed upfront analysis was even required before starting stories.
Well, I guess I was stuffed! I was the youngest and most inexperienced BA in the team – no where near PO material. And as for being developer material…. (unending chorus of laughter).
Suffice to say, a couple of days of reading over the weekend left me neither enthused about the change, nor particularly clear about what the changes would actually mean, and suddenly I was wondering if change was always something to be excited about.
It all worked out in the end. I made the transition, and I am LOVING the Agile/ SCRUM frameworks. I wrote a bit about the difference in the roles here: http://agileaustraliablog.com/2015/07/10/what-an-agile-ba-must-do-differently-to-succeed-with-guest-blogger-tasneem-gould/