Hacker News new | past | comments | ask | show | jobs | submit login

Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybrid waterfall/sprint methodology that mostly worked fine, but i suspect that was more to with the general culture and people involved than anything else.



I think no industry producing anything new ever found a working process to predict and keep the timeline. (If omniscience really existed, it would have more lucrative applications.)

Developing new aircraft, building a new ship, building a custom-designed bridge (most of them are) are processes that often run out of time and / or budget.

If you want predictability, you want repeatability. But in software all reliably repeatable parts become automated away.


Absolutely. And I'd add that predictability is dependent upon not learning anything over the course of the project. To be predictable either you know everything that matters up front (which is only true for trivial projects with no competitors) or you refuse to learn anything along the way (with, e.g., a big-bang release at the end).

But I think good projects release early and often precisely so that they can learn as they go. At which point predictability goes out the window.


? All the specified above endavours - usually run into what one could call the end of the map. Here be science! If you run into e.g. new material science because your goal stretched beyond the scope of what has been done previously, you can blame the engineer for not telling you that you will leave the boundary of the knowledge of a field- you can not blame him for the estimates beeing wrong.


Nope, never.

I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the distinction.


> "it should almost never take longer than that" vs. "it will probably take that long."

This sounds like a much better way to estimate. Do you have any links to content discussing this?


Here's an article that explains the phenomenon much better than I can. It made its rounds in HN a week or two ago: https://erikbern.com/2019/04/15/why-software-projects-take-l...

I haven't seen a good way to turn the concept of "it should almost never take longer than that" into a concrete process. I've always seen it as a gut check, often implemented as "take your initial estimate and double/triple it." What I actually see is that a lot of teams implement that but walk back the doubling when the business/PM delegation persistently asks for more in less time. Only in really engineer driven cultures have I seen engineering teams successfully push back.


On the actual use and calibration of confidence intervals - https://www.lesswrong.com/posts/ybYBCK9D7MZCcdArB/how-to-mea...


AFAIC, the only thing that works with a fixed deadline is a variable scope. Which is basically a tenet of Agile.

The alternative is some sort of sub-iteration hybrid where you attempt to fix deadlines for much smaller units of work and constantly revise.

This is OK for some industries. But 2/3rds of a car doesn't quite sell...


One thing about agile is that usually companies not only set fixed deadlines but also fixed feature set; which usually means lower quality.

That in turn means technical debt; which puts future deadlines and feature sets at risk.

Since in SCRUM as a team you try to not compromise on quality the only way out of this is to push back on deadlines or feature set (or both).

So instead of blindly executing orders; the development teams can push back on deadlines.

Most of the time these are actually negotiable. Even the "hard" deadlines....

It doesnt mean the dev teams always win however they are better equipped to inform "management" about the consequence of the deadline.


Exactly. Probably 90% of the burden on a successful agile project is in setting expectations with stakeholders for an iterative delivery without a fixed scope. It can be a tough sell but it shouldn't be. If you've ever done a top line estimate on a fixed scope project, you know it's just absolutely not possible. Why set a deadline you know with 100% certainty you're not going to hit? Just bake it into the contract and upfront expectations.


Yes, absolutely. Many times. I've done a bunch of projects that were tied to immovable event dates. The only way to deal with it is having very flexible scope. Typically, these have been more "creative" projects and not tied to a lot of critical functionality so we just make sure we keep our MVP quite small and treat everything else as iterative enhancements so we can cut off whenever we're out of time and still have something presentable.


DHH has a nice methodology that works with fixed deadlines: his basic rule is that features can be dropped/simplified, but deadlines must be met.

https://www.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/00628747...


He's applying an old concept. The Iron Triangle has been in use since the 1950s.

https://en.wikipedia.org/wiki/Project_management_triangle

If time is fixed, then scope and/or cost must change.


This is true, but fixing the deadline and not committing to the scope requires clear communication by the project management / sales teams with the clients about it, and this is rare.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: