Responsiveness matters. But repeatedly changing committed work without changing time, scope, or risk is not agility—it is unmanaged rework.

Someone always says it as though the words make the effort disappear.

“It is only a small change.”

The release is nearly ready. Testing is complete. Communications are prepared. Then a senior stakeholder asks for one more feature, configuration adjustment, or exception.

The delivery date cannot move, of course.

The request is approved, the team is told to be agile, and several days of completed work quietly return to the starting line.

Agility changes direction quickly. Chaos changes it repeatedly without accepting the cost.

The “small” packaging change

Imagine a Packaging and Distribution team preparing a finance application for deployment to 4,000 laptops.

The package has passed installation, upgrade, rollback, and security testing. Two days before rollout, the application owner requests a new reporting plug-in for an executive demonstration. It sounds harmless, so leadership approves it without moving the deployment date.

Packaging reopens the build. The plug-in introduces another runtime dependency, so regression testing is compressed. During rollout, hundreds of laptops without the required runtime begin failing and retrying. Network traffic rises, employees cannot open the finance application, and the Service Desk fills with calls. Distribution pauses deployment while Packaging rebuilds the package overnight.

The plug-in was small. Its consequences were not.

Employees lose confidence in planning because “finished” work is never really finished. Service delivery absorbs rework and emergency effort. Customers lose access and receive inconsistent updates. The organization pays through overtime, delayed work, failed changes, and another avoidable incident review.

A late request does not create new capacity. It decides which planned work will be displaced.

Why teams keep saying yes

Late requests are highly visible. The requester is often senior, the deadline feels immediate, and saying yes creates the appearance of responsiveness.

Human judgement can be influenced by urgency and optimism about how quickly work can be completed. Ideas such as the planning fallacy help describe our tendency to underestimate time and complexity, but they do not explain every decision. Sometimes leaders knowingly accept the risk.

The real problem is accepting it invisibly.

When managers approve the change without naming what will move, employees are left to compress testing, work late, and carry consequences they did not authorize.

When leaders approve every last-minute request, employees learn that planning is optional and rework is normal.

What leaders should do

Managers do not need to reject every late request. Genuine emergencies happen, customers change direction, and new information can justify a different plan.

But the decision needs discipline:

  • Define a change cutoff and a risk-based exception path.
  • Ask what testing, work, or deadline will change.
  • Name who accepts the operational and customer risk.
  • Track expedited requests and the rework they create.
  • Protect employees from being blamed for approved trade-offs.

Organizations should align business and technology leaders around the same rule: if scope changes, something else must change with it—time, capacity, risk, or another commitment.

Key Takeaways

  • Late changes are not automatically agile.
  • Small requests can reopen large areas of completed work.
  • Every expedited change displaces planned capacity.
  • Visible trade-offs improve accountability and decision quality.
  • Planning loses credibility when exceptions become routine.

Discussion question: What happens in your organization when someone requests “one small change” just before go-live?