I’ve come to understand that there are more configurations of business analysis in a software development environment than I had thought. Unfortunately for a recent project I managed I found this out the hard way, but I think I have gained some insights that will help avert disaster in the future.
I’ve worked with many business analysts, even been one myself for a while, and never understood until recently how much of an effect an analyst’s background can – or at least should - have on a project’s organization.
In waterfall development I found that business analysts with a technical background were often more difficult to work with than those coming from a business background. They seemed to focus more on the ‘how’ and less on the ‘why’, with predictable battles ensuing. Some analysts with a technical background actually made the jump but more tended to fall back on technical details to round out a functional specification, turning the specification into something less functional and leaving the engineers in the dark as to what we were trying to accomplish. On the other hand, there was always the danger of non-technical business analysts not knowing what kind of information would be important in a functional specification; however, in a waterfall model there is enough review time to ask questions and revise (and revise…and revise…) Once I started working in a…hmm, how to say this…I guess ‘traditional’ agile environment, I found that either flavor of business analyst worked well. Because the engineers and analysts were in close physical proximity there was give and take in the functional specifications that could basically work itself out between the two constituencies in the general flow of an iteration. The agile user story structure helps provide a framework so that the user business and need is understood, while the quick turnaround and small bite mentality makes it easier for technical business analysts to provide the right level of information.
I started getting into trouble working in a distributed Agile environment. Although I had been doing this for several years there was a definite difference in the background and makeup of a new team I had, particularly the analysts, from prior projects. To add to the general difficulty none of the business analysts (who were decidedly not technical) had worked on an Agile project before. The business analysts were in the U.S. and the engineers and quality engineers were in Europe. The business analysts had a great deal of trouble breaking functionality into the right size chunks for consumption in an agile process and their functional specifications typically lacked both an adequate explanation of the business need and coherent detail about what needed to be implemented for that user story only. Because they were working an iteration ahead of the implementation we ended up getting bogged down trying to interpret the functional specifications during the implementation iteration and the whole thing just went to, um, heck.
What finally worked was to pair each business analyst with an engineer. Most of the engineers were actually not on this project, but they were co-located with the business analysts and could give instant advice on whether a functional specification was understandable from an implementation perspective. A few were paired with remote engineers, which worked well as long as the time differences could be worked out (everyone needed to be proficient in IM…and I think desktop video conferencing would work even better). So…bottom line…if the development methodology is agile, the business analysts are non-technical, and the engineers are at a remote location it’s important to pair each business analyst with an engineer for quick turnaround on questions and reviews.
As a side note, for those business analysts with a technical background, pairing with a project manager or a product manager helped in a similar manner.