Every time a technical system impersonates a human in a user story, God drowns a kitten in an agile waterfall.— Unknown
The master plan in the grand scheme of things is concerned only with requirements for human users which may lead to the discovery of unnecessary or contradicting requirements; and once they have been identified, an entire cascade of systems can be simplified and whole systems can be removed from the equation.
Imagine finishing a two hours workshop, writing down complicated validation requirements for an exotic credit card type, just to find out that none of the system’s customers actually use that type of payment:
Requirement: as an ATM, I want to be able to submit ACME credit card numbers which consist of Babylonian numerals.
|Example of Babylonian numerals. Source Wikipedia.|
If we challenge this requirement, we’ll have to take it up with the ATM implementation and the ATM functional requirements. Ideally, the ATM people will realise that this requirement is unimportant even to them and there is no need to percolate it through to our project. Less ideally, the ATM is untouchable and “out of scope” and we’ll just have to live with that weird requirement.
Taken to the extreme, the master plan will not stop at questioning the necessity of individual systems or technical processes; no, it will revisit entire business requirements and eventually advance into the spheres of existentialism, questioning the purpose of business as a life-sustaining endeavour and maybe life itself.
While questioning everything is sometimes the honest thing do to (which may have had prevented many doomed-to-fail projects from ever setting off), instead we’re often stuck in local optimisations: we don’t control external systems, the project’s scope and budget don’t cover extensive changes or organisational/political reasons prohibit us from altering anything but the system at hand (“just do what you were told”).
|Example of a Taylor series, source Wikipedia|