The Business Analyst as Part of an Agile Team

It has to be said

From time to time, an agile coach needs to speak truth to power.  It often has career repercussions and creates more drama than an Anton Chekhov theater production.  A benefit is a truth-based approach to business, or anything else means you are confronting the reality of a situation rather than some other person's magical thinking.  I noticed something this week which bothered me, and I feel the need to call it out.  

Ananya Pani from the International Institute of Business Analysis posted a blog and info-graphic on LinkedIn, which explained that Business Analysts are a vital part of scrum and represent an active role in successful agile teams.  I am going to post the original blog here so you can read it yourself.  It is necessary to critique her arguments.  

If I were going to be prescriptive, I would point to the current scrum guide and highlight no mention of business analysts in it.  A scrum team is a Product Owner, a Scrum Master, and the development team – nothing more.  I realize for most agilists point to the scrum guide and saying that it is the only way to run an agile implementation is counter to the agile manifesto, which says, "Individuals and interactions over processes and tools." I need a better reason to object to Pani's role of business analysts in agile.  

The business analyst is a relic from many waterfall ways of managing projects.  A good business analyst knows about the needs of the business and can transform them into requirements.  It is the same skill set as a product owner, but it lacks the autonomy and authority of a product owner.  In my experience, I often see business analysts taking orders from project managers, and they generate documentation rather than working software.  The way most organizations use business analysts is degrading to the professional skill of the analysts and the power of the project to deliver value.  It is a position designed to create friction in an organization rather than help improve work.  

Additionally, Pani assigned the duties of a scrum master to the business analyst instead of the scrum master.  If I understand her correctly, a scrum master is not necessary on agile teams.  Observations like this point to her having excellent knowledge of Business Analysis but little understanding of agile and scrum; I look forward to her taking some PSM or CSM training and seeing if her perspective changes.  

I do not want to pick a fight, but I feel that the business analyst role is a square peg in the agile world, and we should not try to wedge it into the paradigm of a scrum team.  Instead, we should treat the business analyst as a member of the development team.  As part of the team, they can help with testing, documentation, technical writing, and pitching in with the developers.  Being a business analyst is an important skill and has value like testing, UX/UI, and coding.  We do not need to make a new role for it on the scrum team.  

The truth is the business analyst role is now just part of the development process and should not have any special privileges.  As coaches, we can fold business analysts into scrum teams and then prepare them to take on the role of scrum masters and product owners in the future because their skills translate into those roles.  We need to be honest with ourselves, business analysts are a legacy profession, and they have plenty of expertise to make agile teams successful.  We should take that expertise and fold it into our agile practices.  

Until next time.