Do we need Business Analysts?
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
Absolutely agree with all of the comments. I found that BA's actually make things worse because they do not understand enough about the coding end to prevent business users from creating a mess. Realistically, a total waste that creates even more work. 'BA' = Business Agent because there is never any true 'analysis' being done, simply a pass-through person or go-between.
-
An enterprise role is like a tool : if it is not used properly, it is useless, and can even be dangerous. I would not generalize about businees analysts not being useful.
I agree, the OP's generalization is wrong, but not for the apparent reason -- the developers are being used wrongly, not necessarily the BA. IME, developers should have an understanding of what they are building, how it should work, and how it will be used. When managing a project, I have developers sit in on some of the requirements and design sessions, so they get first hand experience with the situation. This produces better results. The BAs and TAs have the lead in those sessions, but everyone participates. BITD, we weren't developers, we were Programmer/Analysts, and we had Business and Technical Analysts. The roles were not as stratified and IMO worked better. One project where we had clearly defined Programmers and Analysts did not go well, too much miscommunication and lost effort.
-
Absolutely agree with all of the comments. I found that BA's actually make things worse because they do not understand enough about the coding end to prevent business users from creating a mess. Realistically, a total waste that creates even more work. 'BA' = Business Agent because there is never any true 'analysis' being done, simply a pass-through person or go-between.
Member 14840496 wrote:
Realistically, a total waste that creates even more work. 'BA' = Business Agent because there is never any true 'analysis' being done, simply a pass-through person or go-between.
Yep! That's where we are at. I've seen comments from developers, on here, saying that it saves them time. But I prefer to spend time, fully understanding the problem by talking with the person who has the problem - rather than spending my time coding something that the BA (a) didn't fully understand and (b) didn't properly communicate the bits that they did understand. Chinese whispers comes to mind!
-
I'm not sure that you work on problems quite as complicated as I do. I work about 10 hours a day. Frankly, I need all the help I can get. I need the help of DBAs that know the connections and flow between the ... 20 or so databases that my system interacts with. There are literally thousands of sprocs. I have no idea what is in most of them. It's the same way with BAs. I've had useless business analysts and I've had ones that made my job a joy. Dealing with customers can be time consuming and problematic. If someone can offload that task, that's great.
Michael Breeden wrote:
I'm not sure that you work on problems quite as complicated as I do.
Over 50 front-end web applications, (some with their own databases), all interacting with our legacy system, which consist of over 1000 tables and 10,000 pieces of software. I wouldn't call it simple. Note. I use the term 'legacy' to describe it's long standing value - not as a derogatory term commonly used in IT these days.
-
SteveH wrote:
Having someone who neither understands the business nor the technology as the 'go between'
That sounds like your main problem. If the BA lacks domain experience, they need to be good at gathering requirements from those who have it, in which case they can offload this task from developers. But if they try to do it alone, or if those who know the domain don't give them the time of day, it'll be like you say. For most of my career, I worked in more or less a waterfall model where the first thing to be written was the requirements document. Sometimes it was written by a BA type. Other times it was written by the developer, especially if it was an internal capability or could reference a standard and outline the subset of it that would be implemented.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Back in the day, we wrote up the requirements doc as a team of users (engineers), developers (we just called them programmers), a liaison (programmer who was also an engineer - me), and managers (BAs maybe?). We'd work until everyone understood the requirements and signed off on it, then it was just a SMOP, but everyone was clear on what they were producing and how it fit into the whole. This, I believe, is what is now known as the Waterfall model. BAs can be useful in keeping everything on track by keeping the big picture in mind and avoiding bunny trails that crop up when users and coders start to get excited :laugh:
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
I believe the BA's do serve an important part of the business, but like someone else mentioned on here, they need to have domain experience or working to gain that experience. Ideally, as software engineers, we are all very, very busy (thankfully!). When the business wins a new customer or an enhancement for an existing customer, the BA's come in to clarify the customer's needs from a "business" perspective. Meanwhile, us software engineers are working diligently to keep up with the work we already have so it's nice that we have the BA's out there getting our future work ready. When the new work is defined enough from a business standpoint the engineers can be brought in to start figuring out the technical details to satisfy the business requirements. The BA's are consulted about requirements as the tech team comes up with a plan. As the project moves forward the BA's will start to focus on other needs since they won't be consulted as much as they were in the early stages. I don't know what company your with, but I'll bet you are just seeing growing pains since the BA role is new to the company. The BA's are probably still learning the domain so they aren't as effective as they will be in the future. Hang tight if you like the company. The BA's should make your life better once they get some runway.
-
Back in the day, we wrote up the requirements doc as a team of users (engineers), developers (we just called them programmers), a liaison (programmer who was also an engineer - me), and managers (BAs maybe?). We'd work until everyone understood the requirements and signed off on it, then it was just a SMOP, but everyone was clear on what they were producing and how it fit into the whole. This, I believe, is what is now known as the Waterfall model. BAs can be useful in keeping everything on track by keeping the big picture in mind and avoiding bunny trails that crop up when users and coders start to get excited :laugh:
It was something of a red herring for me to call it a waterfall model, because there isn't much point in designing or coding until the requirements are reasonably firm. After that document was written, a meeting was held to review it before development began. Yes, limiting the interaction between users and coders is important once development begins! SMOP = simple matter of programming? :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
While BA's can be useful, they should be used appropriately as an adjunct help to the developers. I wrote this about 1-1/2 years ago, and still believe this is true - from years of experience, having done it, and having seen it in action. The trick is finding the experienced engineers capable of project management and technology management with sufficient people and business skills. There are those out there who can, and within that population, those who will. I have seen on several occasions how non-technical management makes a mess out of technical projects. Some just take longer, cost more, and result in mediocrity at best; some were complete failures. Soup to Nuts[^] As for Agile... Agile Principles from a Traditional American View/[^] Rethinking the Software Development Life Cycle (SDLC)[^]
-
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
The (flawed) business reasoning behind the proliferation of PM's and BAs is that because they work for less money, overall cost can be lowered for development by using less (and more expensive) software developer/engineer positions. The (again, flawed) thinking is that these non-technical PMs and BAs are offloading on a one-for-one person-hour the PM/BA type work from the developer. Of course, this (flawed) thinking comes from the business types who have no clue how software engineering actually works.
-
In my opinion, it works best when you don't have business analysts, project managers, or even programmers / coders. Managing projects and analyzing the business needs is the responsibility of software engineers. You get better end results when the people writing the code are deeply involved in understanding the business needs.
-
While BA's can be useful, they should be used appropriately as an adjunct help to the developers. I wrote this about 1-1/2 years ago, and still believe this is true - from years of experience, having done it, and having seen it in action. The trick is finding the experienced engineers capable of project management and technology management with sufficient people and business skills. There are those out there who can, and within that population, those who will. I have seen on several occasions how non-technical management makes a mess out of technical projects. Some just take longer, cost more, and result in mediocrity at best; some were complete failures. Soup to Nuts[^] As for Agile... Agile Principles from a Traditional American View/[^] Rethinking the Software Development Life Cycle (SDLC)[^]
-
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
-
It was something of a red herring for me to call it a waterfall model, because there isn't much point in designing or coding until the requirements are reasonably firm. After that document was written, a meeting was held to review it before development began. Yes, limiting the interaction between users and coders is important once development begins! SMOP = simple matter of programming? :)
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I have to agree with you. I've never worked with a BA who was worth their salary, but I'm sure there are some out there. My Agile story is when "we're going to try Agile on this project!". Then everyone except the technical people go away, and come back six weeks later with a 60+ page requirements document written by the BA. Sigh. No, that's the opposite of Agile. Of course, the document was so poorly considered, we had to do agile-like cycles of development/review/etc anyway. Only six weeks later.
The two times I recall being handed a spec I threw it out and wrote something better.
-
The (flawed) business reasoning behind the proliferation of PM's and BAs is that because they work for less money, overall cost can be lowered for development by using less (and more expensive) software developer/engineer positions. The (again, flawed) thinking is that these non-technical PMs and BAs are offloading on a one-for-one person-hour the PM/BA type work from the developer. Of course, this (flawed) thinking comes from the business types who have no clue how software engineering actually works.
Interesting, I hadn't thought of it that way -- the average salary decreases by hiring more resources.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
This goes back to the 90's. "My" BA would tell me what he got from the user; then he would ask me to explain it back to him. I quit that company for lack of a bigger picture. BA's, in effect, think and act like you work for them.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Thank you. That is kind.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
In my opinion, it works best when you don't have business analysts, project managers, or even programmers / coders. Managing projects and analyzing the business needs is the responsibility of software engineers. You get better end results when the people writing the code are deeply involved in understanding the business needs.
-
IMHO: No At my previous company, we didn't have BAs - and when I joined my current company we didn't have them either. But that changed, a few years back, when a new head of IT came in and decided he needed to replicate the structure from his old place. We now have dozens of BAs and are constantly recruiting more. What this has achieved over the last 5 years, is: - Software Developers being down-graded to coders. To be honest, some are not troubled by this. They're also not troubled by sitting, on their own, in their bedroom for a whole weekend, playing computer games! ;) - A layer of obfuscation. Having someone who neither understands the business nor the technology as the 'go between', inevitably results in Coders not developing what the business actually needs. - Lack of ownership. Coders no longer feel responsible for working with the business to understand how a requirement can best be developed and delivered. - A disconnect. Where we once had software developers working directly with business users to solve a problem, we now have the person who truly understands the problem, not talking to the person who can solve it. What's even more puzzling is that we are trying to be Agile! I've never been convinced that Agile is better than other approaches - but I don't see where BAs fit in!
Hard no. Allocating resources to BA's is a mistake. They do not add value for the end user and they increase the technical cost, while reducing the individual ownership for everyone involved. I've seen enterprises run successfully with and without BA's, and without them there is less churn, more individual responsibility and less sunken costs in reports and metrics for internal use only. They do not add value and they do not contribute to getting the work done, so why waste the resources. Hire more support and customer training positions instead for a much better ROI.
