What is a business analyst?
I had absolutely no clue until yesterday. This rather business-y sounding role is a staple at almost every major code company – in some cases, an understaffed staple. So, simply in the interests of knowing what I was getting into, I did a little bit of homework before the event itself.
It turns out a business analyst, by description, analyses business ideas (duh) and watches over their implementation, fine-tuning it to make sure things hit the market well. It’s a fairly new role in Sri Lanka. Apparently, quite a lot of BAs end up slightly outside this description, playing a jack-of-all-trades role and generally being the firewall between the irate customer and the confused dev team.
Either way, the role of the BA is getting more and more obsolete in the face of practices like Agile, which integrate some of what the BA is supposed to be doing into the development cycle itself. Talk about having your feet cut out from under you. Hence today’s convention: it’s to help BAs deal with this.
The evening was kickstarted by Chanaka Usgoda Arachchi, who welcomed the audience ean explained what IIBA is and what they do. The room was almost full – we’ve got maybe eight, seventy people. almost all of them BAs and completely unlike the stiff lawyer-ish types we’d expected, so this went over pretty well.
And voila: le main course: Hasith Yaggahawita of 99x. This is one geek we’ve been seeing over and over at many a tech event, and usually he’s the one doing the speeches, because in addition to being able to nail a speech this guy has a metric ton of experience under his belt.
Hasith dived head-first into the topic at hand. “Have you ever had a bit of anxiety when you hear the words Agile and Scrum?” he asks. “I know it has for me. I used to get worked up over it. In fact, it’s causing a lot of grief for BAs the industry. If you think of the development process as a cake, we tend think Agile and Scrum are the entirety of cake. It’s not. It’s just a part of it. Let me show you why and how.”
Cake-induced diabetes aside, he unrolled a case study, which he called Product Suite X – something sent to 99x by a very reputed European consultant. They had a very attractive business idea, the whole thing was backed by investors, and 99d developed it over a two-year period – ending up with a very high quality product – using Scrum.
“It was beautiful product. Usability tested out pretty well. We thought it would be like the iPhone when it came out.
When we took it to the market, customers struggled with it.
Why?
The problem is, Scrum inherently assumes that you know the problem. Or that somebody does. What happens when nobody does? That was where we failed. My product background was basically a set of assumption. They say no business plan survives contact with the customer: we learned this the hard way.
We learned that the ideas of the customer were based on faith. The customer assumed that we knew the problem. But a development team is stuck inside a building: they’re not out there in the market. Inside the building are only opinions, not facts.
Where does the BA come into all this? A BA has to help the team get out of the building.”
This theme – of getting the team to realize what exactly they’re dealing with there – figured largely throughout the entire presentation. In a later breakdown of the BA’s activities, he illustrated how this applies in reverse when you’re working as a BA in a startup: in that case, the product founder is your client: he/she has a hypothesis in his/her head about how this thing is going to pan out – it’s your job to do the actual analysis and determine whether it’s a good idea or not.
He headed into the nitty-gritty of a BA’s tasks related to each part of the development process. Prototyping (he’s a Powerpoint fan); the MVP (minimal viable product – aha, we’ve always wondered what that meant) and split testing.
“Let’s say I create this product,” he remarked, pulling out heatmaps of sites hr’s worked on in the past. “and somebody comes along and says, ‘This is ugly. It’s not a very user-friendly interface.’
“Now that’s an opinion, not a fact. What you can do is test out that opinion using a split test. Create another version of the product and test these two. If you do it like this you’re no loger doing opinion-based software: you’re now doing fact-based. If you look at companies like Google – the blue color they use has been tested 41 times.”
The evening ended with the panel discussion we’ve come to know, and, er, love. Seriously. This recent fixation on panels is not easily understandable. Nevertheless, this one made ground with the audience. We has Prasath Mahalingam, Chanaka Usgoda Arachchi,Yasith Abeynayaka and Hasith Yaggahawita dishing expert opinion on the state of things as they are.
BAs, the panelists agreed, have mostly been put down to playing the middleman between the client and the devteam: you find BAs learning a little bit of Quality Assurance, maybe solution design, just to survive. Agile is making life harder for the BA by eliminating some of what they’re supposed to be doing.
“The BA role keeps getting tougher,” confessed one member of the audience. “Nowadays when I go to a client they expect me to have very technical knowledge on the level that a dev would know. The technical expectations are much higher now. The boundary between developers and BAs are fading.”
It’s not a negation of the role, but more of the job itself: going over the event, we got the impression that Agile workflows are demanding BAs to change their ways of thinking and adapt to match, to the point where the Agile BA is not a separate entity but part and parcel of the project / team they’re working on. The question is whether both the BA can realize what they’re supposed to contribute and adapt to fit Agile methodology. It’s either that or a future where the team handles the BA role, no questions asked, and you end up sitting on the pavement wondering where your job went.
GIPHY App Key not set. Please check settings