Kaizen, checklists, and doing software presentations

Here’s my take on how to make your software presentations better.

Photo by Austin Distel on Unsplash.com

There’s this medical doctor, named Atul Gawande.

He’s a general surgeon, working at a hospital in Boston.

He’s also a staff writer for The New Yorker.

Furthermore, he’s an assistant professor at Harvard Medical School.

Would you like to sit down with this guy for a coffee? Pick his brain, ask him a few questions that sometimes crossed your mind?

Me, I’d love to do that, for sure.

And there’s a pretty easy way for me to do so, any time I feel like it.

Because this guy wrote a book. 

And not just any book.

His book is titled The Checklist Manifesto: How to Get Things Right.

And this book’s title hits the nail right on the head because it’s very close to what this post is about: Doing a demo.

The premise of his book starts with a common-sense observation: The world is complex, our collective knowledge is vast, and human beings are prone to errors, both of judgment and memory. That’s why we should be using one powerful and simple tool: the checklist - a lot more often then we do presently.

Planes, doctors, and agile software demoing

The original place of checklists was the commercial airline industry. Before every flight, a pilot and a co-pilot go through a series of checks, to make sure they deliver to the best of their abilities.

The initial premise of The Checklist Manifesto is defended by the author throughout the book: we can, and should, apply the checklist tool to any area of human activity where excellent performance is necessary, so that we can consistently, correctly, and safely perform a series of complex tasks.

Besides the airline industry, another place where this is crucial is the healthcare industry.

I firmly believe that any person undergoing a complex medical procedure would be happy to know that the medical staff performing the task is going through a series of checks, tested and retested, and improved over the countless past procedures.

If any patient was to be asked whether they’d like their doctors to perform such a series of checks from a predefined checklist, it seems to me that the only logical answer would be a resounding “yes”.

I believe that the conclusion here is obvious: We, workers in the software development industry, have a thing or two to learn from the pilots and the doctors.

When doing a demo for our clients, it would benefit us immensely to utilize a checklist.

How in the world do I checklist a demo?

In his ultra-short book, Just F*cking Demo!, the book author, Rob Falcone, gives us a treasure trove of practical advice on making our demos instantly better.

Let’s take the advice from the above-mentioned book and marry it with the checklist-everything approach. We’ve just gotten ourselves an actionable demo checklist!

Note that this is not a one-time process. It’s not an easy process either. However, there’s another tool that we can put to good use here: the principle of Kaizen.

Continuous improvement and agile demo checklists

Sakichi Toyoda is the founder of Toyota. In the 1950s the Toyota company piloted Kaizen, a system of implementing continuous quality improvements throughout the company, including technology, processes, company culture, productivity, safety, and leadership.

The philosophy of Kaizen is based on continuous small improvements and continuous efforts at reducing waste.

The focus on continuous improvement can be seen in another one of Toyota’s inventions: just-in-time manufacturing.

This is a prime example of a dedication to Kaizen bearing fruits in unexpected ways, spilling over into other areas of a company’s performance, boosting creativity and innovation.

How could we in the IT sector, see the benefits of the Kaizen approach in general?

What could we expect from it when applied to software demoing in particular?

The thing that immediately comes to mind is that once we’ve created all the checklists for our software demoing, we can apply Kaizen to constantly monitor the performance of our software demos, analyze what went wrong and find the ways to both make it better and “reduce the waste” next time around.

Obviously, this should be a team effort.

Similar to a pilot and a co-pilot performing checklists pre-flight, preparing and analyzing both a great software demo and a catastrophic one, should involve at least two team members in your organization.

Where to go from here?

Just implement Kaizen and carve out your company’s best practices through experience.