Do you need to adopt an Agile methodology like Scrum or SAFe?

Do you find yourself asking questions or making statements such as “Should we adopt an agile methodology?” “We need to use Scrum.” “We need to be agile.” “What agile methodology should we use?”

Even worse, are you talking to consultants and contractors who are telling you that you need to be agile, that SAFe (the Scaled Agile Framework) will make you agile, or you should start using Scrum?

Do you wonder whether you’ve completed an “agile transformation” or whether your “agile transformation” isn’t delivering the results those consultants promised? (Or do you wonder what an “agile transformation” even is or why you’d want one?)

First, if you’re just wondering “what is Agile?”, check out our introductory video "What is Agile?" here.

Otherwise, if you’re wondering whether an agile framework or agile methodology (like Scrum or SAFe) is something your team or company should consider, the good news that you are not alone, although the answer may not be quite what you expect.

The bad news is that, like nearly everyone else, you’re asking entirely the wrong question. In this article you'll learn a few things:

1. What actually matters in team (and organizational) performance.
2. Where agile methodologies fit (i.e. Scrum, SAFe, etc.) into #1 (and where they don’t).
3. How to make sense of this information and help teams maximize productivity – with or without the use of an agile framework.

Number 1: What actually matters.

Decades, literally decades, of research has been conducted on team, group, and organizational performance and behavior. The specific academic domain, if you’re interested, is industrial/organizational psychology. Two of the giants in this field, Eduardo Salas and Scott Tannenbaum, co-authored a book summarizing decades of their research into a highly readable text, Teams that Work: The Seven Drivers of Team Effectiveness (Oxford University Press, 2021).

At a supremely high level, the authors identify seven “drivers” of team effectiveness – the things that will ultimately determine how well a team is able to perform when working together.

These drivers encompass and categorize familiar tactical areas including individual KSAs (knowledge, skills, abilities), prior experience, psychological safety, trust, communication, self-belief, mission & vision, organizational rules, policies, leadership, regulations, process workflows, and a host of other factors.

Number 2: Where agile fits.

One of the seven drivers identified by Salas and Tannenbaum is called “Team Cognition.” Team Cognition includes sub-categories such as team member roles, priorities, mission or purpose (including “why”), and how the team will accomplish tasks (work process, cadence, working agreements, and so on).

We have mapped the components of most agile frameworks against the Seven Drivers of Team Effectiveness. For virtually all agile frameworks, notably Scrum (the most popular), the majority of their content, focus, and direction falls squarely under Team Cognition (what the roles on the team are, how they prioritize work, and what the process for task completion will be).

That is in no way bad! Team cognition is the "shared mental model" for how the team works and who does what. It has long been known to be a  performance effectiveness driver. However, it is also (alone) insufficient for team performance.

Which is why simply applying an agile methodology (such as Scrum or SAFe) does not result in high-performing teams. Just ask any of the hundreds of major enterprises who are now divesting themselves of anything relating to “agile.” Literally. Ask them.

The first reason that agile methodologies are insufficient is a matter of simple math. There are seven (7) drivers of team effectiveness. Virtually all of the framework guidance which is provided by agile methodologies falls under one of those seven, Team Cognition.

We can already see that we’re now only covering 14.2% of the problem area.

Yet there are eight sub-categories under Team Cognition, and guess what? Agile frameworks and methodologies, again, cover roughly five (5) of those eight (8). Let’s be generous and call it six (6) because a couple of minor points are debatable. Six (6) out of eight (8) means agile only addresses roughly 75% of the categories under Team Cognition. Therefore...

By adopting an agile framework or methodology, we are addressing 75% of Team Cognition, which itself accounts for only 14.2% of everything  in the team effectiveness drivers.

Which means, overall, we are only solving for 10.65% of the team effectiveness question.

If there is anyone out there who thinks addressing 10.65% of a problem is sufficient, please do not call us. Ever. (Sorry agilists, it doesn’t even meet the 80/20 rule, aka Pareto threshold.)

