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?