Why are some business analysts so non-agile when thinking of their role in Agile?
Are we harming ourselves by trying to protect our role rather than focusing on our value?
For many years there have been countless debates on whether a BA has a role in Agile, and if so what that role is. What isn’t discussed so much is how BAs are impacting those debates through their actions and behaviour, rather than what the organisation is forcing on them. Before I get to that I will need to provide my simple approach to business analysis in general as I like to think that drives my overall perception. Just a quick note, if you’re reading this hoping for a technical definition of a business analyst or Agile software development then it’s probably best you move on.
What is the purpose of business analysis?
Business analysis provides: -
- Context
- Clarity
- Perception
- Insight
Often this comes from people who don’t actually realise they already know it and by asking questions that are so obvious that others take them for granted or don’t take the time to think about them. Yes that’s right, think simplicity. Slow down, take a step back and think logically and holistically.
What are the steps of business analysis?
As I said, forget the technical definition. Google is your best friend for that. I like to think of it as a few steps: -
- Gather
- Consolidate
- Analyse
- Describe
Does business analysis fit in Agile?
Based upon the above the answer surely has to be yes. The purpose of business analysis is required regardless of the approach. To create relevant and useful software that creates value and opportunity one must have already obtained what business analysis provides. I don’t think this is news to anyone.
Does the BA fit in Agile?
This is where things start to get a little more emotional, especially for many BAs. Too many get stuck on the described structure of an Agile software development approach and lose sight of what is trying to be achieved. I’m not going into Scrum or others and what they do or do not describe. Again, you can read that anywhere and don’t forget that these are largely guidelines and recommendations, not rules. Regardless of the method and what it describes then if business analysis is required then a business analyst must be required. It may well be though that this is under a different hat. Describing what those hats may be is something for another day if anyone is interested but it leads to the idea that perhaps some BAs are stuck thinking and being concerned for the position rather than their value. This is where I feel it all starts to go wrong.
The BA Funnel
In my mind the one thing that should be avoided is what I call the BA funnel. This is the situation where every requirement must go through the BA, if one exists. This often comes about for one or both of two reasons: -
- The misconception that BAs write and own requirements.
- BAs fighting for job security and enforcing themselves as a mandatory step in the process.
The former is a whole other topic that can also be discussed another day if people are so inclined to come back for more. The latter is what I wish to discuss now, and yes finally i’ve got to the point of this. Hopefully the foundation above was useful for some context. There’s number one in the purpose above, and hopefully you’ve obtained some of the others along the way also!
To me a BA should be able to adapt to different environments and domains, not being restrained by one train of thought. Dare I say it, agile in their thinking. That’s what makes the second reason so strange to me. Instead of adapting to the environment many BAs move into a mode of survival, needing to prove and justify themselves. To do this they start to wrap their arms around requirements and become the gatekeeper of them. This is not only a problem for the BA, the whole team, the business or product software itself, but also for BAs as a whole.
The Detrimental ‘Survival BA’
The Survival BA, a BA in survival mode, in my view is hindering rather than helping. What occurs?
- You become a bottleneck in the process
- You become inflexible in your thinking
- You start to feel you know requirements better than others
Those main symptoms have the consequence of impacting the perception that others have of BAs. This ultimately has the reverse affect. Instead of enabling others to see the value that someone with business analysis skills can add (regardless of their role or title in the team) it has the affect of preventing collaboration and putting in further jeopardy the security that was initially desired.
The real questions are: -
- Do you need the role and title or do you wish to add your value to the software development process?
- Do you want to help everyone see the benefits of business analysis, or do you want to sink the ship?
It’s in your hands!
If you’re interested in hearing more on any of the following let me know and I may well provide my simplistic thoughts on those also.
- Does Agile give a business analyst more or less autonomy?
- When does a designated BA seem beneficial in Agile?
- If a BA doesn’t wear the business analysis hat then where did it go?
- Does a BA write and own requirements in Agile?
- Are required business analysis skills changing, or is it only their application?
Thoughts / comments / questions / criticism / feedback are all welcome, otherwise I wouldn’t be a BA!
Originally published at https://www.linkedin.com on February 28, 2017.