Number 3: Making sense of it (or, what to do).

The question you began with here was whether you should or should not adopt an agile process or framework. Let’s put that into perspective.

Imagine coming home after a long day at work and your spouse asking you whether you should rewire the electrical in the house. After all, the neighbors had their electrical system re-wired. You should probably do that, too, right? Right?!

You immediately begin researching the costs and benefits of electrical rewiring, looking for reputable electricians who specialize in residential house rewiring. You find and contact them, shocked to learn that they absolutely recommend rewiring your house! Without equivocation or even asking what problems you’re encountering. (No reason to suspect anything there!) They’re more than happy to come conduct assessments about how unwired or poorly wired your house is and provide cost estimates to rewire your house, just as you had asked! (Amazing!)

The only issue with anything so far is that we still don’t know why you would need to rewire your house, but let's ignore that for the time being.

The rewiring specialists can sure list off all the benefits of rewiring: new wires, shiny wires, better wires, better conductivity, more safety, better boxes, better switches, a smartphone app which will tell you when your wires are conducting electricity and when they aren’t (because you need to know that!), and perhaps the older wiring wasn’t done correctly? You don’t even have a “wiring mindset” or an “electrical mindset.” This new wiring will come with all the training needed to make sure you understand the value of the wiring you’re getting and how to best make use of the wiring and all that if has to offer! All. These. Benefits.

Nevermind that we still do not understand what problem we’re trying to solve.

We only know what solution we’re trying to implement. If the actual issue is that the roof is old and the shingles are damaged, new electrical wiring will not help. If the issue is that we have water seepage behind the walls causing mold, new electrical will not help.

I know, you get it. Make sure the “solution” is matched to the problem, right? How do we do that?

First, take some time to understand the problem from multiple perspectives (i.e., not just yours).

Seek input and feedback from peers, superiors, and subordinates (most importantly). Map the issues and challenges, the risks, and the current state. (Red Queen Consulting can help with planning and facilitation.)

Next, map the nature of the challenges and the options for change and improvement.

Consider, for example, analyzing different axes such as energy required for implementation versus impact of implementation, or energy versus time to implement, or impact versus time, risk versus impact/time, etc. Leverage a sense-making framework such as Cynefin to help you analyze and categorize different aspects or components of the problem. (If you are unfamiliar with Cynefin, download our free primer on Cynefin.)

Finally, based on your analysis and exploration, you can make informed decisions about pathways ahead.

Perhaps implementing an agile methodology actually would be more beneficial than your current work delivery process?

Or perhaps you’ll find that other optimizations (Lean, or traditional management) will deliver far greater benefit and cause less confusion for your people, teams, and organization (because trying to force a square peg into a round hole is frustrating for everyone involved).

Regardless of how you choose to proceed, best of all, you can now avoid solving for the 10.65% of the team performance problem, which you otherwise would have been. You are already better off!

