Expectation Management: Mind the London tube notifications

A real life situation

Munich

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"

London

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.)

Example

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 Problem

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.)

A Solution

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

Andon
Heijunka

Related values from the Agile Manifesto

Responding to change over following a plan Working software over comprehensive documentation

Related Scrum Values

Openness

Requirements - a different IPO than that at the stock exchange

I really do love Mike Cohn's format for user stories, but while formulating requirements in the form

"As a <type of user> I want <desired system interaction> so that <desired outcome>"

is very helpful for capturing requirements, it is in no way sufficient.
The point is not only that user stories really have to be written from a user's point of view.
Writing genuinely from a users perspective means that there should not be any story

"As an internet-user I want the system to perform garbage collection so that the server doesn't have to have too much memory."

because, quite frankly, most internet users don't care about garbage collection or the server's memory - they care about response times, user experience and (hopefully) the service that is provided.

But there is more to good requirements than just writing a story from a users point of view – one of the intriguing stories from Tom DeMarco's The Deadline is the one where a bunch of people read a 18-binder specification for a system and none of them dared to tell the project manager that they did not really understand what it was all about. Those binders where full of technical detail and elaborate formulas but lacked a couple of important things nobody noticed at first.
Until somebody asked "Where does the data come from?" and another one chimed in "Where do the outputs go to?" After that magical moment the spell was lifted and all kinds of missing information were was surfaced. In the end the specification was reworked and the project could go ahead.
Which brings us to the basic point of every operation in a system - there has to be an Input, some kind of Processing and an Output. In the olden days there was a name for that concept, it was called the IPO model and used to be applied to hardware as well as to software.
And even though we (hopefully) don't write our programs anymore as the sequence 'input division', 'processing division' and 'output division' the basic structure for requirements is still quite valid. If the input or the source of the input is unclear it is hard to decide how it should be handled. If the postprocessing is unclear – the output – it is hard to decide what to do with the results from the processing.

So for every requirement – if it is formulated as a user story or in any other way – before the implementation starts it should be clear what that user-story's IPO is.

Till next time
  Michael Mahlberg