Today’s move-fast-get-it-to-market-yesterday product development culture puts a lot of pressure on companies to innovate quickly. Such circumstances can make defined processes and comprehensive documentation look unsexy and uncompetitive… even when they’re in the best interest of the organization.
In October, Jama Software and kVA by UL co-hosted a kVA Automotive Lunch & Learn at the Hyatt House in Silicon Valley. kVA by UL is a technical and management consulting group focused on functional safety and the ISO 26262 standard. Bill Taylor, Managing Director of kVA, spoke to a group made up primarily of automotive industry engineers, many of whom are working on autonomous vehicles.
Taylor presented on the topic of “Creating a Safety-First Culture in Automotive Development,” but the points he made could easily be applied to any complex product development where public and/or user safety are a primary concern. Here are five key take-aways from Taylor’s presentation.
Don’t Fall for the Smart Folks Fallacy
When we get on an airplane, do we trust that our pilot and co-pilot are experienced, well-trained professionals? Do we assume they really know what they’re doing and that they’ve done it many times before?
Of course, we do. So, why do the airlines — and the military, and every other aviation employer —make their pilots use checklists?
Learn how to mitigate common ISO 26262 mistakes with our whitepaper, “Top 15 ISO 26262 Snafus.”
It’s so they don’t have to think about it. The checklist is there so a distraction doesn’t cause the pilot to miss or forget a small but crucial step in their procedure.
But many who innovate for a living — especially those who face pressure to innovate rapidly — don’t like checklists. Checklists feel cumbersome, tedious, slow, and perhaps even antiquated. They’re constraining. They don’t let you work the way you want. Checklists force you to work to their dictates.
But checklists are great for safety, says Taylor. They force you to take all the prescribed steps.
Taylor warns against a phenomenon he sees often in the automotive and tech industries, which can roughly be described as the “Smart Folks Fallacy.” He describes it with a fictional conversation, which we’ll paraphrase:
“Hey, who’s keeping us safe?”
“Oh, don’t worry, we’ve got some smart folks over there.”
“Yeah, but how do we know we’re safe? Have we written good requirements? Have we analyzed them? Have we done direct testing? Do we have traceability throughout our process?”
“Nah, we haven’t done any of that. But those folks over there are really smart. So, we’ll be fine.”
Unfortunately, even smart people make mistakes. They’re under pressure to deliver. They get wrapped up in their immediate priorities. Even a smart person might miss something that’s tiny but critical.
Safety Relies on Process and Culture
Taylor says it’s hard to standardize culture. A true safety culture requires more than just following a set of rules, regulations, and standards. But a framework can be articulated.
In that framework, Taylor would expect to see a set of processes designed to comply with applicable safety standards. He would want to see process documentation that, among other things, describes:
- The steps of the safety process
- Any templates that are to be used
- The tool set that will be used
- Outputs that get reviewed, and who reviews them
- The qualifications necessary to be a reviewer
Failure to follow a sound safety process leads to disaster, says Taylor. He maintains that in every accident report that makes the news, there is someone who says, in effect:
“I realized this could be a problem. I told my boss, and he kind of understood, but not exactly. Anyway, we were crazy busy, etc., etc.… It just got pushed aside.”
You need a system and a culture in place that will turn that potential problem into a documented safety anomaly — that will put it on the radar and make sure it gets addressed, says Taylor.
A Safety-First Culture Needs Police Officers
Just like governments need a police force to enforce laws, companies must invest in safety personnel with the authority to prevent potential hazards from being released into the field.
This doesn’t mean putting safety managers at the top of the pyramid, Taylor says. Instead, he likens it to Toyota’s famous quality system, where every plant worker has the authority to stop the production line if they spot a flaw. It’s a huge expense when it occurs, but it can save much greater expense down the line by avoiding costly recalls and lawsuits. It also makes everyone realize quality assurance is a part of their job.
It’s the same with safety. When a problem is a safety issue, the safety team must have the power to say, “Stop! We have a process to communicate and address this issue. We have the authority to make things stop until the issue is fully resolved.”
Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.
Embrace the Idea of “Nothing Happening”
Taylor says safety engineers have a weird point of view: They’re inspired by the idea of nothing happening. That’s because, when people buy your product, they expect that nothing bad will happen to them… ever. If something bad does happen to them, and it’s your fault, they’re likely to sue you.
“Someone has to take ownership of this idea,” Taylor said. “There must be a group that says to themselves, ‘While the rest of the organization is innovating and creating amazing things, I’m going to make sure that nothing bad happens, and I can be motivated by that idea.’ It means you’re not out there making the thing be better and more awesome, you’re just trying to make it work in a way that doesn’t kill anyone.”
“And usually,” Taylor continued, “Your CEO says, ‘I thought it was just assumed that it wouldn’t kill anyone.’ And you say, ‘Yes, but someone has to be in charge of that. Someone needs to own that.’”
Accept that Safety is the Antithesis of Agile
The Manifesto for Agile Software Development values “individuals and interactions over processes and tools” and “working software over comprehensive documentation,” he said. Safety, on the other hand, cannot be assured without a commitment to process and documentation. “Software observed to be ‘working’ can often be fundamentally unsafe,” Taylor noted.
Taylor went on to say that where Agile tries to reduce friction, safety values friction. Friction is how we maintain control. Without friction, everything slips out of our hands.
“If our process has no friction, it’s out of control,” he said. “Agile is not wrong. Agile is wonderful for making progress” but it’s not sufficient for ensuring safety.
In complex product development, Taylor says, we don’t see a lack of smart people. What’s often lacking is a commitment to process and the tools that enforce that process.
We need to make allowances for Agile and a safety-first culture to coexist. Use Agile to make rapid progress. But allow safety to apply its processes — and apply the brakes, when necessary.
In other words, we need to accept the checks and balances of the safety process. Taylor summed it up this way: “Value friction. Value slowness. Take ownership of ensuring safety.”
To further assist in mitigating risks in the development process, maintaining compliance with automotive functional safety standards, creating a safety-first culture, and staying updated on the changes to ISO 26262, check out our white paper, “The Impact of ISO 26262 on Automotive Development.”