Business analysts: why are there so many of you?

[Fronttoback]

BA is a confidence trick

It's like smoking. Smokers start off enjoying smoking. Pretty soon they smoke just to get back to that feeling of normality, that they experienced before starting smoking. When they have a cigarette they enjoy not the cigarette but the freedom from anxiety caused smoking withdrawal. Once they understand that it's not the cigarette they enjoy but the outcome, they stop smoking and return to pre-smoking bliss with a pocket full of coins.

Before BAs came along we developers used to do the task as part of our job- just a different part of the development lifecycle- so you'd be doing lots of analysis one month and lots of code the next. Everything was going smoothly. Then BAs came along and took the analysis bit under the lie that developers shouldn't be talking to the business. Now, business thinks it relies on BAs. When a BA is not involved they have to rough it and talk to a "blue collar" developer. But soon, they realise the outcome is better. And after a while they realise they don't need BAs anymore. Thus they are returned to a state of calm and they are financially better off too.

This is the trend in my market anyway.

[LondonManc]

It's like smoking. Smokers start off enjoying smoking. Pretty soon they smoke just to get back to that feeling of normality, that they experienced before starting smoking. When they have a cigarette they enjoy not the cigarette but the freedom from anxiety caused smoking withdrawal. Once they understand that it's not the cigarette they enjoy but the outcome, they stop smoking and return to pre-smoking bliss with a pocket full of coins.

Before BAs came along we developers used to do the task as part of our job- just a different part of the development lifecycle- so you'd be doing lots of analysis one month and lots of code the next. Everything was going smoothly. Then BAs came along and took the analysis bit under the lie that developers shouldn't be talking to the business. Now, business thinks it relies on BAs. When a BA is not involved they have to rough it and talk to a "blue collar" developer. But soon, they realise the outcome is better. And after a while they realise they don't need BAs anymore. Thus they are returned to a state of calm and they are financially better off too.

This is the trend in my market anyway.

I used to be a senior business analyst until I went down a more technical route. The BA on my previous project wouldn't have a clue what pareto analysis was or how to facilitate business interviews. Just another resource that they need to assign somewhere, while the project would have been delivered a lot sooner without them.

[SussexSeagull]

It's like smoking. Smokers start off enjoying smoking. Pretty soon they smoke just to get back to that feeling of normality, that they experienced before starting smoking. When they have a cigarette they enjoy not the cigarette but the freedom from anxiety caused smoking withdrawal. Once they understand that it's not the cigarette they enjoy but the outcome, they stop smoking and return to pre-smoking bliss with a pocket full of coins.

Before BAs came along we developers used to do the task as part of our job- just a different part of the development lifecycle- so you'd be doing lots of analysis one month and lots of code the next. Everything was going smoothly. Then BAs came along and took the analysis bit under the lie that developers shouldn't be talking to the business. Now, business thinks it relies on BAs. When a BA is not involved they have to rough it and talk to a "blue collar" developer. But soon, they realise the outcome is better. And after a while they realise they don't need BAs anymore. Thus they are returned to a state of calm and they are financially better off too.

This is the trend in my market anyway.

There is certainly nothing to stop someone being an analyst/developer but some developers shouldn't be put anywhere near the business!

I remember when it more or less went -

Business requested change
BA gathered requirements and specced change
Developer coded change
Tester tested change

Last two repeated until finished. BA was there to answer questions but requirements changing mid project was fairly frowned upon.

Then I suspect the non-technical decided that development wasn't really that difficult and we were all overpaid so PMs became popular to keep us honest.

In the last 10-15 years everyone has decided to be Agile without every really thinking it through. I am sure it does work well in certain environments but in most it is an excuse to not think through requirements to start with and ditch documentation.

A lot of largely extrovert people have made a lot of money with job titles that end in Manager not improving speed of delivery in the last 25 years while introverts do most of the actual delivery (sweeping generalisation).

[LondonManc]

There is certainly nothing to stop someone being an analyst/developer but some developers shouldn't be put anywhere near the business!

I remember when it more or less went -

Business requested change
BA gathered requirements and specced change
Developer coded change
Tester tested change

Last two repeated until finished. BA was there to answer questions but requirements changing mid project was fairly frowned upon.

Then I suspect the non-technical decided that development wasn't really that difficult and we were all overpaid so PMs became popular to keep us honest.

In the last 10-15 years everyone has decided to be Agile without every really thinking it through. I am sure it does work well in certain environments but in most it is an excuse to not think through requirements to start with and ditch documentation.

A lot of largely extrovert people have made a lot of money with job titles that end in Manager not improving speed of delivery in the last 25 years while introverts do most of the actual delivery (sweeping generalisation).

