Scrum Basics Part 1 – Activities, not Roles

This is the first in a series of small posts 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.

This post 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.

6 thoughts on “Scrum Basics Part 1 – Activities, not Roles”

  1. This is just an observation:

    You’re right, of course! This is the question that started me on my Agile journey, having been a BA for many years, my great fear was that with the increasing adoption of Agile, my role/job/career had become redundant and I was no longer needed. Experience and a lot of research confirms that this is not true at all, my BA skills contribute to the team in a far greater range of ways than used to be the case, I am no longer constrained by the silo of the role and title. This is a very good thing for me but my organisation still wants to put something specific on my business card and PD; “Development Team Member” doesn’t really do it for them, a few “real” dev team members get a bit antsy about it too, but for different reasons.

    For those BAs and PM’s who are just engaging with Agile and Scrum, this is a big challenge, it’s a source of fear and discomfort. People have traditionally defined themselves and their careers by their titles, at least to some extent. I think this could be one of the reasons why we see so many hybrid, invented roles, as well as proposals of new titles e.g Value Manager or Iteration Manager. More importantly I suspect that the presence of these is a good indicator of the real level of Agile maturity, in software and corporate governance in general. I’m not sure we are even having that conversation yet, the implications of which are further reaching than we can imagine.

    1. Thanks for your comments Kelsey!

      I very much agree with what you’re saying. What I feel is that the traditional and generalist skill set of the BA has been increasingly thrust into the spotlight over the last few years, to the point that companies see BAs as an absolute necessity for Agile teams. There is so much emphasis in Agile around bridging the gap between the development team and “the business”, and the BA is a natural fit for this. BAs are also asked to fill skill gaps in testing, product ownership and management.

      This is where Scrum is coming from with its no role approach, I believe. Rather than addressing skill gaps with training and coaching, organisations tend to take the easy path and hire people in siloed roles. This is why an activity approach is more effective than a role approach. Put the best team together that you can, let them work in a Scrum, let them decide what activities are required to build the product and keep the stakeholders happy, let them decide what skills are missing to execute these activities and then provide them with the necessary coaching and training to help fill those gaps.

      Assigning Scrum activities to particular job titles discourages true collaboration.

      The poor old BA has become the catch-all role in an Agile team. Iteration Manager, assistant to Product Owner, coaching the team, facilitating meetings, running workshops, stakeholder management, gathering and documenting requirements, etc. etc. This perpetuates the “them vs us” mentality to software delivery, is not an effective approach, and is not in the spirit of Agile or Scrum.

      BAs (the people) are wonderful, but the dysfunction of hiring a BA to make up for skill shortages elsewhere is flawed in my opinion.

      1. Thank you :-). I wonder whether it really is the poor old BA though, the “catch all” role is great description, it describes what I do, and as it happens I love it. It’s a perfect generalist role, varied, interesting and challenging, I think it’s fine, we don’t need to give it a name, we just need to value it.

  2. I think this is a key sentence in your post:
    “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.”

    That goes a long way in clarifying the confusion on roles in agile.

    However, I feel there is still a problem:
    I think if a team is not strong in a non-dev activity (testing, design, prod. documentation), they may continue to flounder. e.g., let’s say dev writes specs in a team, they don’t have a product designer. They may never know that they could benefit from one such. One could argue that the situation could only be worse if the team didn’t follow agile.

    However, I think it would be better to acknowledge the various non-dev disciplines (including management) and encourage expertise in them. Expertise can be developed by all team members, as long as they are motivated in the activities.

    I don’t think the importance of expertise in non-dev activities comes across in your post. I am also not sure if a team is not strong in an area, e.g., product design, if they have the motivation or permission to recruit/find an expert in prod. design, i.e., it seems like ‘agile’ would allow them to limp along.

    Disclaimer: This is not meant to be an attack on agile or scrum.

    1. Hi Nilanjan,

      Thank you for your comments. Very good points. Sadly, I think sometimes companies use “cross-functional team” as an excuse for sharing activities with fewer people at a reduced cost. UX is neglected in this way in many companies I’ve worked at or visited. Product ownership the same.

      Much of this boils down to whether an organisation wants its software delivery arm, and itself as a whole, to be mediocre or brilliant. The most effective teams combine individuals who are brilliant at what they do but humble enough to want to share their skills and learn from their colleagues, and want to achieve things as a team rather than individuals.

      Agile does get used as an excuse to do things poorly sometimes. The irony is that its intention, and the only way to leverage its principles effectively, is the complete opposite – a relentless pursuit of improvement and excellence.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s