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.
Good article, Jon! I’ve definitely seen people struggle with “identity issues” when trying to incorporate requirements/analysis as part of an agile project. The approach you suggest – think of the tasks, not the title – is a good one. A product manager / analyst can also work well as the “product owner” for prioritizing the backlog.
As you point out – it is sharing responsibilities across members of the team. Good article!
In general, I don’t expect the BA role to go away. I think the assumption that it can be removed on an Agile project comes from a failure to understand how the role came to be in the first place!
The biggest disconnect that I see between the Agile and business communities–and it’s growing, not shrinking–is that Agilists think software is important and interesting, and the business people should make it a priority. The business people, on the other hand, are increasingly coming to view it as a commodity. That’s an oversimplification, of course–there are companies that gain a real competitive advantage from software–but the vast majority of businesses see software as something that’s secondary to getting on with their real jobs.
I’ve worked on an Agile team, and one of the big lessons I learned from it is that Agile development requires a significant set of pre-conditions that very frequently don’t exist in businesses. You need to have a clearly defined and understood objective that all stakeholders are willing to put at the top of their personal priorities. You need to have substantial agreement about what the problem is and what you’re expected to achieve.
I think there is a set of problems which Agile development is very good at solving. I also think most of the advocates of it work in situations where they mostly encounter that kind of problem. However, most business problems fall outside of that set.
In terms of the BABOK–we’ve been taking the approach you mention above for the last year. We’re working to define the role, not the job.
One last point–Enterprise Analysis doesn’t mean “not software”. Enterprise Analysis is about defining the problem you’re trying to solve (what are the business goals and objectives, what is the context in which the solution will be implemented, what is the business case for making this change). Requirements Analysis is defining the solution, which may include process changes, organizational changes, policy definitions, and yes, software.
Thanks for the comments, gentlemen. This is a discussion that I’ve been observing for a while, and am (of course) very interested in how things play out.
Kevin – I appreciate clarification on the enterprise analysis bit.
What I was trying to express is that enterprise analysis is all-encompassing, not to imply that it concentrates on the “not-software” stuff. In re-reading my post, though, I see how my placement of that sentence could make it come off that way.
The main ‘solution’ that requires business analysis but not new software is acquiring and implementing software packages; and packages are getting a whole lot easier to use, being highly configurable, process and rule-driven, and more. If you work at a company that does not sell software (my experience is insurance and financial, mainly) then the number of packages your company uses will far out-number in-house developed systems. As a working BA, I can count on one hand the number of in-house systems I have done work for; the number of packages would be counted in dozens.
So, if one can succesfully deliver better software faster using Agile, with or without a BA, power to you. Meanwhile, I have tons of other projects to keep me busy.