[magicalhippo]

> "You're going to do agile .... and this list of features will be ready on September 20th."

Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then.

We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.

[ezekiel68]

It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"

[operatingthetan]

In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.

[magicalhippo]

That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable.

This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.

[magicalhippo]

Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.

If the org focuses on the customers one can work together to find a way.

[t43562]

What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.

When there's a time constraint one has to be able to winnow out the real must-haves from everything else.

[magicalhippo]

Right, that's deadly. We try to do small refactorings when we can, but for hard deadlines everyone is reminded to keep their focus on what's required for go-live. And if it starts to slip, one has to be dynamic and be ready to search alternate, perhaps temporary, solutions.