How about two examples of how Red Queen Consulting actually puts this into practice? (Thought you'd never ask.)

(1) Client A was intent on adopting an agile framework to get moving on a major worksite relocation project which had been stalled for some time. The President, the project lead, and all the functional managers were frustrated. As we worked with them on discovery and analysis, our findings reflected that a few (relatively simple) challenges were creating the core of their issues, and that implementing an agile methodology would solve none of them.

Our early analysis of their challenge space identified the primary domain as Complicated. (Click here to download our primer on Cynefin, the sense-making framework we leverage to analyze, categorize, and make decisions.) The fundamental issues they faced began with effective teamwork and related issues which they had (thus far) failed to identify or address. Including:

1. No clear vision or mission for the initiative.
2. No clearly communicated leadership guidance, intent, or constraints.
3. No exploration or discovery of the problem space had been conducted.
4. No constraints (regulations, requirements, deadlines, tripwires, etc.) had been identified or communicated.
5. No planning horizons or epochs had been noted.
6. There was absolutely no way to visualize any work. Not even a cursory mapping exercise to sequence high-level events or work items existed.

Our basic recommendations were to:

1. Create a way to visualize the work, either physically or digitally. Everyone could go to one place to understand and update work required, priority, dependencies, and status.
2. Clearly define a mission/vision for the project overall and for project teams, identify known constraints, and communicate, communicate, communicate.
3. Hold a workshop enable the functional managers to identify work, collaborate, and develop sequencing based on the vision and previously identified constraints.
4. Create team plans and a team-of-teams plan to guide communication, collaboration, resolve inter-team functional ambiguities, allocate responsibilities, agree on decision-making mechanisms, and establish cadences to guide how often they would need to meet.
5. Meet to support updating (replanning) based on the rate of change in the work, the frequency of collaboration required, and to support both individual and collective execution by relating task status, emerging risks, and changes in the regulatory, legal, and/or political environment.

Our recommendations deliver on most of the seven drivers of team effectiveness and create an explicit, shared mental model for how the teams work and work together. A great deal of their work (such as building the new worksite) will be handled via traditional project management, as it is appropriate for construction projects and non-interdependent work sequencing (the Complicated domain).

Next, a challenge perfect for an agile approach...

(2) Client B planned to run an innovation lab to dedicate a single, multi-disciplinary, cross-functional team to try to solve an incredibly technically challenging problem (one the client had attempted to solve multiple times without success). Upon initial analysis, we identified their domain of work as Complex. (Click here to download our primer on Cynefin, the sense-making framework we leverage to analyze, categorize, and make decisions.)

We worked with the team and stakeholders to identify the overall objectives and constraints, and then developed an iterative, adaptive approach to organizing what the team would need, how to prepare the team for the work, how to help the team agree on how to work and determine the initial cadence the team would leverage to plan and prioritize tasks. Specifically,

1. We created a visual representation of the existing state of the challenge, including various technologies.
2. We identified the types of knowledge, skills, and experience team members and external-team resources (experts) would need to either work or guide the work of the team.
3. We explicitly including non-experts and novices, who would be helpful in exploring and challenging team thinking.
4. We chartered the team collectively, including a great deal of exploration and discussion around working values and principles, building trust and collective efficacy into the team from the beginning.
5. We iterated a way to visually manage the work, a critical need due to the team operating collocated at times and remote at times.
6. We agreed on an appropriate cadence to update, collaborate, and plan (or re-plan) work based on how often the situation and collective knowledge was expected to change.
7. We mapped potential solution pathways and areas for exploration, with associated constraints and system components to support investigation and updating as the team learned and moved through work.

The team from Client B is midway through their work and moving forward swiftly, with a number of extremely promising and novel ideas to pursue and will likely overdeliver on what was originally asked. They are performing exceedingly well.

What you should notice in the examples above is that at no time did we prescribe a framework, methodology, or solution to any team. We did not begin with “An agile methodology like Scrum will definitely solve your problem! Wait, I’m supposed to ask about your problem. Can you tell me about your problem?”

Instead, we focused on understanding the team's and company's problems, categorizing the work via a sense-making model (Cynefin), and applying techniques appropriate for the specific type of work while incorporating tools and methods which support team effectiveness in all types of work.

Returning to our foundational question of “do you need an agile methodology, an agile framework, or an agile project management approach?”, our answer is simple: it depends. (We’re consultants! Surely you saw that coming!)

Let the work guide you.

Just make sure you understand how to let the work guide you and be prepared for multiple types of approaches within your organization. If your company is of any appreciable size, you likely work on a lot of different types of problems, and those different problems potentially require significantly different approaches to maximize the success you encounter in solving them.

And remember that whatever solutions you implement, you need to address all of the factors comprising team performance, not just the 10.65%.

As always, we’re here to help.