From Waterfall…….
As a Business Analyst for nearly 5 years now, I’ve experienced working in both Waterfall and Agile frameworks and even hybrids of the 2 (you’ve all heard of Wagile right?)
My first experience as a Business Analyst was working in a large UK government programme with a team of Business Analysts creating use cases for a complex business process. I joined the project as a Subject Matter Expert (that’s how BAs were recruited) and it was pure Waterfall.
Documentation, documentation, documentation
Everywhere you looked, there were Gantt charts, Project Critical Networks, risk logs, requirements documents and process maps. Include all the different versions of these documents and you can imagine what it was like looking for something in a shared folder. And that was just the Service Design team I was part of. It was all about documentation as a BA (or certainly seemed to be).
As a BA in this environment, it was a struggle. We all know this scenario. You spend hours and hours (and more hours) working on a use case for a complicated user journey and at the stakeholder review, your work gets torn to bits with holes picked in it left, right and centre. And the critique not only came from stakeholders but your fellow BAs (we called it ‘friendly fire’). It was demoralising to say the least.
Waterfall to Agile? Piece of cake right?
Fast forward 18 months and I have the opportunity to be part of a new team (still in UK government) that will develop and deliver a product using Agile (Scrum in this case). I’d already been on a couple of Agile training courses and absolutely ‘got’ the concept of Agile so as you can imagine, I was excited!!!
Before joining though, I was asked what experience I had as a BA. Well, having served some time as previously mentioned, I thought I was more than suitable for the role and felt comfortable that I could transition easily from a Waterfall BA to an Agile BA. How wrong I was!! I thought that surely the BA tools and techniques I used working in a Waterfall environment should be the same for an Agile environment right? While this is absolutely true, you still carry out stakeholder analysis (for example), but you do it very differently.
And that’s what this blog is about, what I learnt and what you can do as a BA to transition from Waterfall to Agile including:
- Shifting focus from less documentation to more conversation
- Building your T-shaped skills
- Being creative with BA tools and techniques
Get off your laptop and speak
Firstly, the biggest difference I found was working day to day with a small team (6-8 people) in the same room. Now this might not sound too traumatic but if you’re used to working in an organisation where you dealt with other teams via email and telephone because they’re located in either another part of the building or more commonly another city/town, having constant face to face conversations was novel. And it took some getting used to. However, after a short space of time, I think this was the one most important aspect that allowed me to develop my knowledge and skills as an effective Business Analyst.
In Waterfall, your engagement opportunities were predominantly through workshops, telephone and email whether it be to gather requirements or present documented requirements before baselining for handover to the next stage.
In the world of the BA, you’re constantly gathering or giving information, whether it be to define an ‘as is’ process from a subject matter expert or explaining a user story to the development team. Believe me, getting or giving this information face to face is so much more productive. How many times have you had comments back from a stakeholder who’s reviewed your requirements document which you can’t make head nor tail of and has resulted in further phone calls (or worse, an email conversation!!!)?
Become more T-shaped
When you’re sitting next to and around user researchers, interaction designers (UX), content designers and the like, you have the opportunity to ask questions, clarify information, and generally learn more on the subject. You don’t need to go on a ‘Design overview’ course or ‘User Research 101’ to learn about those subject matters, you learn by speaking to them. Now don’t get me wrong, you don’t need to become an expert in these fields, you just need to know enough so when you are creating user stories, or using investigative techniques with stakeholders, you have the knowledge to apply it to your findings. And it also gives you opportunities to broaden your skills as a BA. You should be carrying out user research sessions with the user researcher or prototype testing with the UX designer. It all adds up to you building your T-shaped skills as a BA. (great webinar here http://masteringbusinessanalysis.com/mba050-the-t-shaped-business-analyst/)
I actively went out of my way to learn everything I could from them and this is my first tip: have the desire to keep learning. I’m sure leaders in the BA industry will tell you they are still learning, and will never stop. Like most things in life, don’t expect knowledge to fall in to your lap, you need to actively seek it.
Be brave and show off
Next big change for me was ‘working out in the open’. Again, not something that’s prevalent in a Waterfall environment (see opening paragraphs) where most (if not all) outputs are held in shared electronic folders, in Agile, it’s positively encouraged. Go in to any Agile team and you’ll see (or should see) user story maps, sprint boards, Kanban boards, Product Roadmaps, user research findings, prototype screens to name but a few. Using wall space to show your work and thoughts/ideas creates an honest, transparent way of working. As a BA though this is great!!! Instead of being constrained to filling out standard business requirements documents, you can at last be creative and put your rich picture, infographic or mind map on the wall for all to see and give you comments face to face. Wow, revolutionary or what? Here’s my next tip: there’s no room for shyness in Agile. Be courageous and confident in displaying your work and get used to having open and honest conversations with the team and stakeholders. I promise it will make you a better BA.
In my next blog, I’ll be talking about how you can use BA tools and techniques to bring out the best in a cross-functional Agile team.
Agile BA blog 
Leave a comment