The internet community is divided on whether RACI and Agile methods are compatible. Let’s start with a quick review of the online “literature.”
First there are the writers who believe that you can use both Agile and RACI together and that they are compatible.
In 2012, Christophe LeCoent invented a new code for RACI to make it compatible with Agile, the “F,” which stands for “Facilitator” (the taxonomist who facilitates the activities related to taxonomy governance). You can read more about this in “RACI+F: An Agile Tool for Taxonomy Maintenance.”
In Mike Adler’s post “SCRUM and RACI” (2015), the Facilitator is defined as the role that facilitates communication and information across the team, which aligns with the role of the SCRUM Master. Mike says:
“As we have been putting SCRUM into the organization, it has me thinking about how to help the teams understand roles and responsibilities in the new SCRUM formation. We use RACI internally to help people understand who makes which decisions and why."
This makes sense to me, because RACI is a language you would use to define the scope of a person’s authority. As such, it can be used to help define SCRUM and Agile roles.
But boy oh boy, there are RACI haters out there. You find them on forums and blogs. Let’s take their objections at a time.
1. Agile teams don’t need RACI because the team as a whole is accountable for the project results.
When an Agile team is small enough to huddle daily and co-located, it can often successfully assign the decision-making “A” to the entire team. You don’t always need RACI. (Click here to read “When You DON’T Need RACI: A Checklist.”) But consensus decision-making by an Agile team breaks down when the project involves more stakeholders, departments beyond IT, or in other ways the project becomes more complex (e.g., geographically dispersed, global).
In other words, that works until it doesn’t. As Marius Zubac writes in “Responsibility Assignment Matrix Techniques for Agile World,” “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?’”
The more complex the project, the more departmental boundaries it spans, and the more stakeholders it needs to take into account, the more the Agile team needs RACI agreements with people outside the software development team. Tracy Brala, Vice President of Ecosystem Development at University City Science Center, spent years at large companies like Campbell Soup and Comcast launching new businesses. She says, “You don’t get the big stuff done with Agile. For complex projects, there needs to be one person with the ‘A’ who owns it.”
My colleague Eric Smith, who used RACI for 20 years at DuPont and is now the Corporate Director, Digital at ChristianaCare, agrees. Eric says, “I worked on complex, cross-functional projects, and RACI provided clarification. To me, the tool facilitates cross-functional work.”
2. RACI is a modern outgrowth of Frederick Winslow Taylor’s Scientific Management and as such separates thinking and doing.
This is balderdash. Taylor died in 1915, and his work influenced the building of the modern assembly line in factories. RACI was first published in 1956 in the Journal of Personnel Management. In fact, RACI and other decision-rights tools became more popular as the speed and complexity of business increased and clear roles became more important in that new world. If you have the “R” role in a RACI matrix, you are responsible for delivering a piece of work of the highest quality you are capable. Plenty of thinking involved in that. The “A” role is the person with the authority to approve your work or send you back to the drawing board. Good RACIs also use a role called “R/A” to delineate someone who is both doing the work and ALSO making the decision about the work. As organizations become flatter, more of these roles are created, representing a more empowered workforce.
3. RACI is open to interpretation, which is one of its downfalls.
The whole point of creating a RACI with your stakeholders is to ensure everyone is using the four codes consistently. If it’s a free-for-all in terms of how you define the codes, good luck creating a successful collaboration. Creating a common shared language is foundational to getting the most out of RACI. Eric says, “You can’t do a RACI in a vacuum—especially in a complex project, you need input from everyone as you build it. If you don’t get that input, you’ll end up with a misinformed RACI. But that’s not the fault of the tool.”
4. RACI won’t fix a dysfunctional team.
In his summary of what project managers think of RACI, Jose Maria Delos Santos writes, “PM’s feel that the RACI matrix will not fix a team that has poor morale. Before RACI can be effective, you must have a team that has no issues.”
Reality check. Possibly because I am an OD consultant, I very seldom see teams that have no issues. Small, single-department, effective Agile teams are not our clients. My colleagues and I are, however, called in to help complex, sprawling cross-functional project teams that have poor morale and conflicting ideas about how to get work done, and we help those teams by clarifying role and authority. Role confusion on a team LEADS to poor morale. (Click here to download a role confusion assessment for your team.) When individuals know the scope of their work, it is incredibly motivating. When a team knows how to get decisions made, it can get on with its work with greater certainty and speed, and that’s good for morale.
5. RACI leads to a culture of blame and excuses.
Bob Kantor writes in CIO magazine:
“In almost 100 percent of these rescue efforts, I have found that there is no shared understanding of participant roles and responsibilities, nor is there explicit documentation to support it. Establishing such a consensus by employing the RACI model almost always gets a stuck project moving again and enables the key stakeholders to readily deal with the other issues that require resolution.”
Eric agrees. He says, “In my experience, I’ve seen low morale driven by unclear expectations and roles. I’ve always found that clarity is coupled with higher morale.”
Overall, I agree, there are bad RACI charts and there are good RACI charts. Bad RACIs have thousands of lines on an Excel spreadsheet, which is too many for the team to keep in mind, and/or are built by an outside consultant and handed over to the client and the team. Good RACIs are built by the teams who will use them, create a common language to understand role, are as simple as possible, and give teams clarity about who is going to do what. Good RACIs lead to clarity and collaboration.
Take the free Role Confusion Quiz to see if it would be helpful to clarify roles on your teams.