The business analyst is part of an agile team.

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 infographic on LinkedIn explaining that Business Analysts are a vital part of scrum and play 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 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 that 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 as a business analyst 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 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 analysts' professional skills and the project's power 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 unnecessary 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 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 development team member.  As part of the team, they can help with testing, documentation, technical writing, and pitching in with the developers.  A business analyst is an important and valuable skill, like testing, UX/UI, and coding.  We do not need to make a new role for it on the scrum team.  

The business analyst role is now part of the development process and should not have 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.