I’m a developer at heart. The steady decline of the Business Analyst (BA) is ostensibly good for me. But I can’t shake the sense that the industry has grossly overreacted in its view towards BAs.
Since the turn of the century, companies have steadily shifted towards Agile development and DevOps and the like, in an attempt to squeeze more work out of fewer people. As we all went over the waterfall (method) there weren’t enough barrels to save everyone. So the BAs were left to fend for themselves.
I’m seeing more and more clients with a hard rule against any software project team structure involving BAs. The logic goes that it’s easier for developers to learn the business than the other way around. Broadly speaking, there’s an inverse relationship between a company’s technical sophistication and it’s willingness to use BAs.
Further, modern methodologies reduce the need for many of the things BAs traditionally brought to the table – comprehensive process mapping, detailed functional requirements, formalized use cases, standalone documentation. Basically anything that involves writing things down. The in-vogue method of communication between the project team and the users has become the code itself in the form of PoCs, incremental delivery, and inline contextual help.
And it has worked. As a whole, development teams are delivering leaps and bounds beyond the antiquated approaches of 20 years ago. But the disdain for the well-intentioned BA has taken root and is choking out any residual or novel value which we may otherwise derive. This developers-only mentality is not always leading to software Nirvana.
While on a project at a top-end financial institution which exclusively recruited talent with elite university pedigrees and/or advanced degrees, I worked adjacent to a project team of about 10 developers led by – you guessed it – the most senior developer. Not a BA in sight. Over many months I watched them generate magnificent, glorious code while floundering and stumbling over basic project functions. Predictably, the tasks which doomed them involved clarifying requirements, functional design, detailed status tracking and generally writing things down. Eventually the project was cancelled and the project lead was let go from the firm. Somehow the “put a small group of brilliant people together and they can solve anything” premise fell flat on its face. The team was too one-dimensional.
So I challenge those of you in the “no BAs allowed” club who may have forgotten why it was formed in the first place:
- What percent of your developers are equipped to interact with your full spectrum of users? Understand the drivers of profit for your company? Would you classify as “detail-oriented”?
- Looking back on your negative BA experiences, was the role truly unnecessary or was the BA just bad at his/her job? Were there technical leaders who weren’t equipped to maximize BA skills?
- Are you modeling your approach based on trendy tech companies when your core business is not technology? Are your internal users and stakeholders as tech-savvy as you might see in these tech companies, to where they speak the same language as developers?
- How much of what you give a developer can be done by a significantly less expensive resource with high aptitude, business domain knowledge, and some IT experience? And would offloading this work make your developers happy?
Perhaps we just need a name change, a rebranding. The remaining business analysts all have some degree of technical expertise. They spend more time aligning business functions to available software rather than the aforementioned traditional hands-off tasks. They would be better labeled as “Systems Analysts”. Since this isn’t the 1970’s, though, let’s stick with “Hybrid”. It’s a nod to the increased technical understanding you get with a good BA these days, and clients have generally taken to it. Now we can get on with finding simple ways to leverage these folks, and you don’t even have to get rid of your “no BAs” rule, to boot!
