In defense of business analysis
There has been much written about the role of a Business Analyst on agile teams recently.
Some gently question the need for a BA.
Some are outright hostile, calling a BA “an additional monkey that’ll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work”.
I try to keep an open-mind when it comes to debates (I do love a good debate! Probably more than I should). But when I read such articles, try as I might, I come to the same conclusions. Either:
- They have a narrow view of what “agile” is
- They don’t really “get” what a BA does
- Or both.
The Agile Manifesto itself seems to be taking a direct swipe at Business Analysts when it talks about valuing “working software over comprehensive documentation”and “customer collaboration over contract negotiation.” Somehow, Business Analysts have ended up as a proxy for everything bad about the “Waterfall” development method: Big Upfront Design, Big Documentation, Bad Communication, Silos, Cholera, Blunder-headed Filling Out of Templates, the works. Oh, wait, not cholera. But you can see how it would accidentally get into the list–that’s what happens when you start to write things down unnecessarily. Next thing you know, you’re gold plating.