Agile Software Development Against A Date You Cannot Move

We had a regulatory deadline eighteen months out. It was not negotiable, it was not going to slip, and the penalty for missing it was a matter of public record.

Every piece of advice available assumed the date was a variable. Here is how we ran Agile Software Development against one that was not.

Fixed Date Does Not Mean Fixed Scope

The distinction that made it possible.

A deadline fixes when. It does not fix what, and the instinct to fix both simultaneously is what turns these programmes into eighteen months of pretending.

We fixed the date and the quality bar and let scope be the variable. That is an uncomfortable conversation to have in month one and a far better one than the conversation in month sixteen.

Find the Actual Obligation

Usually smaller than the project.

Our programme as originally scoped had about two hundred requirements. Reading the regulation carefully with counsel present, forty one of them were obligations and the rest were improvements somebody had attached.

That exercise took three weeks and removed roughly a third of the work. Nobody had done it because everybody assumed somebody else had.

Build the Compliant Thing First and Badly

A sequencing decision, not a quality one.

By month five we had something that satisfied every obligation, with an interface we were embarrassed by and manual steps in three places.

It was ugly and it was compliant. Everything after that was improvement against a safe position, which changes the character of the remaining thirteen months entirely.

Keep a Working Release Every Fortnight

Even when nothing externally visible changes.

Our previous regulatory programme integrated at month fourteen and discovered its problems then. That is the standard failure and it is entirely avoidable.

Agile Software Development earns most of its value here, not in the ceremonies. A thing that assembles and runs every fortnight cannot hide a structural problem for a year.

Separate the Obligations from the Date Dependencies

Not everything has to be ready at once.

Of our forty one obligations, eleven had to be live on the date. The remainder had to be demonstrable, which is different and much cheaper.

Mapping that distinction let us sequence sensibly rather than treating all forty one as a single wall arriving simultaneously.

Report Progress Against Obligations

Not against story points or percentage complete.

Our board report was a list of forty one items with four states. Not started, built, tested, and evidenced.

That report was readable by lawyers, auditors, and executives without translation, and it could not be made to look better than it was, which is the property a programme report most needs.

Protect the Modernisation You Actually Need

Where the hard call sits.

Two of our obligations were effectively impossible on the existing systems, which could not produce the required audit trail at all.

We did the AWS application modernization services work for those two components only, and left four other systems alone that a wider programme would have swept in. That restraint is the reason we finished.

Plan the Evidence From the Start

The part engineering teams consistently underestimate.

Satisfying an obligation and demonstrating that you satisfy it are two pieces of work. The second involves logs, reports, retention, and a narrative somebody external will read.

We built evidence generation alongside each obligation rather than afterwards. Our previous programme produced the evidence in the final six weeks and it dominated them.

Hold a Real Contingency and Say So

Not a hidden one.

We held eight weeks, visible in the plan, owned by the programme rather than by any team.

Hidden contingency distributed across teams gets consumed invisibly. Ours was spent in two blocks, both for identifiable reasons, and we finished three weeks early.

Decide in Advance What Gets Dropped

The list nobody wants to write.

In month two we wrote the order in which non obligatory scope would be abandoned if we fell behind. Twenty nine items, ranked, agreed by the sponsor.

We dropped nine of them. Each drop took about ten minutes because the decision had been made in a calm month rather than a panicked one.

What Our Approach Required

●        Scope as the variable, with date and quality fixed.

●        A legally reviewed list of actual obligations.

●        A compliant but unpolished version early.

●        An assembled, running release every fortnight.

●        Obligations split by what must be live versus demonstrable.

●        Board reporting against obligations in four states.

●        Modernisation limited to components that genuinely blocked compliance.

●        Evidence generation built alongside, not afterwards.

●        Visible contingency owned by the programme.

●        A pre agreed, ranked drop list.

Common Questions

Can agile work with a fixed date?

Yes, if something else varies. Agile Software Development with fixed date, fixed scope, and fixed quality is just a plan with different vocabulary.

What is the biggest risk?

Late integration. Ours was mitigated entirely by assembling a running system from month two.

How do you handle a sponsor who wants everything?

Write the ranked drop list in month two and have them approve it. The conversation is reasonable then and impossible in month fifteen.

Should the whole estate be modernised?

Only what blocks the obligation. We modernised two components and deliberately left four, and that restraint was the difference between finishing and not.

Does automation help on a fixed date programme?

Narrowly, We used Autonomous AI Agents for evidence collection and nothing on the critical path, because an unpredictable component is the last thing a fixed date needs.

Would you run this differently now?

In one respect. I would ask earlier whether Autonomous AI Agents could produce the evidence pack, because that work dominated the final weeks of our previous Agile Software Development programme.

When should evidence work start?

With the first obligation. Agile Software Development teams build the capability and forget that proving it is a separate deliverable.

Where we ended up

Forty one obligations evidenced, three weeks early, nine optional items dropped by prior agreement, and two systems modernised rather than six.

The date never moved. We spent eighteen months making sure that it did not have to, which required admitting in month one that the scope would.