BA blog which is worth reading. This week Kimberly published some thoughts on Agile - a reassurance that the BA role is still important, even with the rapid growth of Agile methods for projects.
It stimulated some thoughts of my own.
1. BAs are not required for all types of agile projects.
In fact if the developer team have the skills, why not let them out of the back room onto the shop floor? Why put middleman into the conversation?
How you address requirements management depends on the project, the people and the organsiation. BAs are not always required. (Nor are programmers.)
2. Iterations mean you don't work to a product blueprint.
If you are a BA assigned to an agile project your most likely mistake will be to model an end state (at least in your head) and then work towads that. This is pretty much contrary to the whole iterative approach.
There is a fundamental value in the agile philosophy that says if we design a product today we will probably get it wrong. So don't. (The phrase that is disparagingly used is BRUF.)
In many stable markets - such as governement - this is not true, but in environments where thre is significant shift in business requriements over time, it is very important to understand.
3. You will probably not work on a pure agile project.
The world isn't black and white. And you don't just pick Agile or Waterfall approaches. In the real world you usually mix it up, pulling techniques and tools from a range of methodoloies and frameworks to address the specifics of your project.The approaches us enterprise workers will usually take is a compromise - some of the strengths of agile and some of the strengths of a plan diven approach.
Part of this creation of a hybrid approach is because we think about the situation and design an approach that is appropriate to the cirumstances. Part of it is becasue of a natural conservatism in large organisations. (And I think that at this stage of the Agile methodology maturity we don't know whether this will be a compromise or an enhancement to the agile models.)
And lastly, I think when people talk about Agile as a methodology is smacks of a certain lack of understanding. (Maybe on my part?) Agile is a value set which underpins several (dozen?) methodologies. As a BA, when you talk about Agile I expect you (readers of BetterProjects) to be more specific.