In response to: Plato's Revenge: The Business Analyst is the Tester!:
Its interesting that the CIO article that Plato's Revenge refers to mentions "Agile" practices and states "even if they don't know what they are".
I think that the point Plato's Revenge hits on well and seems a consistent theme across the IT solutions delivery spectrum is breaking down the barrier between the business stakeholders and the technical delivery team.
Traditionally the BA is a big part of this interface and as described, the value of experience in both camps cannot be underestimated as it can be such a lynch pin role in the success or failure of a project.
In theory a well implemented Agile process for solutions delivery should help to bring down these barriers as well in a variety of ways.
One aspect of agile development that is worth examining in relation to Plato's Revenge's post is the concept of 'test driven development'. This feature of agile ties in very well with the idea of a BA being involved in the testing of a project.
The concept being that in order to write a piece of functionality properly a developer first needs to understand the requirements well enough to know how that functionality will be tested - thus by writing (or attempting to write) the tests first, prior to developing the code, it is quite likely that potential inconsistencies in the requirements or miscommunication or misunderstanding of requirements will be identified and resolved earlier in the exercise.
Adhering to the test-driven development methodology effectively forces the technical team to think about the end stakeholder goals very early in the process.
Having the tests written before hand then provides a benchmark that will help to prevent the technical team getting carried away with over-architecting a solution to the extent that they lose sight of the original requirements and goals of the project.
There are numerous other ways a properly implemented Agile methodology can help to increase communication and feedback between the delivery team and the business takeholders.
This includes shorter and more regular delivery/feedback cycles, requirements management mechanisms which explicitly cater for adjusting to changing understanding of business processes and various other features about the way teams and communication are structured that if implemented properly can achieve signficant benefits.
The business stakeholders are a key part of making the process work, so if the business stakeholders are not participating in, understanding or seeing those benefits then the Agile process is not being implemented properly and the disconnect still remains.
Because the Business Analyst plays a key role as an interface between the technical team and the business stakeholders, a BA with a good grasp of the ideas and objectives behind Agile methodolgy can play a key role in facilitating an effective implementation of this methodology.