0

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?

  • 1
    Why does your manager need a deadline? – Euphoric May 28 at 5:16
  • "4x" is only applicable in the early stages of the estimation process. As you get further in, you should be reducing that factor. Break your 5 month task down and work out where the risk is. – Philip Kendall May 28 at 5:43
  • 2
    If you have a laundry list of features to deliver by the end of the year, that's not agility. You need to be validating those feature ideas through user research and prioritising the highest value tasks so that, however much work it turns out you can get done by the deadline, you did the work that was most important to end users. It's also worth understanding why there's a deadline. – jonrsharpe May 28 at 6:50
  • Before that -no way-, make sure you have solid arguments to ground your position which, on the other hand, is going to be (often) pessimistic regardless of the estimations and deadlines. A different way to approach your manager is saying by December 1, 2019, we could have done A, B and C but I don't see possible D and E because of ... This might help you to rearrange priorities so that by the deadline you could provide with perception of "almost done" rather than still left to many important things to do. Basically, you have to manage expectations so do it sooner as possible. – Laiv May 28 at 10:44
3

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" ;)

0

If your professional reaction to the dead line is "no way" you need to say that now not later.

Agile does absolutely nothing to speed up your work. All it will do is let you show management how far behind you are.

Agile provides management with two things. The ability to provide feedback early to tweak requirements and to see progress. Don't expect it to make you faster.

If you have a better idea than management when you will be done let them know now.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.