In 1935, physicist Erwin Schrödinger proposed a thought experiment to explain how quantum mechanics deals only with probabilities rather than objective reality.
He outlined a scenario in which a cat is placed inside a sealed chamber. Inside the chamber is a flask containing a deadly substance. There is a small bit of radioactive material that has a 50% chance of decaying within a specified time period, say an hour.
If the radioactive material decays, a hammer breaks the flask and the cat dies. If it does not decay, the contents of the flask are flushed safely away and the cat lives.
(This would be a barbaric experiment if it were real, but remember that this is only a thought experiment. No actual cats were harmed.)
If we were to leave the apparatus alone for a full hour, there is an equal probability that the cat lived or died.
Schrödinger explained that in the moment before we look inside the box to discover the outcome, the cat is both alive and dead. There is no objectively measurable resolution to the experiment…yet. The system exists in both states. Once we peek (or by any other means determine the fate of the kitty), the probability wave collapses.
When I first read of Schrödinger’s Cat in my physics class, I was befuddled. A cat is alive, or dead, not both. I did not understand the idea of a probability wave that contained both possible states.
So I can understand completely if you are thinking, “Look, the dang cat is dead. Or not. And besides, this is not related to software AT ALL.”
Ah, but it is.
You see, in the moment we release software, before users* see it, the system exhibits the same properties as Schrödinger’s feline.
There is some probability that we have done well and our users will be delighted. There is another possibility: we may have missed the mark and released something that they hate. (Actually there are an infinite number of possibilities involving various constituents with varying degrees of love and hate.)
Until the actual users start using the software, the probability wave does not collapse. We do not know, cannot tell, the outcome.
For teams that believe they are building awesome stuff, the moment before users get their hands on our work is a magical time full of excitement and wonderment.
For teams that believe they are building a pile of bits not suitable for human usage, it is a time of fear and panic.
But both fear and excitement stem not from observable reality but rather from speculation.
We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us.
We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking.
We are speculating that we knew what the users actually wanted in the first place.
We are speculating that the tests we decided not to run wouldn’t have found anything interesting.
We are speculating that the tests we did run told us something useful.
None of it is real until it is in the hands of actual users. I don’t mean someone who will poke at it a bit or evaluate it. And I don’t mean a proxy who will tell you if the users might like it. I mean someone who will use it for its intended purpose as part of their normal routine. The experience those users report is reality. Everything else is speculation.
This is what teams forget in that heady moment just before release. They experience all their excitement or terror, confidence or insecurity, as real. We forget that reality is meta-surprising: it surprises us in surprising ways.
And this is why Agile teams ship so often.
It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact.
In short, frequent delivery means we live in reality, not probability.
Facing reality every day is hard. Ignorance is bliss, they say. But living in the land of comforting illusions and declared success is only blissful as long as the illusion lasts. Once the illusion is shattered, the resulting pain escalates with the length of time spent believing in a fantasy and the degree of discrepancy between our beliefs and the actual results. Given sufficient delusion and lengthy schedules, the fall to Earth can be downright excruciating.
I’ll take small doses of harsh reality over comforting illusions and the inevitable ultimate agony any day.
* I use the term “users” here to represent both users (the people who use the software) and customers (the people who decide to buy the software).
If you are buying yourself a game to play, you are both the user and the customer. In sufficiently enterprisey systems, the customer might never even see the software. In that situation the customer and users have very different concerns, so it’s a more complicated probability wave. After all, if the customers love it but the users hate it, was it a success or failure? I’ll leave that discussion as an exercise for the reader.