|Tom Smykowski, Office Space BA|
But let's take another look at this. When we're pragmatic, rather than dogmatic, we tend to find that business analysts are proving to be as vital for agile project teams as they were for the first struggling dev-only teams in the dark days before they invented "waterfall." Let's break this down a little bit.
- Even On Agile Teams, someone still needs to facilitate discussion, record consensus once reached, and analyze the business/technical flow of data. The best business analysts were never the people who doggedly filled out every template to completion--BAs at their best have always facilitated discussions, promoted development ideas to "the business," and urged people to talk directly to each other. Blaming BAs for "Big Upfront Design" is no more appropriate or helpful than deriding developers as pocket-protector wearing individuals with thick glasses who only communicate in binary.
- Time Has Told. Although the Manifesto and Agile Founding Fathers originally thought of all agile team members as developer generalists (or--dare I say it--old fashioned "programmer/analysts"?), time and experience have dis-proven the hypothesis that BAs aren't needed for agile. Modern Analyst quotes Alistair Cockburn in 2009 saying: “the early attempts at Agile development tried to do away with the Business Analyst” because of the potential distortion of communication with a go-between. However, given the complexity of organizations, the disparate business languages that various units may use and the time constraints of subject matter experts, "more recent variations are finding good use for someone with deep business knowledge, who has time to spend talking with the programmers.”
- Corollary: Time Is At A Premium. As Cockburn says, some agile teams may gain benefits from a division of labor whereby business analysts stalk, cage, and interview disparate organizational stakeholders, always time consuming practices, in order to present a coherent set of stories to developers, who can then focus on the actual development. This is not because the developers are not capable of understanding the stakeholders, but because facilitating consensus is a different activity than writing actual code.
- People Have Preferences. As actual agile teams have been born and gone out into the world, it turned out that everyone didn't want to be a developer. Speaking generally, some people wanted to work with people, some people wanted to write algorithms, and some people wanted to develop psychotically completest edge cases to guarantee quality. So although agile teams have often offered everyone the opportunity to do a little bit of everything, gradually the roles of BA, Dev, and QA have emerged as personal expressions of interest by team members. One could argue that things have now gone too far, and people have hardened into their job titles, but so long as teams (or companies) offer people the chance to continue to learn and grow, it isn't necessary to jump to the conclusion that the presence of BAs or QAs on an agile team is caused by HR departments blindly filling out a template somewhere.
So to me, the bottom line in all of this discussion is that the fundamental unit of agile production is the team. The team should combine a number of diverse skills, analytical, communicative, creative, quality-minded, dev/ops, and good-design-informed. As you put together your team, you should make sure that you have all of the skills needed, from some combination of interests, experience, and skills of the team members. People will have a combination of generalist and specialist capabilities, and people should hopefully be emotionally as well as analytically intelligent. But you know what? It's absolutely fine to start by setting up a ratio of one BA, one QA, and two pairs of Devs, and then correct for missing skills.
It is certainly better to do so than to start tinkering with theories like "<my job title here> can be trained to do it all, and the rest of you are monkeys."