About two weeks ago I found myself driving to Dearborn Michigan, to the Adoba hotel to attend Agile and Beyond. I’ve always found the title a bit ironic; too many companies want to get to “beyond” without doing the heavy lifting. It was my third trek to the conference, and I didn’t expect a whole lot new.
Then I heard the opening keynote, by Joshua Kerievsky. It blew me away.
A New Idea For Software: Safety
Kerievsky began his story in New York City, in 1987. Paul O’Neil has just become CEO of a struggling Alcoa, an Aluminum manufacturer, and called his first press conference, and explained his goal: To make Alcoa the safest company in the world, and to use time lost to worker injuries as his gold standard.
This perplexed the folks on wall street. Where was the talk of profit margins, of earnings and sales figures? O’Neil did not make those explicit, nor did he set those as a goal. He figured that if the company accomplished its goal of less accidents, the sales figures would come. Simply considering opportunity cost of worker injury and re-work cost for whatever was damaged, that’s not too much of a stretch.
The ideas worked. Under O’Neil, sales went from 4.6 billion in 1986 to 22.9 billion when he left in 2000, and continued to grow to 30 million in 2007, seven years after O’Neil left the company. Meanwhile profit growth was equally impressive.
My picture of Joshua at Agile And Beyond. With 600 attendees, the place was packed; the only seats were in the far-right front!
What does that have to do with software?
Kerievsky’s next observation was profound: Most software projects are not safe, at least, not safe in the sense that we are comfortable changing code. We are, too often, afraid to change the code for fear of some problem in production, or because rollback is too hard. So we create elaborate, expensive processes that slow down change.
Instead of the slow-down, Kerievsky proposed a different approach: Add practices that increase safety. Pointing to Extreme Programming’s Automated Tests and The Lean Startup’s small experiments as two ways to increase safety on a software project, he added that in physical safety, we have warning signs, hard hat areas, and other visual indicators. Pulling up some source code from a development environment, he asked us “where is the message that this code has a hundred crashes right in this line of code production in the past two weeks?”
Beyond Technical Practices
Kerievsky also mentioned psychological safety, which exists when people are free to express relevant thoughts and feelings, and raising a dissenting view is encouraged and welcome. Without physiological safety, an organization will likely send mixed messages to employees, such as “safety first … and we need to get this code out the door today. Do what you need to do.” Drawing a metaphor, Joshua talked about active failures (“mosquitoes”) and the latent conditions that lead to failure (“the swamp.”) Instead of blaming people for mistakes, he suggested that organizations figure out a way to drain the swamp; that the single largest contribution Agile Software Development may have made is to increase #TechSafety.
The term Joshua used for his #TechSafety approach in Anzeneering, after the Japanese word Anzen, for physical safety.
Nothing New Under The Sun?
You could, of course, argue that there is “nothing new here.” One of the primary motivations of test driven development and refactoring was to produce code that was safe to change — to “drive out fear.” Continuous Integration did the same thing on the detection side; if your CI server ran within fifteen minutes of every checkin, you could be automatically notified when a problem occurs.
Even so, Kerievsky’s talk gives us a few new wrinkles on old ideas. Here are a few:
(1) We get a new umbrella term for improvements. Instead of saying “should we do TDD or exploratory testing first?” we get to ask “Let’s pick one item from this list that will increase the most safety for the least cost.”
(2) The concept of Tech Safety, or Anzeneering, allows us to move the goal for improvement from “what do we have to do to go faster? features, features features” to “what single thing can we do to improve safety?” To do that, we need to have a belief that tech safety is inherently the right thing; that improving safety will lead to velocity, to the ability to respond to change, and to do more ambitious projects with less risk. It certainly seemed to work for Alcoa.
(3) The language of tech safety is one that is familiar to business; it resonates with customers and executives, just as Lean and Six Sigma might resonate where “The Daily Scrum”, “XP”, “Continuous Integration” or “ATDD” might not. Why do those practices? Because they increase safety.
In my mind’s eye I see conversations in retrospectives about what to improve, not focused on velocity, but about tech safety.
Let’s go make Paul O’Neil proud.
As for me, after Kerievsky’s talk, I had my own to do, one on pair programming, with David Hoppe, followed by a panel on #NoEstimates, and then helping on a talk on Lean Coffee. If you’d like to hear more about Agile And Beyond, there’s plenty more to come.