Agile Business Analysis is an evolutionary and collaborative process where analysts, developers, customers and end users work together to understand the business domain, to identify what is needed, to prioritize the functionality and to deliver products of the right quality and value to the business. The Agile Business Analyst is a full member of the cross-functional team, working alongside business and development skills to evolve the right products.
You may be wondering, as a business analyst, if that means that the developers will talk directly to the users. Well, yes it does. The business analyst must not become another "hand-off" or block to the information flow. Does that mean that your job has disappeared? Certainly not! Some early Agile approaches laid much emphasis on the developers in the team becoming "generalising specialists", who could fathom everything from the business strategic level to the bits and bytes of machine language. Development teams in these approaches had access to a business representative, a "Product Owner", who proposed, refined and prioritised the requirements, but also needed a broad spectrum of knowledge and authority from project-level budgetary control to in-depth end-user knowledge. These approaches were absolutely correct in one thing - that several small teams work better than one large one, organised as a production-line with multiple hand-offs between the roles. However, a misconception of early approaches was to confuse roles with people. Although it can be shown that it is better to have fewer people involved with a product, to reduce the number of hand offs (business - analyst, analyst - designer, designer - developer, developer - tester and so on) the skills of each of these roles are still needed. Time has shown that missing out the business analysis skills is costly. The business representative may be able to look at the "As Is" and "To Be" situations from their own perspective, but often lacks the modelling skills to look at the "big picture". The Agile Business Analyst can use soft systems approaches (Checkland 1999, 2006) to appreciate different world views, identifying what processes and activities ought to be present to meet corporate vision and what monitoring and control activities are needed to meet strategic objectives and continually improve processes. The power of value chain analysis (Porter) and value nets can also be useful to recognise viable solutions and to enable effective prioritisation. The Agile Business Analyst will also become a negotiator and facilitator within the Agile team, but these are by no means their only contributions.
The early Agile approaches were fine for projects where small teams were making straight-forward small changes. For the larger scale projects with corporate impact, we need a more robust and well defined, but still Agile, approach, and good business analysis skills are essential. DSDM Atern is the only Agile approach to fully recognise and define the role of the Agile Business Analyst (www.dsdm.org).