The case against Agile: Why it may be time to stop “playing it SAFe”

During the past two years, IT budgets have ballooned as COVID-19 accelerated and emphasized the need for digital experiences. But now, as the economy cools and the labor market weathers waves of disruption, inflated IT budgets are under scrutiny, especially when it comes to Agile delivery.

Companies that went “all in” on Agile are now facing tough questions about the value of the model: Is the added cost worth the incremental benefit the organization is receiving – assuming they can quantify it at all? Is the model enabling teams to “fail fast” – or just spend faster? Is Agile adding value – or just introducing complexity?

But here’s the catch: Even if companies aren’t getting the return they expected from Agile, most aren’t convinced there’s a better option available. Purists will have you believe there are only two real choices: 1. Revert to Waterfall – and suffer the 6-8 month release cycle that falls dramatically short of meeting the needs of the modern landscape; or 2. Adapt the Agile approach to add more agility – but inadvertently introduce more complexity, overhead and constraints within the environment.

In fact, there’s a third option – one that most companies skipped over the first time around and are still ignoring today: The Iterative Model. In this post, I break down what the Iterative Development model is, how it compares to other development models, why companies have overlooked it in the past and, more importantly, why they shouldn’t in today’s environment. ?

Why Agile isn’t working

The main premise of Agile is that small teams operate in a semi-autonomous way to enable continuous software delivery. In its purest form, each Agile team works as a single, independent unit: They sit together, work together, and trouble shoot together. They fail and flourish as a team.

But in reality, unless you are a pure-play software company, this is not how the IT function operates. Teams are distributed; a variety of partners are engaged; business leads are not closely integrated with software development teams; and companies lack the capabilities and infrastructure to support this model. It would take a virtually limitless budget and a complete restructuring of the IT team for most traditional enterprise organizations to deliver on the promise of Agile in its highest form.

Why you shouldn’t “play it SAFe”

To help make Agile work better, new approaches such as SAFe were created. The Scaled Agile Framework, or SAFe, attempts to solve some of the issues with Agile by overlaying new processes and contingencies on top of the model. This allows organizations to draw out some of the benefits of the model in a distributed enterprise environment. However, this added process layer also has a tendency to introduce new levels of complexity and cost.

For example, one of the hallmarks of SAFe is quarterly planning intervals (PI). As part of this process, organizations will outline, prioritize and assign all work that is expected to occur in the coming three months. The issue is that steps like PI add more complexity to the environment, creates more overhead and introduces more constraints that ultimately decrease flexibility and velocity. At the same time, it also requires substantial changes to the way that most organizations work and how they are structured.

Ultimately, even with these adjustments, the SAFe model still doesn’t deliver any better on the promise of Agile to enable “early and continuous delivery of valuable software.”

The question we really should be asking: Is Agile the best choice for your business?

The common issue in both the pure Agile model and SAFe is that early and continuous software delivery is usually not the main priority for enterprise organizations. Unless the business is a pure-play software company, an organization’s core business is not developing software – it is keeping grocery store shelves stocked, or production lines running, or electricity flowing, or any number of other functions that serve a purpose in society.

To be clear, software has an important role to play in helping companies of all kinds reach their objectives. But these organizations cannot lose sight of their main business, especially as they grapple with issues like inflation, workforce shortages and supply chain disruptions, all of which are making it harder for them to operate. In these cases, supporting a continuous software delivery model can take up valuable resources – resources that would likely be better spent serving the company’s core business.

Further, for many enterprise organizations, many development projects involve updates to existing sites, apps and other assets. Generally speaking, these projects do not need to be executed on a continuous basis. In fact, I would argue that fast releases for many of these companies have the opposite effect: Software becomes harder to support; users have the potential to be confused; and the experience can be eroded by releasing sub-optimal features. In such cases, the incremental benefits of Agile or SAFe typically do not justify the cost and complexity of continuous releases.

All of these issues contribute to why Agile – whether pure or SAFe – doesn’t really make sense for most non-software organizations and why the effort in continuing to try to make it work is the wrong goal.

Finding an alternative to Agile: A closer look at Iterative Development

The silver lining in this situation is that there are ways to build effective software development organizations without following a pure Agile model or SAFe framework – a prime example being the Iterative Model. ?

Iterative is a software development model that breaks down the development process into small pieces, or “iterations.” Like Agile, each iteration represents a distinct component of the development cycle – planning, design, building or testing. However, unlike Agile, Iterative does not require massive restructuring to the existing IT team or substantial changes to the way work is done.

Iterative often gets overlooked by many IT teams because people write it off as another name for Waterfall. But it’s not. And when it is implemented correctly, it can deliver a comparable level of value as Agile, with far less cost and complexity.

To illustrate this point, I’ve developed the below table which highlights the main differentiators of the Iterative model as compared to Waterfall and SAFe. (The reason why I chose SAFe, as opposed to pure Agile is because, as discussed above, for most large, non-software organizations, Agile in its highest form is impractical, unattainable or both. In this context, SAFe is a better and, frankly, more honest standard for comparison.)

The final word on Iterative

For many organizations, the shift to Agile was all about improving execution. But as some companies have come to realize, the model hasn’t quite lived up to its potential. As IT teams face growing scrutiny over the return on their investment and face mounting pressure to meet a host of new business commitments, now may be a good time to rethink the commitment to Agile.

At the same time, it’s important to realize that walking away from Agile doesn’t necessarily mean taking a step back in terms of speed or performance. When implemented correctly, the Iterative model offers enterprise organizations the ability to seize many of the benefits of rapid delivery, with far less cost and complexity. That leaves us with a new question: Is it time for IT teams to stop overlooking the Iterative Development model?

Want to discuss what development model makes sense for your business? Contact me, Scott TumSuden , to set up a 1:1 with our business team at 高知特 Cognizant and learn more about your company’s software goals and needs.?