top of page
Privatw Classes Landing Page_.jpg

Why isn't Agile Working for us?

State of Agile Report from Digital AI

Digital AI releases an annual State of Agile report, which includes a survey of how many teams are adopting Agile. In the 17th Annual State of Agile report, released in 2024, we saw that some organizations have taken a step back from Agile. Even with the clear benefits that Agility can bring to the organization, from delivering value sooner to reducing risk faster, some organizations are having trouble getting the full benefits of an Agile way of working.

agile adoption

Why is that?

First, I think it’s a reaction to the rapid adoption of Agile that we saw immediately after COVID-19. In 2020, we went from 37% of Software Development teams using Agile to 86% of Software Development teams using Agile. That is a huge spike and is almost certainly a result of so many teams going remote during COVID-19. In a remote environment, the transparency and collaboration fostered by an Agile approach to software development are even more important than in an in-person environment. When many companies returned to an in-person way of working, I believe they dropped Agile, which is why we saw a slight reduction in Agile adoption in 2023. But I think it’s also important to note that while we saw a step back in adoption in 2023, we did not go back to pre-Covid levels, which shows that most of those who adopted Agile are getting at least some benefits from it.


Secondly, I think many companies went Agile without understanding that to get the most out of Agile, organizations need to adopt a benefit mindset and move from a command-and-control approach to an approach that empowers teams to decide how best to approach their work. Organizations that did not focus on outcomes or embrace self-organization did not receive as much from their Agile transformations as those who did, and this may account for why some organizations have struggled with Agile and may be taking a (perhaps temporary) step back. 


In the following paragraphs, we will explore some of the ways that organizations - even with the best of intentions - can focus on the wrong things and actually slow value delivery by creating unnecessary dependencies that disempower teams and slow value delivery. By recognizing these symptoms, organizations struggling with Agile can find ways to more fully embrace the Agile mindset and the tenets of self-organization. Additionally, for those who took a step back from Agile, this article can help you recognize what may have gone wrong so that your Agile transformation can succeed when you are ready to try again.

corporate department scrum

Silos, silos, silos

This is by far the most common—and deadly—sin that I see in Agile transformations, especially large-scale Agile transformations. 


Here’s what happens. An organization decides to go agile. Great!  The first question that the organization generally asks is, what should my team structure look like? Many well-meaning organizations either go Agile along current reporting lines (e.g., my boss is XYZ, so our team will be an Agile team together) or worse, the organization decides that every team will specialize in a particular technology (e.g., we’ll have a Java team, a SQL team, a Reporting team, etc.) 


When organizations create silos based on specialization or reporting structure, they are often creating dependencies that slow value delivery. A better approach would be to take a step back and ask what Products we are trying to deliver, then build cross-functional teams to support those products.

Not focusing on outcomes.

If you are in a complex environment and Agile is not working for you, it could be because you are focusing on the wrong things. 


Agile is a state of mind. Yeah, it’s cheesy, but also, it’s really, really true. When an organization goes Agile, they need to focus on the customer outcomes rather than worrying so much about keeping everyone busy.

tickets and scrum

Now, you may be asking yourself, “Isn’t that the same thing? Don’t people need to be busy focusing on customer outcomes?” 


I hear you, but you’re missing the point.


When I measure success, what am I measuring? Am I measuring the number of features being built, or am I measuring how useful those features are to my customers? It’s a subtle - but vital - difference.

But it’s worse than that. It’s not just about measuring the wrong things. It’s about holding people accountable for the wrong things. We need to be focused on value, and instead, many organizations are focused on metrics that measure productivity. We are so wired to think that productivity is the most important thing. Productivity is, I guess, important, but what really matters is this: are we working on things that add value? It doesn’t matter how busy we are if we are working on the wrong things. Rather than being obsessed with ensuring everyone is busy, we need to consider whether we are working on things that add value. 


This all goes back to mindset. We must understand that Agile is used in complex environments where less is known than unknown. In complex environments, it isn’t clear what the highest value work is, so we need to measure results and outcomes instead of focusing so much on productivity.

Disempowering the Product Owner

I once worked with an organization that was concerned because their Agile teams were not delivering the value that they expected. “The Agile team just isn’t delivering,” they said.


And it was true, it did seem that the Agile team was not delivering much value for the size of the team. But when we dug in, we found out that 80% of the work being delivered by the Scrum team was random work requested by people who were going around the Product Owner. These same people were really in a pickle because the Product Owner could not deliver against their roadmap so they could never get anything done. So, they went around the Product Owner and directly to the developer to get their work done.

product goal

Do you see how this is a self-defeating approach? 


The Product Owner is accountable for maximizing the value of the Product. This can sometimes mean saying “no” to low-value work so that we can say “yes” to high-value work. 


But when everyone thinks their work is the most important, the Scrum team is pulled in 1000 different directions, and nothing gets done.


I have to say it. The way companies are adopting SAFe is a problem. SAFe makes it too easy for organizations to enshrine dependencies in their team structures, which slows value delivery. Organizations—with the best of intentions—are adopting rigid, overly siloed structures for their Agile teams and then wonder why they don’t get the speed and flexibility that Agile promises. 


Think of it like this. When we used to run projects, we would bring together team members with different skills to get something done. The same thing needs to happen with Agile teams. But instead, companies think that they can adopt SAFe and then silo their teams and put up barriers to their working together and then solve those barriers with a quarterly PI planning meeting.


It doesn’t work.

What can you do instead?

Adopt Agile. Adopt a mindset of bringing people together with different skill sets and empowering them to get the job done. Take a step back and ask yourself: what are our products? Then, bring together a team with all of the skills necessary to deliver those products. If more than 3 Scrum teams are working together on a single product, adopt Nexus. Contact Rebel Scrum for help adopting a simple approach that unleashes your team’s ability to deliver value.

It's not a coincidence!

Consider this. According to the latest State of Agile report, large companies are twice as likely to adopt SAFe as smaller organizations. At the same time, larger organizations are more likely to report dissatisfaction with Agile and see barriers to adoption. 


I don’t think that’s a coincidence.


SAFe lets consultants sell expensive agile implementations and allows Executives the comfort of a command-and-control structure. 


However, command-and-control does not work in complex environments. We’ve known this for a long time. In the 1986 Harvard Business Review article “The New New Product Development Game,” the authors discussed how, in complex environments, we need to bring together people with different skills and give them goals, not tasks. SAFe makes it too easy to ignore that advice.

bottom of page