Scrum Basics - Activities, Not Roles

This post is aimed at new Scrum teams, organisations newly adopting Scrum and people who have been doing Scrum for a while but are struggling to get the results they crave.

It is based on a response I gave to a question in a LinkedIn forum:

“The BA role is an integral and implicit part of Product Owner Role in Scrum. What is your take on this?”

This is a very common question among those new to Scrum and Agile. It’s an interesting one and a classic example of why, in my opinion, companies the world over are failing to do well with Scrum.

To begin to answer it, I will let the Scrum Guide do the talking:

• The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
• Scrum Teams are self-organizing and cross-functional.
• The Product Owner is the sole person responsible for managing the Product Backlog.
• The Product Owner is one person, not a committee.
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Departmental silos are entrenched in the way companies typically do things. They are part of the system. The culture. As a result, the urge to maintain departmental silos is strong.

I would suggest this is a key reason why Scrum implementations might (and do) fail.

Straight off the bat, certain elements of the Scrum Guide are typically ignored or deliberately rejected. These elements may or may not turn out to be key in your organisation, but the fact is they are in there for very good reason. It is a mistake to assume from the outset that your context requires removal of these elements.

Scrum is not asking companies to remove departmental silos, but it is asking that these silos are ignored such that they do not exist within the Scrum team. In the Scrum team, everyone building the product increment is part of the Development team. There are only 2 other people in the team — the Product Owner and the Scrum Master. That’s it. That’s the Scrum team model. Period.

There is absolutely no prescription as to who should be in the Development Team, only that the team has all of the skills and capabilities required within it to build a product increment, and that the team jointly owns all of the work, activities and decisions. In order for effective teamwork to flourish, Scrum says that roles should be left at the door.

That does not mean that our individual expertise and experience is left at the door along with our job titles. On the contrary, the best self-organising teams decide how best to leverage the expertise within the team.

If the question asked in the LinkedIn discussion was actually:

“Are the typical activities undertaken as a BA part of the Product Owner’s responsibilities in Scrum?”

then my answer would be that these, and any other activities involved in building and managing a product’s development lifecycle end-to-end, are shared between the Scrum Master, Product Owner and Development Team. This is made very clear in the Scrum Guide.

To that end, there is no “BA role” in Scrum, much like there is no “tester”, “QA” or “UX designer” role. Roles are part of traditional siloed thinking. Scrum (and Agile) focus (deliberately and alternatively) on cross-functional teams. Roles are a function of the particular company, not the activities that need to be done as part of product development.

To get the best results from Scrum it is a good idea to stop thinking about what roles you need in the team, and instead think about what activities are required to build your product. A good self-organising Scrum team will share these activities regardless of whether they have a specialist, designated BA or not.

Personally I like to encourage “collaborative analysis”, where all of the “what” and “why” for every decision, every story, is talked about by the whole Scrum team. Then the “how” is handled by the Development Team.

The popular model of having BAs “writing stories” and handing them off to the developers in the team is highly ineffective, not the hallmarks of a collaborative, self-organising team and about as far from both Scrum and Agile as you can get.

To build products effectively with Scrum, it’s a good idea to map out all of the activities that are required to build the product. Forget current roles and responsibilities for now. Once you’ve listed the activities, gather a team that can execute those activities in their entirety. If your company has BAs and you need one of them for your Scrum team then by all means have them in the team.

But please remember to ask yourself this key question:

“Is the BA part of the Development Team or are they the Product Owner?”

In Scrum, they can’t be both. And they can’t be neither.