You missed the key bit of BA working with Tester to confirm correct tests were being executed, but yes, that's been a fairly successful model.

Agile works well in web development, no question about it. I've seen some very good stuff delivered. The problem with Agile evangelists is that they are like Sith; there can be no Waterfall project that is done correctly.

[Lance]

@contract recently advertised for 2 BA's, 8 Java developers and 2 testers, all contract. This the number of applicants:

103 BA's
34 Java devs
70 testers

this suggests that roles without a requirement for specialist knowledge attract more applicants.
Without being offensive to BAs and testers it's probably because those roles are far easier to 'wing it' when you don't have a scooby. PMs are pretty much the same and anything in service management.

[Lance]

It's like smoking. Smokers start off enjoying smoking. Pretty soon they smoke just to get back to that feeling of normality, that they experienced before starting smoking. When they have a cigarette they enjoy not the cigarette but the freedom from anxiety caused smoking withdrawal. Once they understand that it's not the cigarette they enjoy but the outcome, they stop smoking and return to pre-smoking bliss with a pocket full of coins.

Before BAs came along we developers used to do the task as part of our job- just a different part of the development lifecycle- so you'd be doing lots of analysis one month and lots of code the next. Everything was going smoothly. Then BAs came along and took the analysis bit under the lie that developers shouldn't be talking to the business. Now, business thinks it relies on BAs. When a BA is not involved they have to rough it and talk to a "blue collar" developer. But soon, they realise the outcome is better. And after a while they realise they don't need BAs anymore. Thus they are returned to a state of calm and they are financially better off too.

This is the trend in my market anyway.

I almost completely agree except that some developers shouldn't be allowed near users.
That is when a good BA is really useful. Unfortunately good BAs seem quite thin on the ground.
I end up doing a BA role after they've left the building. The business get what they want and I'll talk to developers and translate for them.

[VillageContractor]

There is certainly nothing to stop someone being an analyst/developer but some developers shouldn't be put anywhere near the business!

I remember when it more or less went -

Business requested change
BA gathered requirements and specced change
Developer coded change
Tester tested change

Last two repeated until finished. BA was there to answer questions but requirements changing mid project was fairly frowned upon.

Then I suspect the non-technical decided that development wasn't really that difficult and we were all overpaid so PMs became popular to keep us honest.

In the last 10-15 years everyone has decided to be Agile without every really thinking it through. I am sure it does work well in certain environments but in most it is an excuse to not think through requirements to start with and ditch documentation.

A lot of largely extrovert people have made a lot of money with job titles that end in Manager not improving speed of delivery in the last 25 years while introverts do most of the actual delivery (sweeping generalisation).

What you'll find is that anyone not doing documentation or giving proper requirements is not doing agile. People attempt to implement agile within any experience and then end up doing the poor mans version. Agile works in most situations if done properly. There are lots of reasons and companies who don't do it properly. Don't blame agile, blame the company for doing it wrong.

Don't make a judgement on agile based on how companies have implemented it poorly.

[LondonManc]

I almost completely agree except that some developers shouldn't be allowed near users.
That is when a good BA is really useful. Unfortunately good BAs seem quite thin on the ground.
I end up doing a BA role after they've left the building. The business get what they want and I'll talk to developers and translate for them.

Agreed. I've seen DBAs ushered away from end users before now

[SussexSeagull]

What you'll find is that anyone not doing documentation or giving proper requirements is not doing agile. People attempt to implement agile within any experience and then end up doing the poor mans version. Agile works in most situations if done properly. There are lots of reasons and companies who don't do it properly. Don't blame agile, blame the company for doing it wrong.

Don't make a judgement on agile based on how companies have implemented it poorly.

I agree it works well in some environments and projects but people try to force it onto projects that it shouldn't be near. For example I don't see the point of using it when implementing regulatory changes that aren't going to change.

[Cirrus]

Some BAs are really useful. Others are less than worthless.

My most recent two projects were crippled by the useless BA. Unfortunately this person was a favourite of the Portfolio Manager (or 'Essex Girl' as I called her). So I couldn't get him off. It was only excellent developers in South Africa, and a very good 'Solutions Architect' (there's a prime candidate for another discussion) that allowed the projects to proceed at all

The big problem with the BA - and this is often the case - is he didn't know much about the business and didn't do much analysis.

What he did do was have lots of discussions about solutions and software development management. Since he knew little about either I eventually threw in the towel and waived bye bye.

It was 'interesting' to see the reaction of my replacement (nice enough chap) when he first saw one of the BA's Requirements Documents.