Waterfall to Agile: The Role of BAs on Agile Projects
/I read an article today that caused me to ponder on the role of business analysts in today’s agile environment. Steve Blais narrated a story in which the BAs of an organization experiencing a shift towards Agile were forced to prove their usefulness to the organization in the face of an impending extinction.
The Situation
You're a traditional BA. You work in an environment where interaction between end users and developers is not the norm (probably because it's not encouraged or because both parties lack the skills or interest to interact with one other). You’re used to going out to find out what users want, documenting their requirements, requesting sign-off and sending the Requirements Specification Document to developers for coding. You're used to planning your work by estimating the time and effort required to complete analysis. Everything is going smoothly until one day, you find yourself in an agile environment.
Agile is a software development methodology that depends on establishing a direct link between developers and users. It is based on the premise that requirements will change and as such, there’s no need to invest in producing time-consuming or lengthy Requirements Specification Documents (RSDs). An initial requirements envisioning is done to clarify the project scope, an estimate of effort required to deliver the software is produced and requirements are elaborated as needed based on constant prioritization.
It’s easier to see the usefulness of BAs in traditional waterfall development environments where requirements have to be clearly defined in Specification Documents before system development can begin. In Agile environments however, users and developers are expected to sit in the same room and agree on what will be developed, with little emphasis on documentation, thus threatening the role of the middleman - the Business Analyst.
More organizations are beginning to embrace the agile approach because it’s synonymous with adaptability and a faster time-to-market. In the face of increased competition, customer demands need to be met quickly and businesses crave the benefits of quick responsiveness to change. The traditional software development methodology in comparison, does not respond well to change. It requires that you specify your requirements completely (however ideal this might be) before moving on to other stages of the development process in a linear fashion. Yes, there are advantages to this approach, but clearly not in all cases.
How can the traditional BA blend in an agile environment?
Here are the challenges:
Agile requires that the BA produce requirements faster by analyzing through observation or trial-and-error instead of attempting to find out all the facts before development begins
Lengthy Business Requirement Documents are not required; the level of detail is different. Less has become more.
The BA's role in an Agile Environment
In a typical organization, not all projects can be performed the "agile" way. That is, not all technology projects involve specifying and building software from scratch. Software may be bought off-the-shelf or leased in which case, the contribution of business analysis in whatever form is critical. Organisational improvement does not always involve the use of technology. Projects can range from business process improvement, organisational reshuffling to outsourcing - all endeavours in which the role of the BA is critical.
The nature of the game may have changed in terms of our relevance in Agile Software Development projects but we’re still players in it. As Business Analysts, we must rise up to the challenge of the Agile methodology. We should not avoid the change that we constantly preach to users. Now is the time to be an example and show our stakeholders what it is like not to be so afraid of change.
As BAs in agile teams, we must be prepared to:
Produce and explore requirements in collaboration with users, at a different level of detail than we’re used to
Identify missing requirements
Work with users to develop acceptance criteria or test cases for the system
Mentor developers on how things work in the business domain
Assume the role of “Product Owners”
Work ahead of the team to get clarity on some (not all) requirements before the next iteration
Stand-in for users only when they're unavailable (as opposed to being the “permanent“ bridge between developers and users)
Wear different hats: designer, tester, facilitator, product owner, etc
Create a shared understanding of what the product is supposed to do
The Way Forward
If we’re going to be successful in an agile world, old habits must go. Not because these habits are not valuable but because we must create new habits that will help us to cope in a different environment. To work in an agile environment, we must drop the formality of trying to confirm all requirements upfront to one of discovering requirements as we go. We must adopt the principle of “fit-for-purpose” or “just enough” while placing the responsibility of defining requirements in the hands of the customer (with our help, of course). We must be ready to collaborate by empowering stakeholders to define their needs and assisting developers to communicate with users to understand the context of their development work.
It’s no doubt a new order – let’s make it one in which our roles are indispensable.
Moving from the traditional/waterfall approach to an agile approach certainly involves a mindset shift that may not always come naturally or even easily for Business Analysts. This mental shift comes with implicit obligations of adopting new ways of working.