Because campaigns have to be planned ahead too - anywhere between a few weeks and a year or so, depending on the size of the project and the company, and often timed to match big trade events.

And there's always the possibility that if you announce too late competitors will eat your lunch.

One way to handle this is to spend some time on a formal estimate. Two to four weeks of R&D to scope a project can help narrow estimates to something approaching realism. You'll still be wrong, but you're less likely to be hopelessly wrong.

Asking someone for an instant opinion is madness. That's not an informed estimate, it's just a guess, and usually worthless.

Sounds like marketing needs to be agile

Because if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.

This. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule.

That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has committed itself and they have no real choice but to work with the sliding deadlines?

In the example I'm thinking of the partner wasn't really bothered that the schedule slipped, but the ideal marketing window came and went before the product officially launched, which certainly affected sales. They were really excited that all the planned features made it to market though.

I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day.

> the ideal marketing window came and went before the product officially launched, which certainly affected sales.

Definitely. I used to see that all the time in the games industry. Getting the right launch window is critical because most of a game's sales happen in the first few days of launch. And yet, games are famous for shipping months, even years late. They usually seem to make it work. I guess you'd be particularly hosed if you couldn't afford the burn rate for the extra X months it would take to get to a decent launch window.

Lots of reasons:

1. Marketing management is full of idiots.

2. The coder's estimate is used to tell the CEO when a product will be rolled out. Who then questions why it didn't get rolled out on time.

3. Marketing gets a bonus for rolling out ad campaigns on time.

4. Marketing is using this for their big trade show coming up and wants to make a big announcement for maximum impact.

Why do you assume management is always competent?

I think this comes down to the idea that estimates are really for coordination.

At least, I think that’s the best reason for using estimates. I wrote something about this here: https://riskfirst.org/Estimates

Actually I don’t really understand why all the HN posts on agile just devolve into a discussion about the difficulty of estimating.

Surely there’s more to it than that?

Well, standup is also terrible. In addition, there's the general agile assumption that developers are capable of consistently producing X hours of work per day. Maybe it's just me, but I'm a bit more burst-y with my work habits than that.

I wouldn’t say Standup is terrible but one where you go round the room giving updates is almost useless. It’s not just you, most developers can do 8 hours work in an hour if they aren’t interrupted with meetings.

Shouldn’t it average out over 2 weeks?

Not if you're doing standup every day and expected to report daily progress.

Because the superbowl comes once a year -- seasonality matters!