Strict Adherence to Agile Is Actually Not Very Agile

“Agile” has been a buzzword for quite a while. Teams work Agile. Modern management is Agile. Using an Agile framework to reorganize classic production processes is a big initiative at a lot of companies these days. Somehow, everything is Agile – and, as always, when a trend reaches its peak, we have to ask ourselves: How much of this is hype and how much of it is substance? At Meisterplan, we also have teams who work Agile, and our conclusion is that Agile is a great option, but strictly adhering to the method is too inflexible and just doesn’t make sense.

Why Did Agile Become So Successful?

The traditional waterfall model, with its milestones, deadlines, and resource plans, often generates complex project plans that everyone knows aren’t realistic, even before they start. No project plan survives first contact with the real world anyway, so it’s important to have a plan that is adaptable. Additionally, the waterfall model is based on the idea that a project’s goal is known from the beginning and that we can start by assessing what we need to do to achieve that goal. In reality, these assumptions are often, at best, educated guesses, and, at worst, complete nonsense. As a result, project managers continue to lose sleep as they fall more and more behind on their project plans. They are always waiting for the other shoe to drop, knowing that they’ll have to explain the inevitable delays and missed deadlines. The Agile framework won’t help with these specific problems but it serves to address the larger problem of how to get work done quickly and efficiently. The Agile team will explain, “We don’t know what the end product looks like and we have no idea how to get there, so nobody can say exactly when it will be done. We work Agile, baby. Deadlines are so 90’s.”

Not only is this openness and flexibility liberating for teams, but these teams often show that with this more flexible framework they can produce better and cheaper products and deliver them faster. And that’s something that gets management’s attention.

So, Agile All the Way?

That would mean everything is faster, cheaper and better? Get rid of waterfall and use the Agile framework from here on out. End blog post.

…OK, maybe it’s not that simple.

No One-Size-Fits-All Solution

Agile is great for certain situations. For example:

We don’t always know what the final product is going to look like.

It is not always clear at the beginning of a project what its goal is. Often the design of a new product involves multiple teams working independently on different pieces. And often those independent teams identify areas where they can improve the product with changes but those changes have implications for what the other teams need to deliver. Agile teams can quickly react to these updates and adapt their deliverables to integrate all of these changes from the other teams. This adaptability is key to delivering the best product in the shortest amount of time, which is the ultimate goal of Agile teams. Uncertainty is not only OK but it’s expected. Accepting this uncertainty and maintaining adaptability also gives teams the opportunity to more directly involve the customer in the development process so they can get real-time feedback. This ultimately results in a product that makes customers happier. And happier customers are what we all want in the end.

We don’t know how to get there.

Even if the end product can be clearly described, the path to delivering that product is not always clear. Perhaps right from the start, the project will present unexpected challenges to a team. Rather than having to stick to a prescribed plan, Agile teams are able to evaluate the challenges as they see them and adapt accordingly.

Regardless of the reason, if the path to completion is more like a labyrinth than a straight line, the Agile method is probably the better choice.

We don’t know when the project will be finished.

This is a direct result of the first two points. If the end result and delivery method aren’t yet defined, then it’s logical that a completion date is also impossible to define. For teams that work like this, strict deadlines are not only impossible to estimate but they are counterproductive.

Looking at these points, it is no surprise that Agile work first became popular in the software industry. What would be seen as additional challenges in many other industries have long been the norm in software development. For example, when working on some software projects, at the beginning you may not be sure about which devices or operating systems your solutions will support. And it isn’t obvious which bugs you’ll need to fix on the way to delivering your product. But those answers become apparent as the project progresses. However, not all projects in all sectors are subject to the uncertainties of software development. If your project is to build, for example, a prefabricated model of a physical product, you probably have a very good idea of what you need to do. And even in software development, there are projects where it is actually very clear what needs to be done from the beginning, so it’s easy to define when and how long that will take. Of course, you could still use Agile for those projects, but … what is the advantage? Especially when you consider that the waterfall model with its concrete planning and clearly communicated deadlines also has advantages. Should we avoid those advantages just to be 100% Agile?

The Solution: Let the Teams Decide

So what we’ve learned is that Agile works better for some projects and more traditional approaches, like waterfall, can make more sense for others. But who should decide how their teams should work?

Our tip: Management should be flexible enough to leave this decision to the teams that are actually working on the projects. Ultimately, delivering a successful project is what matters, not how that success is achieved. Instead of forcing teams into a specific project management methodology, management should be able to support both Agile and non-Agile teams with their plans. Management decides what work needs to be done and the teams decide how it will be delivered. We have written in detail (e.g., here and here) on how this can be done, so I’ll summarize: 1) This is much easier than it sounds and 2) We recommend using Lean PPM™ as the framework.

Agile Religion

So far this all sounds very pragmatic. However, there is a problem. The age of Agile Project Management did not start with a simple “how-to” guide, but instead with a manifesto. Agile is not just an alternative way to manage projects, but also, at least for some, an alternative to outdated hierarchies and a stagnant corporate culture. Agile has developed its own, quite arcane, language as well as its own rules, leading to many arguments about why Agile is better than any other project management method. From this perspective, Agile seems like more than just a project management method; it becomes a conviction, a way of life. Agile sometimes has an almost cult-like following. Leave the dreaded, sinful deadline behind you and enter the heavenly realm of the flexible working world of tomorrow. All projects will now be Agile, because it’s just better. Some companies are now all Agile, because they’ve been told it’s the future and they don’t want to be left behind.

We think teams that use Agile are great, but we also think that strict adherence to Agile in every project or situation is the wrong way to work Agile. Ironically, strict adherence to Agile isn’t very “Agile” in the true sense of the word.

Bragging Rights…

We’ll be totally honest here. At Meisterplan, we have at least 10 different tools that we use across our teams. We have Agile teams and teams who use traditional project management methods and some people who just do it – without a project. And that’s good. That’s almost the maximum amount of freedom! Continuing our metaphor of Agile as a cult, which believes there is only one acceptable way, then Meisterplan is like a non-denominational congregation that includes many members who believe in many ways to successfully deliver results.

Does that sound chaotic? It isn‘t! We just practice what we preach. We separate the questions “What do we do?” and “How do we do that?”. We believe we don‘t have to tell the teams how to answer the second question in order to answer the first one. The only thing the teams “owe” to management for this freedom is to participate in the planning process (Lean PPM™) at the set times. For planning, we use Meisterplan (surprise!), which allows us to visualize all current work in a portfolio view, regardless of whether the teams are Agile or not. That way, we can create a portfolio that fits our strategic goals – and the teams always know how they fit in with the overall business strategy. This works great for us and we think it can help all businesses, including yours!

Our conclusion: Agile is a great tool but Agile for everything is simply… not Agile.