Agile Business Analysis is not the usual IT business analysis process that happens prior to the development phase of traditional waterfall projects. Since the business environment is always changing so are the user requirements in response. The challenge is to keep on accepting the changes and hence deliver the highest value application to the customer. Also when a new application is being built, how does an end-user know what he/she needs when they have never used the application before? The end-user somewhat knows what they want beforehand but they will really know what they need once they get some experience using the application. Therefore change is continuous and agility is the key! Agile business analysis is such that it welcomes and enables changing requirements. It is so adaptable (agile) as it is based on a minimalistic principle and puts paramount emphasis on collaboration between the business customer, other business stakeholders and the whole project team.
The Traditional Activities of an Analyst
- Scope the system.
- Translate business needs.
- Translate technical issues.
- Model and document.
- Act as a communication broker.
- Political mentor.
- Test and validation.
- Represent stakeholders
The Agile Analyst
Many of the traditional analyst activities listed above are embodied in the Agile Analyst, however the approach is modified. OPI development teams follow the practice of Active Stakeholder Participation, which means that they work closely with their project stakeholders. The goal of this practice is to reduce the feedback loop and thereby improve communication. An interesting implication is that the role that a BA takes on changes dramatically based on the communication options available to your team. There are three categories of team organization that need to be considered with respect to how an “Agile BA” will interact on a project team:
Co-located teams: The project stakeholders, SME’s and project team are all located in the same open area.
- This is an ideal situation that you should always strive to achieve. Within this organizational model the BA will be facilitating requirements and analysis modeling efforts with the entire team as needed.
- They would actively work to facilitate communication within the team. The BA focus will shift from “We’ll go out and find out what the customers want and bring it back”, to “We’ll go help the customers figure out what they want, so they can tell us”.
- This change of focus leaves control in the hands of the customers, and makes all the difference. Additionally the BA will provide any analysis artifacts required for the project.
Near-located teams: The project stakeholders and SME’s are near the project team, but not co-located in the same physical area.
- In these situations the agile BA takes on some of the aspects of a traditional BA. In particular, in situations where the stakeholders are not able to partially co-locate with the development team the BA will need to work with them in their own environment.
- This will likely entail modeling sessions and interviews with the project stakeholders. The Agile BA will typically bring one or two other developers with them to these sessions, that way the developers can learn the business knowledge that they need.
- The agile BA will also model a bit ahead of the team, gathering the information which they need a few days or weeks before it’s actually needed: too much modeling ahead may result in the sort of wastage seen with a big requirements up front approach.
Geographically dispersed teams: Team members are spread across a wide geographic area.
- This situation is the least desirable because of the barriers to communication it creates, however proven techniques have been identified and used successfully to help bridge the communication gaps.
- The BA will facilitate conference calls, video conferences, and online meetings between the team members, including the project stakeholders. They’ll help to arrange periodic co-locations where some project stakeholders travel to the developers, or vice versa, to enable some direct interaction between the groups.
- Additionally, requirements will need to rely on written documentation and/or a prototyped system more prominently in the absence of a co-located project stakeholder. If a prototyped system is used as a tool for requirements clarification, it should be noted that this is typically NOT throw-away code, but rather working code that allows the project stakeholder to visualize and understand system requirements more clearly.
