This myth can be seen in several different ways. When people talk about it they generally mean one of two different things, which I will address here.
"There are no deadlines in Agile, the only promise you get is that things will be done when they are done."
This can be both true and untrue depending on the context you are in, you can choose if you want to work with deadlines or not. Many teams and organisation practice a system of continuous delivery, meaning, as each feature is completed it is released directly to production. In this context, most choose not to set deadlines, as they are rendered quite moot by the pace at which you are delivering. But, this is a choice that is made, not something forced by Agile to be the case.
A common situation where you might choose to do this is when delivering tools internally to your organisation. In this context you may not require marketing, training or other activities that can slow a release process, your organisation wants the things you are building as quickly as they can get them. No need to batch them together, so very little need to set deadlines either.
But, what if you deliver to a more traditional market place? A consumer product for example. In this case you may want to batch features together and practice a traditional release model once or twice a year, so you can coordinate marketing and sales activities around these releases, this is perfectly possible with Agile.
If we take Scrum as an example. Scrum not only has deadlines, it has a lot of them, many more so than traditional gated software delivery models. Scrum works inside of time-boxes which it calls Sprints, which can be anywhere from 1-4 weeks in length. The outcome of every Sprint is what is called "The Increment", or as some like to call it "The Potentially Shippable Increment". The increment is a fully functional piece of our product that we can choose to release or not. So in Scrum we not only have deadlines, we have them constantly. We have deadlines as often as every week, and as "rarely" as every month.
This not only helps us to ensure that we are on track, it makes it so we can easily move up release dates if we want to, it allows us much more flexibility than a gated model that doesn't deliver anything until then end of the project.
So, if you want to set a deadline for release, go right ahead! If you want a release every 6 months, you can get everything that can be built in 24-6 Sprints of production.
This brings us to the second part of the myth:
"Agile is too unpredictable, we are not able to fix time, scope, and cost in an Agile project. Basically, we have no idea what will be delivered in 6 months time."Once again, this is both true and untrue. Just as before, a choice you can make for yourself.
One of the main benefits of Agility, and really the whole point, is to provide us with flexibility. We want to create an environment where scope does not need to be fixed if we don't want it to be, we want to create an environment where it is not only possible for our customer to change their minds but where they are encouraged to do so! This allows them to adapt to changes as they occur like the market, technology, and their needs. If commitments are only made for the duration of a Sprint, we are free to adapt to changing conditions as much as we need to outside the Sprint, and if they change so rapidly that we can't even wait the length of a Sprint, then all we lose is at most a few weeks work, instead of 6 months worth.
On the subject of fixing the other two variables (time and cost), well, they are always fixed. Time is the length of a Sprint or however many we choose to include in that release. Cost is fixed because we know exactly how much a Sprint costs.
But, let's say you choose to fix all of those variables. Scrum supports that as well, but a bit more subtly.
Software projects are notoriously hard to predict. They frequently come in over budget, late, and to a low degree of quality. Our approach to this has always been to spend time and money at the start of the project trying to define exactly what we need, so we can predict when it can be delivered. Basically, we are trying to remove the flexibility in favour of predictability.
You can of course choose to do this in an Agile project, although you are giving up one of the biggest benefits of Agility in doing so. Scrum is not only able to supports this option, but, it is able to mitigate the risk in doing it much more effectively than a gated model. Since we are delivering at most every month, we will actually know if we are behind schedule at the end of the very first Sprint, instead of at the end of the project! Isn't that more useful?
Agile teams actually focus very heavily on their ability to create a stable velocity for their production, and are therefore actually able to predict their outcomes far more accurately than other teams. But, this is only possible over time in an Agile project, so if you are just starting there is an inherent unpredictability. But this no different from other project models, it is simply made more visible in Agile projects because our goal is to make it more visible, so that decisions can always be made with the most information possible.
In summaryYou are able to choose how you want your organisation to work, depending on your specific situation, and be confident that you always have a clear picture of the current status. This allows you to focus on what is most important to your business, be it flexibility, or predictability with the mitigation of risk.
I am calling this myth busted!