Q:

Estimates, deadlines and milestone

I am currently learning agile with a focus on project planning. I am having some issues aligning the teachings to the real world.
With agile I have learned, that we need to get customer feedback in every iteration, and we should include this customer feedback into our backlog so it is address, and we give the customer what they want. Secondly there is the cone of uncertainty, which says that my estimates can be 4 times higher or less. This all seems fine but it makes it very hard for me to figure out how I should report on the project.
Let’s take an example from a project that I am currently working on the currently projects completion data is 5 months from now. With the cone of uncertainty the means it will take between 1.25 and 20 months to finish. With a hard deadline of December 1, 2019, should I tell my management no way! I can first have this done Jan 2021? 

A:

I am currently learning agile 

With respect, I'd suggest that you haven't got very far with that learning process. "Agile" is an adjective; not a noun. So you are learning agile techniques, or agile planning etc. You can no more "learn agile" than you can "learn sparkly" or "learn hot".

Let’s take an example from a project that I am currently working on the currently projects completion data is 5 months from now

Regardless of what process you are using to deliver a project, you cannot escape the "project management triangle" of scope, cost and quality. The moment you specify a deadline, the only way you can guarantee to meet that deadline is by compromising on one of the three corners of the triangle. You can spend vast amount of money on extra staff (though beware the mythical man month, often expressed as "you cannot employ nine women to deliver you a baby in one month"). You can cut right back on quality and release a bug-filled mess. Or you can release with less completed features.
The purpose of using an agile approach of frequent iterations, each of which is a theoretically releasable product is that you bring that triangle under more control. As you progress toward that deadline, you are always in a state of release-readiness, quality is kept high and costs are better monitored. You sacrifice large-scale scope always, but have frequent measures of the pressures on that scope that you can report to management.
Just beware them saying "what are you going to about it?" though when reporting on less than 100% delivery to their deadline. You can stand firm and insist that you'll deliver what's completed by that point in a robust fashion without compromising quality. Their only other option is to ask you to ramp up costs and cut quality so make sure they understand that that is what they are asking for if they want all the features by their deadline.

Secondly there is the cone of uncertainty...

The cone of uncertainty is related to the size of the backlog of work. The bigger the backlog, the greater the uncertainty. By breaking the work done into a series of iterations, you massively reduce that uncertainty ... for the current iteration. Each iteration is only tackling a small scope and so has a lower uncertainty. What such an agile approach doesn't do is magically remove the cone of uncertainty for the entire scope. That is why the logical next step after shifting projects over to an iterative process is to release after each iteration. That way the whole nonsense of large scope (not being) delivered in the distant future goes away. You have a series of smaller scopes with less risk and uncertainty that often can be delivered on time and the priorities of what goes in future releases is free to change after each short iteration and release.
And when you get to that point, you really will have "learnt agile" ;) 

