Software Delivery in Small Batches

[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. In each episode I present a small batch, with theory and practices behind building a high velocity software organization. Topics include DevOps, lean software architecture, continuous delivery and conversations with industry leaders. Now let's begin today's episode.

[00:00:26] This episode continues the series on Steven Spear’s 2009 book, the high velocity edge. The previous episode told the story of Mrs. Grant. She died in hospital when she was given the wrong medicine. individual workers did not killed Mrs. Grant. The process that permitted workers to mistake one medicine for another killed Mrs.

[00:00:46] Grant, the staff could not see that one medicine could be mistaken for another and someone died. as a result. All it would take is for someone to say, Hey, these vials could kill someone. Let's do something about it. Well, for that to even happen, organizations must see the problems. This is the entry point into the four capabilities described in the high velocity edge.

[00:01:10] High velocity organizations, identify problems, solve them, then stop them from reoccurring over time. This ongoing process leads to better results. Spear introduces the four capabilities by describing multiple organizations, I’ll focus on two of my favorites, Alcoa and the us Navy nuclear propulsion program.

[00:01:31] The year is 1987. Alcoa is an aluminum manufacturer? A career at Alcoa was risky. Workers had 40% chance of being seriously injured. At least once over 25 years. Research showed that workers were injured when situations may it easy to get hurt and hard to be safe, no one at Alcoa believed they deliberately designed processes that made it hard to be safe.

[00:02:00] of course they thought that because they did not know how to design processes, that made it easy to be safe and hard to get hurt. They assumed they had done everything right from the get-go with all risks and safety concerns, accounted for.

[00:02:16] Alcoa hired Paul O'Neill as the new CEO in 1987, he began with an unorthodox goal, zero injuries to employees, contractors and visitors Why zero zero injuries means perfect processes based on perfect knowledge of how to do work anything more than zero implied missing knowledge or ignorance either.

[00:02:40] Must be. rectified.

[00:02:42] O’Neill established a policy that he must be personally notified within 24 hours of any injury or near miss injuries or near misses were happening up to seven times a day at this point. The policy ensured fresh information flowed to the top of organization.

[00:02:59] People tend to forget details as time passes, but those details may be key to understanding what happened. So they must reported as quickly as possible. There was also a second. rule: O’Neill must receive a report within 48 hours on the causes. and What was being done to prevent an injury from happening again, these two rules created a feedback loop.

[00:03:22] The reports revealed opportunities for improvement. People immediately put countermeasures in place to prevent future occurrences. Eventually the organization built up a body of knowledge on how to design processes that made it easy to be safe and hard to get hurt. That knowledge spread around Alcoa. Eventually a core group of people understood this process then set about developing the same approach in others. When O'Neil joined the risk of injury over a 25 year period was 40%, 20 years later, it was less than 2%. These safety improvements were not at the expense of quality yield efficiency, or even cost.

[00:04:02] In fact, the safety improvements actually made Alcoa more profitable. The point is that no one can design a perfect system in advance while planning for every possibility. However, teams can discover great systems and keep learning how to improve them. In other words, perfect systems are not designed. They are discovered Alcoa's story demonstrates, each of the four capabilities, 1. seeing problems as they occur 2. swarming and solving problems.

[00:04:35] 3. spreading new knowledge 4. developing capabilities, one, two, and three. in others. We'll look at how Admiral Rickover demonstrated these same capabilities years earlier, in the us Navy In the next episode, you've just finished another episode of small batches podcast on building a high performance software delivery organization for more information, and to subscribe to this podcast, go to smallbatches.fm. I hope to have you back again for the next episode. So until then happy shipping.

[00:05:12] Like the sound of small batches. This episode was produced by pods worth media. That's podsworth.com.