This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
sidebar ~ agile business analysts
there seems to be an ebb and flow for this sort of thing. recently i read a discussion on the idea of a technical business analyst and how the business analyst role is evolving in project management. there was an argument that business analysts [ba’s] are like wait staff. wait staff ask the customer what they would like and submit an order. they are never asked to go into the kitchen and cook. so why should a business analyst get into the pit and code?
if we continue with the metaphor above, customers are constrained to those items on the menu as well as the types of substitutions they may request of the kitchen staff. a good, or well trained, wait person will know these nuances very well and coach the customer to meet these constraints. if the waiter is unsure, they might ask if a request is appropriate before committing to the customer. otherwise, they will have to tell the customer that they have made a mistake committing to their request, or that there is a slight up-charge for doing so, or it may take a little longer to prepare. the story could continue, but i think this is a probable scenario.
my first question is, is this an appropriate comparison? does it hold water? in general i say no, but if we expect as much from an agile business analyst then it could be. based on my experience, there is usually a highly adversarial and dogmatic approach in favor of the customer by ba’s in an agile software development environment. this may not be acceptable or typical, so i admit to a potential bias.
ultimately and imho, absent specialized skill sets (which is the direction of the industry in general), distribution of effort is delegated to the other people actually doing the work. for instance: in an agile development organization where ba’s are limited, the responsibility is delegated to other members of the project delivery team, be it the pm, dev, qa members, etc. is it as high-quality as what a ba might produce? maybe, maybe not. but we know that the division of work is distributed, as developers are asked to have business acumen, qa is asked to do some development, etc. expertise is expensive, and very few are worth it despite the skill being sought.
so another question would be, what makes the ba a specialization that should be maintained in the field?
ba’s work for both sides in an agile context. the walls are crumbling between business and technology. ‘us and them’ is becoming ‘we’. i don’t think it helps to compare ba’s to wait staff. let’s change context for a moment. in most automotive service departments you’re not likely to find specialized technicians (tranny, engine, electrical), but technicians will have varying degrees of proficiency in each. your vehicle will go to a single technician or team of technicians to complete as much of the work as they can. rarely does a service call require an overnight stay any more, because the engine guy is backed up by a team of generalists. now an argument could be made that the service advisor is a better analogy to the ba. i argue that when the problem is complex, the customer suffers from an ‘expert’ translation. a good advisor offers tons of communication about where the work is and when the customer can expect to be done. they may also advise on trade-offs so the customer can decide to only do what needs to be done now and return later for the rest.
what are your thoughts on the matter? should ba’s be more integrated and more technical? to what extent? how can the customer benefit from a more agile business analyst?