Agile has ambiguity โbaked inโ, like everywhere you look.
Decisions are deferred to the last possible moment, detail is delegated to the lowest possible level, roadmaps are notes on a timeless axis. Direct action provides feedback, rather than โinterviewing usersโ.
Disambiguation (I love that word) falls to individual developers. Ambiguity is resolved through person-to-person interaction just prior to code being written, perhaps whilst the code is actually being written.
Did you know this when adopting agile, before sending staff on certification courses and scheduling ceremonies?
Consider this:
Sometimes requirements are known in advance (legacy system replacement), and sometimes requirements are critical to know in advance (safety-critical systems).
But:
Many technical teams, particularly outsourced and offshore ones, really struggle to โdisambiguateโ the requirements (ie. time, access, language, business understanding).
What happens then?
The disambiguation must be deliberate, rather than implied, and must happen in advance.
Itโs less responsive, but will avoid the usual quality issues (bugs, rework, tech debt) later on.