On January 28th, 1986, seven astronauts boarded the Challenger for its tenth launch into space. Its previous missions had included the first space walk and, at various times, the first American woman, African-American, Canadian and Dutchman in space. 73 seconds after lift-off, the Challenger broke apart, killing the entire crew. Why? Because the fuel tank exploded. So, the solution, of course, is to send the next shuttle up with a fuel tank that doesn’t explode, right? Only if you assume that the exploding fuel tank was a 100% isolated incident, completely unrelated to any other events. If that sounds fishy to you, it should. And this is where root cause analysis comes into play, a practice colloquially known as “the five whys”.
Heijunka: Why Batching Is Not Your Friend – Game Planning With Science, Part 14
A commonly held belief is that it’s best to batch work – to handle similar tasks in large, consolidated chunks. The notion makes intuitive sense. It allows you to focus on one activity at a time and avoid so-called switching costs of switching activities. But as with so many other instances of unverified intuition, this particular notion is flat-out wrong. Batching may avoid switching costs, but it greatly protracts flow time, which, in the long run, can end up being far more expensive. Which is why the Toyota Production System introduced the concept of heijunka – “leveling”.
The Muda of Defects, Or: Finding Freedom Through Discipline – Game Planning With Science! Part 13
One of the more interesting characters I’ve encountered in my wanderings through the internet is a man by the name of Jocko Willink. He’s the author of Extreme Ownership and a business consultant. Oh, and an ex-Navy SEAL and a black-belt in jiu-jitsu. So, the man knows a thing or two about getting shit done under arduous circumstances. And his personal mantra is “Discipline equals freedom.” And the more I study operation science and the more I learn about software development, the more I see his point. So, in this post, I’m going to walk you through a multi-step process for testing code and how a little QA discipline can avail a lot of freedom.
Jidoka: Putting The Robots To Work – Game Planning With Science! Part 12
As a developer, you’re almost perpetually flat to the boards. There is always too much to do, too many fires, too many needed fixes. You can’t create more time in the day, or more days in the week. But you can do the next-best thing: eliminate repetitive tasks using automation. Welcome to the wonderful world of jidoka.