B(e)A Dev(il)'s Advocate

Please note, there's going to be some wordplay in this post, so try and keep up. If you just asked yourself - "why should I keep up" - it's so you can understand the puns - now keep up, everything will connect in the end (of this post, your life's too long). If you understood the title then you probably know where I'm going with this. Allow me to elaborate further. Let's begin with the term Devil's Advocate:

Being a Business Analyst, a major portion of my day involves enabling a shared understanding between the business and the development team. I know what you're thinking, isn't my job to get the requirements from the client and providing it to the developers to so they can build it? Ahem, no! That's something the developers can do by themselves, they don't need a third wheel in this relationship (if you are one, please continue reading; if you're not, continue reading anyway).

So what does enabling a shared understanding typically mean? Let's begin with shared understanding:

Since we live in an agile (software development) world, let's locate a place for a list of wishful thinking. Yes, it's called a Backlog. Here's another wordplay, if you're a business analyst, your job is to explain backlog items to your development team; if you're a Business Analyst, your job is to align backlog items with your development process (if you understood the difference, you're keeping up). What does alignment mean?

Focus on the second please, you're a Business Analyst, not a Big Automotive, keep up. As a Business Analyst, it's your job to make sure that there is an agreement between business and development team. The needed business items developed when needed is the shared understanding that you thrive on. The idea is to make both the parties aware of each other's position and enable empathy that leads to vibrant results.

So who's the devil? The Dev? Again, focus on the second below:

Anyone involved in the development process is a devil. Then again, anyone involved in the development process is a developer (here's another brainteaser for this topic). As a Business Analyst, it's your job to be the devil's advocate, be that person who's derived & analyzed opinions (note: analyzed) provoke a debate that leads to a conversation and confirmation of business requirements to be developed. That's how you enable a shared understanding and make sure that the value (whatever that is) is optimized.

So what skills do you need?

There are organizations like IIBA that define the minimum capabilities a Business Analyst should have. These being the minimum eligibility, many organizations have their own unique requirements, like domain expertise or Batman. The question you really need to ask is, why restrict yourself anyway? The ultimate goal is to deliver valuable software, so do everything that you're capable of doing in order to optimize that value. Analyse, Code, Test, Own; select your own poison - Be A BA, Be A Devil, and its advocate.