I’ve noticed a recurring discussion around various business analysis-oriented websites of late concerning the relevance and value of the Business Analyst, especially in an agile environment. Some argue that with agile, “business analyst” responsibilities are carried out by software developers or technical architects, eliminating unneeded layers of communication (read; BA’s).
Karl Wiegers, one of my favorite reads on software methodology, addresses the topic briefly here.
One of the points he makes, and with which I agree is that we can “[t]hink of the analyst function as being a project role, not necessarily a job title. This role can be performed by various people on the project who have the skills, knowledge and temperament for it.”
That’s where I think the IIBA may find peace with certain agile evangelists (see the comments section – link requires registration). Depending on the environment, developers could certainly be called on to carry out some of the software related “business analyst” responsibilities. I don’t think that marginalizes the broader role of the Business Analyst, though. “Who does what” in a company is governed by any number of factors, including budget, headcount, and the available skill sets among the company’s pool of employees, to name just a few.
Wiegers goes on to warn that some developers may not be comfortable wearing the “analyst hat.” I can relate – in reverse fashion. A number of years ago as a new consulting analyst I was staffed on a project as a software developer. I like to think I did a fairly decent job, given my lack of experience and training, but I won’t even pretend that my performance would have matched someone with training, experience, and who enjoyed software development. Additionally, while I was willing to fill the role, I didn’t (and don’t) particularly enjoy coding software.
To that I’d add that even if the developer is great at analysis, sometimes business solutions just won’t involve software development. Who does the analysis for those projects? From my humble vantage point, business analysis is not at all limited to requirements for software development solutions. If a Business Analyst’s role is to identify stakeholder need, and then help identify the best solutions to meet those needs, then it seems perfectly reasonable that some solutions will not involve software development at all. This is where what the IIBA refers to as “enterprise analysis” comes into play.
Some solutions may involve tweaking business processes through personnel (staffing) changes, changes in sales or marketing approach, or myriad other ways that may not even require the first line of code. In these situations, I’m not sure how interested software developers are going to be in fulfilling the responsibilities of the business analyst.
For me, the bottom line is that there is a place for enterprise business analysis, and a place for software requirements analysis. Often, those roles will be filled by a business analyst, but they don’t have to be. Different methodologies work better in different environments. In some shops, agile is the way to go. In others, it’s a waterfall or some derivative of the waterfall method that makes the most sense. While the titles of who performs the work may differ, business analysis skills are critical in any methodology.
Kommentare