Is it time for Agile to become agile again?

The Agile Transformation has become a mantra that nobody questions anymore. Everything must become agile, quick and flexible. The whole world is so enthusiastic with agile methods that no one questions whether they are always the right answer for everything.

The essence of agility lies in reevaluating current systems and conventions. As a fan of this approach, I believe it should also apply to agile methods when they become the established systems and conventions.

Software has eaten the world

In 2011, software developer and investor Marc Andreessen declared in a widely cited Wall Street Journal article that software would "eat the world." He declared that software companies would become increasingly dominant players in almost every sector of the economy, displacing or transforming traditional companies. He predicted that most business activities would be influenced or controlled by software, highlighting IT's central role in the future economy.

Soon Mark Zuckerberg's "Move fast and break things" became the order of the day. It was all about acting quickly, trying out new ideas, and accepting the risk of mistakes to create disruptive products and rapidly advance technological progress. The foundation of this development is agile.

Particularly in the context of "Lean Startup" and "Rapid Prototyping," agile has become invaluable. Like no other project management approach before, it enabled the rapid development of prototypes and learning from user feedback, fostering efficient product development and improvement, which are crucial for startups and innovative projects.

To put the quotes in a common metaphor: While Andreessen's "Software will eat the world" describes the process of eating itself, Zuckerberg's "Move fast and break things" is about biting and gulping down (market shares).

Digestive Problems

Today, about a decade later, IT plays a central role in value creation. The vision has become reality, software has eaten the world. Moreover, it has digested it and pooped out a new world. And that is the world we live in today.

But in this new world, swallowing things quickly is not the only job anymore. It's also all about properly digesting things, processing nutrients, excreting toxins, and - most importantly - avoiding stomach pain and diarrhea.

Agile has become the status quo

Agile project management methods are no longer anything special today: 94% of companies report that they practice agile today. Agile is now the norm. The new status quo. And in some cases, the reason for pain, as agile also have its downsides:

Once software, projects, products, and companies reach a certain maturity level, less agility and quick adjustments are needed, and instead, safety and especially stability become more important.

In software development, you can easily recognize this maturity level: The number or effort to implement Non-functional Requirements (NFRs) exceeds the number of functional requirements (FRs). While functional requirements (FRs) define what a system should do, non-functional requirements (NFRs) describe how the system should perform its functions by defining quality attributes like stability, performance, and security. In DevOps-teams, you can recognize this maturity level by the fact that no longer the developers call the shots, but the ops-guys.

In recent years, you could observe that multiple teams working together in a scaled agile framework like SAFe or Nexus, with a focus on operations or NFRs, function particularly well when they cooperate closely with each other and plan their steps next carefully. If this sounds familiar, you are probably not a millennial, because many millennials have never known the old waterfall world, like PRINCE II.

If all you have is a hammer, everything looks like a nail.

Despite the notion that agility is the answer to everything, I believe that some organizations and projects "force" agility where it doesn't fit. In some cases, the company, its products, projects, or the environment simply aren't good candidates for agile anymore.

In its basic form, agile is about testing assumptions in small steps to reduce risks and accelerate the learning cycle so that they can learn what to do next. This approach is not suitable for everyone and every situation - especially when the main priority is stability.

The skilled handyman knows: "If all you have is a hammer, everything looks like a nail." In other words, you should avoid an over-reliance on a familiar or favorite tool. While a tools can be very useful at times, over-reliance can result in approaching problems in ways that are not always helpful or even destructive.

Therefore, here are some considerations that you should make when it comes to whether/when you might need to change tools/methods:

• Clear phases and dependencies: The waterfall model follows a sequential approach, where each phase (such as requirements analysis, design, implementation, testing, deployment, and maintenance) must be completed before the next begins. This can be advantageous in complex projects with many dependencies between teams, as it helps identify and prevent overlaps and inconsistencies in advance.
• Focus on comprehensive planning and design: In a waterfall-oriented model, great emphasis is placed on the initial phases of planning and design. This can ensure that all teams have a clear understanding of the requirements and project scope before development begins. Such comprehensive planning can reduce the likelihood of changes and revisions in later phases, which can improve the stability of the software.
• Risk management: The waterfall model allows for early identification and management of risks, as the sequential nature of the model means that issues must be identified before moving to the next step. This can be particularly beneficial in the development of stable software, as it allows for addressing potential issues before they affect downstream processes.
• Simpler integration and testing: In projects involving many teams, integrating various components or modules can be challenging. The waterfall model can simplify this integration by providing dedicated phases for testing and quality control before the software is rolled out. This can help enhance the stability and reliability of the end products.
• Avoiding continuous changes: Agile methods like Scrum promote adaptability and rapid iterations, which can be advantageous in a dynamic project environment. However, in contexts where stability and predictability are crucial, this can lead to challenges. The waterfall model reduces the frequency of changes, which promotes stability.
• Clearly defined milestones and delivery dates: The waterfall model places great importance on clearly defined milestones and delivery dates, which can aid in coordination and management in a large project with many teams. This can increase transparency and accountability in the project.

It is important to emphasize that the success of such a transition strongly depends on the specific project environment, objectives, and the capabilities of the teams. In most cases, a combination of agile and waterfall elements (a so-called hybrid approach) can optimally utilize the benefits of both methodologies and thus contribute to stable and efficient software development.

In any case, it is essential to regularly question whether the right tool is indeed being used for the right task, as this too is agile.