A real life situation
A bright but icy winter morning in southern germany: Dozens of people stand on the platform at a local train-stop in Munich’s outskirts. The display reads “train arriving”. Ten minutes later the crowd is visibly unhappy, swearing and freezing. The first would-be passengers start to leave the platform in search for other means of transportation.
The whole attitude is “We [strongly disklike] those (explicit deleted) responsible for the public transport”
A rainy day in England. Hundreds of people walk into the tube station at tottenham court road, quickly glance at the sign that posts the current outages in the London transport system and quickly decide to use the ‘Northern Line’ and the ‘Circle Line’ to get to ‘Victoria Station’ since the ‘Central Line’ runs only at 50% and takes much longer this morning (and is probably heavily overcrowded as well)
The whole attitude is “business as usual”
The Situation (related to the software world)
In a computing environment some resource (a called service, the internet connection, memory, disk etc.) is not available or at its limit and the System just ignores it until it finally fails. (Another version could be planning meetings, where the fact that the amount of work can not be done in the available time (or that some preconditions, like known requirements etc., are not yet met) get ignored until after the deadline hits.)
Almost all software that does not offer sensible graceful degradation strategies and thus shows an error message only after the user tried to access a – probably vital – function of the system. (E. g. E-Mail clients that say “Encryption Error while initiating secure connection to server” after polling the mailbox for two minutes … while the computer actually is not connected to the internet.)
The physical world example is in fact the German railway system (and even worse a lot of the public transport operators) where arrival times of trains and busses are sometimes displayed based on plans instead of the real situation.
The user loses trust in the system and either switches to alternatives (e.g. if the system with the un-announced problem is a trouble ticket system the users might start sending mails instead of using the ticket-system, in the physical world people switch from public transport to private cars etc.)
Communicate everything you know about probable system malfunctions as early and visible as possible. Plan your outages and be honest about them. Design software with sound graceful degradation strategies.
Related lean/TPS concepts
Related values from the Agile Manifesto
Responding to change over following a planWorking software over comprehensive documentation
Related Scrum Values