Agility in a World Full of Mandates

In this 2-part series, I'll be covering an issue I've seen several Agile teams face firsthand: how to stay Agile when developing mandated, compliance-based features.

In Part 1 I'll look at ways to approach this type of work, including reducing risks, sustaining user value, and why reverting to a waterfall approach isn't the best answer.

Part 2 looks at changes to the Product Manager's playbook.

---

Part 1: When Outcomes Aren’t Incremental

Story Time

Early in my career, I had an awesome Agile coach drill one lesson into my head: focus on outcomes, not outputs. His favorite metaphor? Fixing Thanksgiving dessert.

“Some want pumpkin pie, others pecan. A few crave chocolate cake, some swear by carrot. You can’t bake them all, so focus on the outcome: serve a great dessert.”

I loved it and used it everywhere... until I tried it in a room full of government stakeholders.

One shot back: “But I want all the pies and cakes.”

I thought they’d missed the point. Turns out, I had.

In their world, every dessert was the outcome. Their job wasn’t to optimize for delight, it was to deliver everything listed, exactly as written.

The menu was set upstream. Their role? Execute it.

When Agile Breaks Down

Standard Agile advice flows beautifully when you’re chasing user value: ship small, gather feedback, iterate, repeat.

But what happens when the next priority isn’t driven by users at all?

• A compliance clause buried in a customer contract

• A security mandate from legal

• An executive deliverable with zero tie to your actual product

No MVP. No feedback loop. Success is binary: comply or fail.

Teams in government and large enterprises live here. The work doesn’t bubble up from analytics or research, it drops down. It could be from Statements of Work, regulations, or C-suite fiat. You don’t negotiate whether it happens. You only decide how to deliver it without breaking the system.

This is where traditional Agile guidance cracks. Some teams surrender to waterfall. Others fake the ceremonies while batching work in secret.

Agile still works, you just need a new definition of value.

Redefining Value as Risk Reduction

When you can’t ship user value in slices, you can still reduce risk in slices.

Agile was built for handling uncertainty: learning fast, testing assumptions, delivering safely. Strip away the user-value lens, and risk reduction becomes your North Star.

Incremental Risk Reduction lets you stay Agile when the requirement is large, mandated, and non-negotiable.

You're not incrementally delivering a feature. You're iteratively lowering your risks. Every step builds confidence, even if nothing new is visible to users.

Ask yourself:

• Can we deploy this safely to production without impacting anything?

• Can we isolate the change behind a feature flag?(A toggle that hides unfinished code from users.)

• Can we ensure this won’t degrade the user’s quality of life?

• Can we release it to a small, low-risk group first?

None of these ship a visible feature. All of them shrink uncertainty. 

That’s Agile, just in stealth mode.

A Real Example: Fingerprint Authentication

Your biggest customer just told you that you're now required to add a fingerprint login. No one in your user base asked for it. The change isn't negotiable. There is no "almost done" or really even an MVP. It's either all or nothing.

You could waterfall it and try to define every edge case up front, code for two months, schedule a high-stakes release weekend, flip the switch, then pray.

Or, you could reduce the risk:

• Deploy the code in dark mode so it reaches production without being active

• Add monitoring to detect unexpected issues

• Enable shadow mode so the fingerprint logic runs silently for comparison

• Run an internal rollout to validate in a controlled setting

• Gradually expose the feature to real users when it's proven stable

This lets you protect the live system, buy time to react, and (surprise) you might even spot small UX wins (smoother error messages, faster fallback) that improve the experience even though the feature wasn’t user-driven.

Agile here isn’t about velocity. It’s about safety and control.

What’s Next: The Product Manager's New Playbook

We’ve seen how teams can stay Agile under mandates. But someone has to orchestrate the balance: mandated work vs. user needs, short-term delivery vs. long-term system health, compliance vs. innovation.

That someone is the Product Manager.

In Part 2, we’ll explore:

• How PMs can prioritize when “user value” and “contractual obligation” collide

• Why the classic product model fails in mandate-heavy worlds, and what to do instead

Stay tuned.