Parkinson’s triviality principle:
It was 1957, all the right people were gathered in a committee, they had one job, approve design for a nuclear power plant. So they did what every man in their situation would do, they scheduled a meeting. As with all meetings, it was very productive, everyone agreed, no-one spoke out of turn, everyone stayed on topic, important decisions were made and they were all out of there early enough to miss the lunch queue.
Unfortunately, instead of discussing the nuclear power plant, these guys devoted most of their time to the plant’s bike shed. Yes, a bike shed. Apparently the two could be easily confused. Also, designing a bike shed was way easier and less things could blow up. Parkinson, the observer of this predicament, noticed that they spent their time working on a trivial problem, why, because it could be easily understood and visualized in the mind. I’m sure you recognize this predicament in your environment, it’s when you step out of a meeting and get the feeling, we’ve missed the target. Zero value was added.
- Predicament number 1: Digress into solving the trivial leaving the actual complex issue unexamined.
Pareto’s 80/20 principle
Entrepreneurs, engineers and anyone involved in delivering software, see the world as a problem to be solved. We can hardly order a burger without identifying the choke point. Over the years, I’ve learned that this is a bad strategy for marriage. Don’t see your wife as a problem to be solved. And how do we engineer types solve problems? By creating a list of-course. We simply can’t relax until we’ve listed all the what-if’s. Are we certain we’ve thought of all the possible catastrophes? Earthquake, check, rapture, check. Is that everything that could possibly go wrong?! Great, now I can finally get a good night’s rest.
Back to the principle, Vilfredo Pareto, an Italian economist, observed that 80% of the land was owned by 20% of the population. Translated into software, 80% of the value is resides in 20% of the scope. Which means the majority of what-if’s isn’t worth our concern. That is definitely my experience, we usually don’t have to deliver all the what-if’s, hitting the base case covers most of the ground. Besides, what-ifs are negative, demotive and results in burdening everyone with everything that could go wrong rather than focusing on adding value.
- Predicament number 2: Defocused by large percentage of what-if’s
I’ve come to realise that these two predicaments are related. We are lured into solving the trivial because it is easy to grasp the what-ifs. So what is the solution to our double predicament? How do we focus on the complex, how do we get to solving the hard problems.
Just Start
Just start. Yes, it’s that simple.
The key here is defining start: In engineering you have distinct phases; analysis, design, development, testing. Start usually means design has been completed, you will now start development. Not so in software, in software, you analyze while you develop. And if that’s not screwed up enough. You also start with the test, deliver before you’re completely done and obtain requirements even after you’ve released. The lines are blurred, if they even exist at all. So what do we mean by start in software development. I’ll tell you what it shouldn’t be: Something you do, after you’ve gained certainty. In engineering you draw up plans to gain certainty before you start. You need to be certain about the distance between the cliffs before you start building the bridge. Besides, the cliffs don’t move while you plan like they do in software. In software, the process of starting, of delivery, is a way, if not the best way, to gain certainty. Development, is analysis, writing tests, is analysis, building front-ends, is analysis.
If we digress into solving the trivial, maybe we’re solving in the wrong arena. The correct arena for solving the complex is at the salt mines, doing the actual work. With the added bonus that while you’re gaining certainty, you’re delivering. In my experience, you gain certainty in the trenches, not before. So get out of the meeting room, embrace uncertainty, and just start!
Let’s get practical
Allow me to share one aid that helps us to just start.
- The story map. We use a story map to prioritize the two dimensional backlog. Our main themes are listed in the top row with detail stories vertically arranged underneath. We draw a line and move important stories above the line, this forms our minimum viable product, or walking skeleton. We have this map with us at every grooming and sprint planning. For us, it does a few things:
- It helps us to identify the 20% value items.
- It is a way to stop what-if’s from defocusing us. As soon as someone brings up a what-if, we write it down, stick it below a line and move on. This way no one gets hurt and we retain our momentum.
Figure out what is the best and fastest way your team gains certainty, and make that your start.
So let’s embrace uncertainty, take action and let’s solve the hard problems in the correct arena. I close with a quote from J.F. Kennedy’s moon speech:
“We choose to go to the moon, not because it is easy, but because it is hard.”
By: Tjaard du Plessis: Synthesis Software Technologies
