I’ve been doing business analysis for a long time, in many different development methodologies, and it still surprises me when I hear someone say this. How could there NOT be BA in Agile? Isn’t agile supposed to be all about the business user? In which case, wouldn’t we need a special focus on their needs? And isn’t that precisely what a BA does? Well, duh…
But…evidently people take published methods as gospel. And apparently scrum is the current popular flavor that even large, established companies are following. To the extent that, I would argue, they aren’t using the Agile mindset anymore – because they are following to the letter and not adapting according to their situational needs. And, indeed, there is no BA in scrum. Or…is there?
According to the vast majority of publications on scrum, there are 3 parts to a scrum team: the Product Owner, the Scrum Master, and the Scrum Team. The Scrum Team is often referred to as Developers. Nowhere in this list of people is a Business Analyst. Yet, we know that business analysis is essential. So who does it?
In a perfect, harmonious scrum world, the answer would be “everyone on the team is responsible for the business analysis function.” Sadly, we do not live in that perfect, harmonious world. So, who really does it?
Many would say, well, of course it’s the Product Owner. They are, after all, supposed to be well-versed in the needs of the organization and translate those to the technical folks. They may even write the user stories. That sounds very BA-esque. The trouble is, many organizations don’t have dedicated Product Owners; that role is filled by someone who still has a “regular job” to do, and so their Product Owner duties often slip in priority.
So maybe it’s the Scrum Master. After all, they are “in charge” of keeping the team on task and removing obstacles. Requirements are just a form of an obstacle, right? Gotta have ’em, but don’t want to waste time on them. But again, often a Scrum Master is one role either a developer or someone else takes on in addition to something else they have to do. Plus, wrangling the team toward scrum goals and handling actual obstacles can be a full-time job on its own. So, the likelihood is they aren’t focused on BA-type tasks.
So then there is the Scrum Team, or the Developers, depending on what your organization calls them. It makes total sense, to me, anyway, that the business analysis activities would be taken on by these folks. However, because there’s this concept that the developers need to have a dynamic backlog that is constantly being refined and prioritized so that they can focus on development, the business analysis work really needs to be taking place 2 – 3 sprints in advance of development. That throws a wrench into the concept of developers getting into a Zen flow of development.
So why don’t we add Business Analyst to the scrum model? Well, we can’t because the Scrum Alliance doesn’t show that in the diagram. Why not? Is there some Scrum Police out there that’s going to fine us if we actually have a BA role on a scrum team? Why don’t we, as business analysis practioners, regardless of our title, advocate for this? Or maybe we already are. Maybe the people that wrote the Agile Manifesto assumed that need for business analysis was so obvious that they didn’t feel a need to actually call it out.
I attended a local IIBA chapter meeting the other night, and this question was brought up, and even the presenters of the topic of “business agility” had no insight on how or why business analysis may have been overlooked in many of the common Agile models. So, let’s discuss. What does your Agile practice do to ensure business analysis is included in development efforts? Do you have your own organizational models that include a BA in your teams? Do you practice business analysis, but maybe call it something else?
Leave a Reply