Where Exactly Do Waterfall BAs Best Position Themselves on Agile Teams
Let me begin by establishing who it is I am speaking about, when I use the phrase waterfall BA.
I use this reference to speak to the business analysts who have worked waterfall projects but have zero experience working on agile projects. I also include in this group the business analysts who are working in organizations who ‘say’ they are following agile practices – but really aren’t. While the size of the waterfall population continues to diminish, this is not to say we don’t still have a pretty good sized audience out there who are delivering their projects using a waterfall approach or who have minimally mature agile skills.
In fact, the 13th annual State of Agile Report by Collabnet VersionOne informs us that 83% of organizations are still coming up to speed with agile.
With this being the case, I am still coming across many business analysts who question their ability to transition to agile, the best approach to get there, and where they best fit in, on an agile team once allocated to one.
In this article, I wish to address the latter.
So you hear that your organization is going to start running projects using an agile approach to delivery. If they choose to follow Scrum – you understand there are 3 main roles:
- Product Owner
- Scrum Master and
- Development Team
But as a waterfall business analyst – where do you fit?
The good news is that the answer to this question is ‘anywhere you want to’!
Let’s quickly break down the objective of each role and then discuss why business analysts are well positioned to fulfill the responsibilities of any of these positions on an agile team.
Product Owner – the representative for the business or user community. The person who takes responsibility for setting the priorities of the requirements and choosing which features will be addressed in each iteration and release.
Scrum Mater – the facilitator for the team. The person who takes responsibility for ensuring the team adheres to the agile principles and practices they have agreed to uphold.
Development Team – everyone else. All members of the development team work collaboratively to deliver a product of value to the business/customer. Development team members self-organize and therefore ‘collectively’ take ownership for delivering the final solution.
You might be thinking ‘wonderful’ but I still didn’t see something like ‘the person responsible for eliciting and specifying the requirements’ …so where do I really fit?
Let’s tackle that question by looking at the skills a waterfall business analyst possesses and then tie those skills to the 3 Scrum roles. We’ll then close out and speak to how requirements elicitation and specification on agile projects are different…and why you didn’t see this spelled out specifically above.
The following word cloud was created using the skills as listed in A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v3. There are close to 30 skills identified as being critical skills a business analyst should possess in order to effectively perform their role.
This means that if waterfall business analysts have been performing their current roles with a mature skillset – they possess some of the most important skills needed by agile teams!
Here is a ‘very’ preliminary mapping of business analysis skills to the Scrum roles. I indicate ‘preliminary’ because you could really make an argument for a lot of the skills listed above for each of these roles.
- Business acumen
- Conceptual thinking
- Decision making
- Industry knowledge
- Organization knowledge
- Problem solving
- Visual thinking
- Conceptual thinking
- Decision making
- Leadership and influencing
- Negotiation and conflict resolution
- Non-verbal communication
- Methodology knowledge
- Problem solving
- Creative thinking
- Personal accountability
- Problem solving
- Solution knowledge
- Systems thinking
- Verbal/written communication
When discussing where the waterfall business analyst ‘best’ fits, it ends up being more of a discussion about which position is most appealing to a business analyst and which would they ‘prefer’ to do.
For example – an analyst wishing to move into a Product Owner role would be someone who has in-depth business domain knowledge, strong customer empathy, and understands how to make tradeoffs based on value and risk. For someone who can envision the holistic view and enjoys sharing their business insights to others, enjoys setting vision and scope – the product owner role might be your calling.
If an analyst has strong leadership skills, has a passion for addressing issues, finds motivation from helping others, understands agile principles and enjoys teaching others, then serving as Scrum Master might be your passion.
For waterfall business analysts who enjoy facilitating discussions to discover requirements, has strong writing and communication skills, and enjoys a more tactical role of defining requirements in the format and deliverables expected on agile projects – then lending business analysis skills to develop user stories and acceptance criteria and facilitating discussions around this work is your place.
My last point is to make sure waterfall business analysts understand that transitioning to agile requires more than just a robust set of skills. While several of the activities a business analyst performs on waterfall projects is similar to work that is performed on agile – there are some BIG differences. This is why you didn’t see me spell out requirements elicitation and specification – which are traditional names for activities business analysts perform on waterfall projects.
On agile, we see the differences between waterfall business analysis and agile business analysis appear in 3 main areas:
- What we call the activities we perform e.g. we conduct a process called approve requirements in waterfall versus activities called backlog refinement and iteration planning in agile to determine the requirements the development team will work on.
- The approach to our work e.g. we perform our tasks sequentially and prior to any development work on waterfall versus performing our tasks iteratively and incrementally in agile, and
- The types of deliverables produced e.g. we produce business requirement documents and software requirement specifications on waterfall vs. user stories and acceptance criteria in agile.
If you are interested in knowing more about how business analysis is tailored for agile – check out The PMI Guide to Business Analysis referring specifically to the tailoring tables included within that standard.
Retooling and acquiring new skills for agile means you will require new knowledge and new experiences. Knowledge is acquired from ‘your’ hard work – reading and professionally developing. Once you feel you have acquired enough knowledge and understanding about agile – pair that up with your robust skillset and start looking for opportunities to start gaining on the job experience on an agile team.
The good news for waterfall business analysts is that there is a position for you on an agile team. You bring with you a strong set of core skills and fundamentals. Decide which position ‘best’ fits your passion, set your professional development goals, and attain the knowledge and experience you need. Good luck!