Are You Telling The Story of Your Software?

This is Minard's analysis of the fall of Napoleon's Grand Army at the French invasion of Russia in 1812, considered a masterpiece of analytic design:

(source)

It features in my favourite book by Edward Tufte, "Beautiful Evidence", as the focal piece for explaining the principles of data presentation. It is a landmark in the history of the 'infographic', renowned for its cleverness (in stark contrast to the military disaster it describes).

With not much more than a glance, we can learn a great deal. We immediately see the French Army was decimated - that the approach cost many lives, that the attack on Moscow was ruinous. We see that the timing for the return to France could not have been worse, the sinking mercury being the death of many. We note that river crossings were particularly dangerous, each costing a great many thousand lives.

But something is missing.  

We are missing why? Why was Napoleon attacking Russia? Why was he doing this just before the onset of Winter? And why did all these people agree to such a poorly thought-out plan?

From Minard's analysis we know "what" happened, but we do not understand the "why" behind any of it.

In software, we spend a lot of time working in the analytic "thinking space", a place where we are taking things apart and trying to figure out how they work. It's a safe space, because if you do it well, you will probably be able to figure out most of what is happening. But does this help you understand why it is happening? Does this help you tell the story of your software?

What story are you telling?

To paraphase the great Ackoff, a systematic analysis of the parts generates knowledge, but it does not generate understanding. It does not explain why things are the way they are. To create understanding we need to look not at the parts, but rather what they are a part of.

We call this the "synthetic" thinking space, a concept that is ages-old, but which gained popularity with mid-century business thinkers like Ackoff, Deming and Drucker. When we work using synthetic thinking we want to play with the pieces, we put them together and look at them in their context, we come up with ideas by experimenting and observing their interactions.

What do I mean? Let's look at an example:

(source - me ... pre-covid)

This is a user story mapping exercise. We are playing with the pieces of a story that we deconstructed earlier. This exercise is designed to evoke synthetic thinking using a diverse group of specialists (plus a lot of La Croix and Red Bull). It is part of a repertoire of activities that enable us to come up with new understandings: new reasons why. 

Why do customers want us to solve their problems? Why do they want to use our software? Why are they willing to pay us money for it?

To answer these questions we experiment, we try things out, see what works, and fail constantly until we get it right. We use processes that are designed to help us put pieces together, and in ways that reveal the unique, the unexpected, and the innovative. We use synthetic thinking.

How are you telling your story?

It is not just a coincidence that we use the concept of a "story" to capture our work in software.  Since the beginning of human history, stories have been used to connect the dots, to bring people together, to generate knowledge and understanding about the world around us.

Stories connect the analytic with the synthetic: Analytic thinking deconstructs the problem, creating knowledge; Synthetic thinking puts the problem back together again, creating understanding. It’s through cycles of analysis and synthesis that we can change the world. 

For all forms of work, we need to ask ourselves: where should we spend the most time in these cycles? What should we do more of or less of to drive these cycles? 

What story are you trying to tell? If its a software story, you should be spending much of your time in the synthetic space, and using practices that support it.

That’s because software is synthetic, and for software development we have been learning to prioritize this way of thinking. It is the reason why certain practices to succeed in our work. It is the unstated undercurrent that runs beneath many of our successful practices: synthetic work requires synthetic management.