So, you’ve heard the news – your organization is going agile. Or you are looking for jobs, and every single one requires agile experience.
What does this mean for you, your career, and business analysis? How do you leverage your skills and experience in more traditional, waterfall environments to succeed as an agile business analyst?
That’s what we cover in today’s video.
For those who like to read instead of watch, here’s the full text of the video:
Agile is a huge opportunity for you as a business analyst.
I’m Laura Brandenburg. I’m the creator of Bridging the Gap. Today, I’m going to share exactly how you can move forward as an agile business analyst with a waterfall background.
First of all, agile teams definitely need business analysts. We give the requirements and the insight that help that agile team be successful. This is a huge opportunity for you as a business analyst.
Waterfall to Agile Tip #1 – Ground Yourself in Core Business Analysis Practices
The first thing to do, it’s important to just ground yourself in core business analysis practices and why they are important. This doesn’t mean you get to stick to your old way of doing things and kick and scream about how essential you might feel it is to create a BRD, a business requirements document, or an FRD, a functional requirements document, or whatever type of document you are used to creating as a business analyst.
This means you have the opportunity to look at why you create that document.
- What value does it provide?
- What do you find most helpful about it?
- Where would the team fail if you took it away?
I believe that business analysts create clarity and eliminate ambiguity. Your existing documentation is likely one tool for analyzing the requirements and doing so with clarity. There are many tools that you can use to do the same thing. So, understand your value. Your why. What you do and why it’s important. That’s your first step because you want to go into the agile team with that inner confidence and that inner self of value and personal power.
Waterfall to Agile Tip #2 – Let Go Of Your Existing Templates
Second, it’s going to be the hard one, let go of your templates. All of them. Poof. Just let them go. They’re gone.
You’re on a new project.
- What are you doing now?
- What questions are you asking?
- What decisions are you driving?
Take a moment to visualize if you let go of everything you do today, what would you do, what would you truly need to document and why? This can be a thought experiment. You don’t have to throw away all those templates and all that work. But can you trim it down significantly?
In our Business Analyst Template Toolkit, I provide my very streamlined shorter templates. They’re great alternatives to traditional BRD or FRD you might have been used to creating in a waterfall environment.
Waterfall to Agile Tip #3 – Collaborate with Your Agile Team
Talk to your agile team. What would help them the most? I’ve been on several agile teams and they all wanted different things from me on different levels of detail.
- What information are they expecting to have in place, and when do they need it?
- What deliverables will help them the most?
- Do they want to see wireframes, or data models, or use cases, or user stories?
They might not know. And if so, you can provide some examples and ask for feedback. They might have a very specific set of expectations.
When shifting to agile, it can feel like a lot of our traditional tools just get thrown out the window. I can remember my first agile project. I knew I had to trade my beloved use cases for user stories. I didn’t know what that meant. And so, it turned out that I still needed all of my use case thinking skills, and the user stories nearly became another way to package and communicate those functional requirements.
My core business analysis skills – that gaining clarity, that discovering needs and requirements for business stakeholders, clearly documenting, and analyzing, all of that was absolutely, positively essential to my agile team. Agile didn’t replace them and, actually, augmented the need for them. Even though our skills are important, we do need to shift some aspects of our work, so we can deliver the most possible value and earn the respect of our agile teams.
In the three steps I walked you through – thinking of your “why,” owning your value, discovering why it is you do what you do, at least going through the thought experiment of just throwing your templates away and coming up with what is essential to your success as a business analyst – and then deeply and intently, and consciously collaborating with your agile team.
Learning enough about agile practices, like user stories and product backlogs, and then going to your team with some ideas and getting their feedback along the way to make sure you’re creating requirements and documentation that help them deliver working software more quickly.
You do these three things, and your transition from waterfall to agile might not be easy; there might still be a few kicks and screams, but it’s going to happen with more ease and grace, and you’re going to come out on the end, probably, appreciating some of the positive changes that you can experience, and your teams can experience, and your organization can experience when they transition to agile. I know I did.
It was a lot of fun getting to work on an agile team and getting to see my requirements become more closely modeled in reality and becoming a closer partner with the tech team than I had in more traditional environments. It’s a great way to accelerate my career and see more positive change happen more quickly for organizations.
I hope you had a lot of fun with it. I hope that it helps you grow your career. I’d love to hear what’s coming up for you as you go from waterfall, or traditional approaches, to more agile business analysis practices.
Again, I’m Laura Brandenburg, from Bridging the Gap. We help business analysts start business analyst careers.
Thanks for watching.