It most likely was derived out of sheer necessity and in some cases desperation. In many varied situations you can pull from it a wide array of tools which will get the job done when you need it most. It’s a versatile, useful, multidimensional asset; a must have for those who dare to brave the unknown.
Swiss Army Knife? No...but that’s kind of cool too.
I’m talking about the Agile Business Analyst.
I chuckle a little inside when I hear the contrast between some Agile ‘purists’ and Waterfall BA’s who live on different islands when it comes to the Agile team roles. On one side you have the self-proclaimed ‘agilista’s’ who evangelize the rainbow and lollipop world of completely cross-functional teams; with each team member well versed in development, testing, analysis and project management.
I personally feel that these individual folks got into their specific line of work for a reason. (Don’t get me going on this ‘BORG’-like scenario, where everyone can, at a high level, perform all functions when needed. I have yet to witness it in real life.)
On the other side you have traditional BA’s saying, “Where do I fit in here? I don’t want to code. I can test but don’t want to do it as a career. I like my BA job just fine but don’t want to limit myself to traditional methodologies. Where do I fit in the Agile world?”
Ladies and gentlemen, I give you the Agile BA.
Let’s take a moment to break down why this role is so crucial to an Agile team...
Imagine a far-fetched scenario where your technical experts aren’t real great personal communicators with the business representation (there’s that smile). Imagine another far-fetched scenario where Product Ownership isn’t 100% dedicated time-wise to the team. Throw in just for giggles the idea of an over-utilized QA team that is looked at as a bottleneck in quick to market delivery. Oh...and by the way...we are Agile and assume we don’t have to document what we do (no matter what SOX, HIPPA, FTC, ISO or anyone else has to say).
To summarize, we have poor communication between business reps and development regarding needs, poor quality due to overworked and under-appreciated QA, and compliance\legal\information assurance breathing down our necks because they need something, anything, showing we actually are thinking through how we handle data.
For some, this little picture we painted here might represent exactly where you live now! For others it may paint a picture of where you see yourself headed.
I give you the Agile BA.
Let’s start with the developers. They need someone who can talk business-eez and translate that into technical jargon. They can’t get the PO to spend any dedicated techie time with them but the need is still there on a somewhat daily basis. Now, don’t mistake this to say the BA should play the PO role. One voice makes the call on value and priority in the backlog. But an Agile BA will have a great relationship with the product owner and help create a bridge between the two by becoming a business to IT translator.
The most common area of success I see in this “translator’ role is when teams practice the “Three Amigo’s” approach to development. This is where a developer, tester and BA will sit down and hammer through the known details of each story before any actual work is done.
Ever needed something from someone who spoke another language? Remember that feeling of utter relief you felt when the Good Samaritan who could translate stepped in to assist? They didn’t tell you where to go, but they could sure help in getting there.
I give you the Agile BA.
How about our testers; our QA brethren? They are the ones who get code at hour 11. They are the ones who are pushed to sacrifice quality for time. How can our Agile BA assist?
Being as familiar as they are with the backlog of work, requirements, and business/technical needs, they are ideally suited to assist in some of the higher level testing efforts that will help ensure new levels of quality. They are careful not to encroach into the technicalities surrounding the QA world, but make themselves available to QA as an additional resource to ensure completed requirements before passing on to their PO for final approval. They are many times best placed as a final set of eyes to keep the team from the burden of unwanted rework. In this scenario I have seen the BA become the product owner’s right hand (wo)man.
QA can feel a little on an island at times. They are the bearer of bad news and the messenger is often killed in these circumstances. They need someone to help evangelize quality and point out what we will simply call ‘opportunities for improved code design’.
I give you the Agile BA.
Finally, agile documentation (not an oxymoron).
There are companies out there, who I won’t address by name, which have refused to adopt Agile approaches due to the perception that their compliance level will be at risk (no pun intended) due to the perceived lack of sound documentation in Agile practices.
It’s important to remember that great Agile teams will do what is needed to provide the business with top value. If the business has determined that a certain level of documentation is required in order to continue to provide this kind of value, than the Agile team had darn well better plan for that documentation need.
Working software is, according to the Agile Manifesto, of considerable value to the business. But remember that the manifesto does not say documentation is without value. It simply states working software is considered of more value.
Well...yeah... of course. We want the software, predominantly. But real world tells us that we need to prove compliance and best practice data security. It’s hard to do that with a poorly written user story!
I give you the Agile BA.
With their day to day involvement on the Agile team, inclusive of the product owner, they are ideally placed to help define which parts and pieces will create the most value from a documentation standpoint. They can work with the team facilitator/scrum master/etc. to find out who needs what and then help translate that into streamlined and useful (valuable) documentation.
Funny thing is the teams I’ve worked with find the Agile BA to be one of the most critical roles on the team! We can swap out a developer if need be. Rotate the testing around a little if you must. But please, PLEASE don’t take away our business analyst!
There is a side effect though. Our Agile BA’s are often asked eventually to become product owners themselves. Why?
Well let’s walk through this again...
1) They have experience in translating business needs to developers
2) They know what to look for in quality products
3) They have experience working with business partners in backlog prioritization
4) They can determine streamlined documentation needs that fit business value
5) They know what it means to be engaged with an Agile team day after day.
I’ll be honest here...that’s a product owner worth their weight in gold.
Agile is all about providing value. When you look at the many ways an Agile BA provides value to their team, how could anyone question whether or not there is a seat available at the table? The Swiss Army Knife is considered a must have by some (Swiss Army anyone?). It’s flexible, useful, valuable...dare I say...Agile?
Make no mistake, as timeless as that tool is, the time is coming very soon when you won’t see an Agile team without their handy-dandy Agile BA which you will have to pry from their cold dead hands!
