Agile roles and responsibilities

Agile roles and responsibilities in the agile world, and in particular for Scrum, have been described extensively in numerous publications. In this article I want to point out a method that has successfully been employed in waterfall-style project management, and that could add significant value to agile processes as well. I’m talking about Responsibility Assignment Matrices (RAM) , a technique not well known in the Agile community. but that could are usually Scrum projects do not usually require explicitly creating RAM artifacts. However, when things go wrong, and sometimes they do, Product Owners (PO), Scrum Masters (SM) and eventually other stakeholders look back and ask: “Do we have a RACI matrix for this project?”

Agile roles and responsibilities plus RACI

There are Scrum practitioners that think RACI cannot be applied as is in a Scrum project management practice. Although many variations of RACI exist, some practitioners feel the urge to add new Scrum specific roles (like “F=Facilitator/Coach”), new Scrum specific activities and responsibilities (like “ensure consistency of Scrum practices across teams or remove impediments”), or new job positions and roles (like “Scrum Team”) to the matrix like shown in the illustration below.

And no doubt these thoughts – rightfully – spur discussion. Some of these discussions are mostly concerned with the technical aspects of this matrix while others are of more essence and go to the core of the Agile/Scrum principles and pillars, as defined by the Agile Manifesto, and Scrum Guide.

If needed, how should the new Scrum-based RACI Matrix Template look like?

When talking about Scrum flavored agile roles and responsibilities and activities, one should ask why in the above matrix there are activities and responsibilities like “ensure consistency of Scrum practices across teams or remove impediments”, and not activities like “protecting team from interruption”, or “keeping the stakeholders informed”. There is a list of more than fifty activities and responsibilities that are split among the new roles Scrum promotes. A RACI matrix template should be consistent and list all the Scrum specific activities and responsibilities, and more. Once the RACI template has been communicated to the Sprint Team, there should be clear areas of concern defined and we should clearly understand how much responsibility  the Product Owner (for instance) should retain, and how much from the PO’s accountable responsibilities should be delegated to the team.

Then it is about the new job positions and roles advocated in Scrum. In the illustration above, typical Scrum roles like stakeholders and development team are missing, while others are filled in, like project and functional managers. To be consistent to Scrum, we would have to put at least all the missing Scrum roles in.

Explicit RACI attributes assignments in Scrum

It is true that both the Agile Manifesto and the Scrum Guide are just frameworks, and not full-blown project management methodologies. It is also true that the Agile Manifesto is now over 15 years old. However, when crafting the Scrum-RACI Matrix Template we should re-read creatively these documents and only “improve” where it is really necessary. When reading the Scrum Guide we find that:

The Product Owner is the sole person responsible for managing the Product Backlog.

[The Scrum Guide, p5]

and also:

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

[The Scrum Guide, p5]

From reading the text, it should be clear that the PO is actually both responsible and accountable for the product/project backlog management, looking at it from a RACI perspective. Yet, the PO can delegate some of his work to the Development Team, and therefore an R should be also placed in the Development Team column for the delegated PO activities.

By reading the fourth principle of the Agile Manifesto we learn that:

Business people and developers must work together daily throughout the project.

[Agile Manifesto]

According to this principle stakeholders are also accountable and even responsible at least for providing feedback to the Scrum Team.

Implicit RACI in Scrum

Both Agile and Scrum frameworks promote a series of principles, concepts and values that depart from the previous paradigms of project management. According to these values and principles we can depict implicit agile roles and responsibilities in Scrum.

Team work is much emphasized over individual heroics. The Development Team is a self-organizing cross-functional entity and holds the overall accountability for the Sprint increment. While individual tasks are assigned to individuals, who are therefore responsible for tasks completion, the accountability belongs to the whole team.

Scrum encourages transparency, inspection and adaptation. Scrum ceremonies are specifically built to make these values shine. The Daily Scrum is the place where the Scrum Team gets together and learns about the state of the sprint. Everyone is therefore implicitly informed at least once a day.

Scrum is also promoting communication, proactivity, and courage. You don’t need to be on a list of consulted people. All the team can be consulted, and as a matter of fact, the Daily Scrum is a great place to speak up and provide (short) feedbacks to your coworkers when needed.

With all these insights into Scrum-flavored RACI, a PM/PO can build a RACI Matrix Template that can be communicated, and eventually debated, in the same kickoff meeting where the Scrum Team is setting and agreeing upon the project’s Definition of Done.

How about having a Scrum-RACI Matrix mapping actual tasks to real Sprint Team members, like in the waterfall-style?

Well, such a Scrum-RACI matrix should have listed as horizontal rows only activities for which we define actual tasks in the Sprint backlog. In Scrum, tasks are assigned to people, and every decent Scrum software (Allegra included) usually provides a digital Task Board View where you can clearly depict all peoples’ current responsibilities for all the tasks taken into the Sprint. In cases when the Development Team needs to reorganize itself, and shuffles the tasks around among its developers, the task board view should be updated, to reflect the new responsibilities of every developer in the team.

Additional resources:
https://www.toolshero.com/project-management/responsibility-assignment-matrix/