Our Journey to ISO 26262

You may have noticed our recent certification announcement related to ISO 26262, but what you may not know is the behind the scenes story of how it all went down. This was no easy walk in the park. Our journey to being certified by TÜV SÜD as “fit for purpose” started with the simple realization of the growing importance of having such a certification would help our customers use Jama within their own certification. As the first few steps took shape and despite the many supportive and excited responses we heard from our customers, there where almost as many internal debates about the true value or perceived cost of going through the process. At Jama, we pride ourselves on following an agile development process, so it was inevitable that questions like “will it require a change in our culture?” and “will we need to relinquish our existing methodology?”, started to creep in. For those of you familiar with our “5 Keys of Modern Product Delivery”, we took a bit of our own advice (Define the Why, Rethink Change) and we managed to overcome those concerns, but the debate helped shape the final outcome.

Phase 1: What does ISO 26262 mean to Jama
Jama is not building automotive parts, so our understanding of ISO 26262 was already limited. Thankfully we have great customers who were willing to work with us and internally we spent hours (months) researching and meeting with customers and industry experts to better comprehend what it means. For Jama, that meant before anything else it was critical that we figure out and deeply understand our role as a tool supplier in a customer’s validation process. The more we learned, the more it became clear that we were not getting certified on ISO 26262 but instead as a tool that was “fit for purpose” within our customer’s own certification. This really all boiled down to building trust that the Jama solution would not screw up their process. Sounds simple enough when I read it back now, yet even though everyone understood this nuance it was amazing how many times it needed to be repeated or clarified!

Phase 2: Organization alignment
The next step was to work internally to educate and prepare for an audit. My stance was that regardless of the methodology the certification was about quality and safety – so as long as we were able to, with confidence, demonstrate that our process ensured both of those things we’d be good. As I mentioned previously, our process was Agile with iterative, continuous working software, and a strong collaborative mindset. But could we demonstrate safety? And what did safety mean in the context of Jama? This new angle to the earlier debate would continue right up until the end.

The main area of contention was the premise that we should have a standard set of requirements for the entire product that tests, new requirements and issues all traced to. But with agile software development the reality is that the software itself represents the product. For Jama that meant after 10 years of development, numerous Kanban boards, sprint planning sessions, and MVP’s we simply didn’t have a large historical requirements doc to reference. The solution was the creation of the “Safety Manual” (calling it that was yet another debate because again, we are not building an automotive product). The Safety Manual describes the core workflows within the Jama product that we deem part of a customer’s process. These workflows are the same that they would use for their own certification. This document became a grounding document – it can trace tests to these flows and product. Support references it with the understanding that our customers are relying on those core flows.

Traceability became an obvious critical factor, without which we would not have been able to fully realize had we not been using the Jama solution itself. The fact that we use our own solution meant that Themes, Epics, Stories, and tests were all traced and versioned out-of-the-box. This highlights that while agile proponents like to claim less documentation (while millions of post-it notes die every year for the sake of less documentation), the fact that Jama is easy to use, web based, and part of our process the “documentation” is a natural course of our workday and not an added burden. The end result was that heading into an audit we were ahead of the game.

Phase 3: The Audit
We actually went through three audits. The first was conducted by a Jama customer who early on decided to come on-site to conduct their own audit (this was before getting our own certification). We then hired an actual auditor to come and do a gap analysis to determine how far off we were. The good news – we were not that far! So after researching multiple auditors and asking customers who was most respected in the industry we determined that TÜV SÜD was as about as authoritative as we could get. The audit itself went very well and we made it through without any major hiccups or surprises. Obtaining the certification was where the story we set out to tell was supposed to have ended. Goal attained.

But the big news, and the part of this journey we had not set out to discover or validate was the degree to which our agile process aligned with the best practices typically associated with waterfall. (Remember all of that earlier debate???). Our own process of becoming ISO 26262 fit for purpose demonstrated that agile, when done with diligence and intent, can be used in compliant environments. We managed to maintain our trust and belief in our Agile process but also that the process was recognized as rigorous enough to pass traditionally document and process heavy interpretations of a standard. I can still hear the collective sigh of relief from within Jama. Until the next journey…

Author
Recent Posts

Derwyn Harris

Derwyn Harris writes about ISO 26262 compliance, rethinking the Agile manifesto, and lessons learned in complex product development.