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

"Oh, feature no 32 is going to take months and we realised that users can just...."

"No"

magicalhippo 2 days ago | parent | next [-]

> "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 2 days ago | parent | next [-]

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 2 days ago | parent | next [-]

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 2 days ago \| parent [-]
		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 2 days ago | parent | prev [-]

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 2 days ago | parent | prev [-]

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 2 days ago \| parent [-]
		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.

▲

mytailorisrich 2 days ago | parent | prev [-]

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

That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.

▲

t43562 2 days ago | parent [-]

Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not.

Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.

	▲	mytailorisrich 2 days ago \| parent [-]
		Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.