Nowa­days, cars fea­ture more elec­tro­nic com­pon­ents than ever, embedded sys­tems like bra­king, acce­le­ra­ti­on, navi­ga­ti­on, com­mu­ni­ca­ti­on, and dozens of others must per­form flaw­less­ly in various con­di­ti­on becau­se human life is at sta­ke. With cur­rent, auto­no­mous vehic­les tech­no­lo­gy deve­lo­p­ment trends, the num­ber of safe­ty cri­ti­cal embedded sys­tems will only increase and requi­re more attention.

In Code­lab, we most­ly ope­ra­te in indus­tries with very high secu­ri­ty stan­dards and have many years of expe­ri­ence in Auto­mo­ti­ve pro­jects, the­r­e­fo­re our orga­niza­tio­nal pro­ces­ses are ali­gned to Auto­mo­ti­ve SPI­CE® stan­dard and focu­sed on con­stant impro­ve­ment. Fixing pro­blems quick­ly is signi­fi­cant but the only thing that can pre­vent mista­kes from hap­pe­ning, is fin­ding the root cau­se and tack­le it pro­per­ly. For Root Cau­se Ana­ly­sis we used to use 5 Whys tech­ni­que, deve­lo­ped almost a hundred years ago by Saki­chi Toyo­da. This is a very popu­lar tool, espe­ci­al­ly in Lean Manage­ment. Howe­ver, we quick­ly rea­li­zed that, regard­less of some advan­ta­ges, this tech­ni­que seems to be too sim­pli­stic for our needs. Too often the final ans­wer of inves­ti­ga­ti­on is ‘human error’, too often it ent­ails dis­cou­ra­ging bla­me cul­tu­re. We felt the need to find powerful, effec­ti­ve and soci­al­ly con­scious tool for post mor­tem ana­ly­sis. We got inspi­red by Infi­ni­te Hows method, tho­rough­ly descri­bed by John All­s­paw and also Nick Sten­ning with Jes­si­ca DeVi­ta.

The method does not sim­ply chan­ge one word to ano­ther. Repla­cing Whys with Hows comes pri­ma­ri­ly with a dif­fe­rent mind­set and effort put to ask bet­ter ques­ti­ons, the­r­e­fo­re get more valuable ans­wers. In the fol­lo­wing part, I will pre­sent this topic with more details.

Infi­ni­te Hows method

A per­fect start for any inves­ti­ga­ti­on is to ask ‘why’, but in the end, ine­vi­ta­b­ly chan­ges to who is respon­si­ble. Jud­ging a spe­ci­fic per­son won’t help the pro­ject team with eit­her lear­ning or improving.

Let’s take an exam­p­le. If we start 5 Whys ana­ly­sis with the ques­ti­on: ‘why the deli­very was late?’ we will pro­ba­b­ly learn the root cau­se of the pro­blem is eit­her the mana­ger doesn’t have suf­fi­ci­ent manage­ment skills or someone on the team is not skil­led or trai­ned enough to deli­ver tasks on time. Yes, trai­ning is important, but we don’t need to do a pro­per ana­ly­sis to come to this con­clu­si­on, and it doesn’t help with under­stan­ding the event, moreo­ver impro­ving, and lear­ning from mista­kes. Asking peo­p­le why they did some­thing mul­ti­ple times may put them on the defen­si­ve and make them speak less frank­ly, espe­ci­al­ly when being asked by someone more powerful in the organization.

When using Infi­ni­te Hows method we start asking: ‘how did we made the deli­very?’ it gives us an oppor­tu­ni­ty to learn how we eva­lua­ted the scope of the work, how much the time pres­su­re was expe­ri­en­ced, how often deli­very delays hap­pen, how the approach for coding and test­ing was cho­sen, and the list goes on and on.  Asking ‘how’ lets us under­stand the con­di­ti­ons that allo­wed the fail­ure to hap­pen, gives wider per­spec­ti­ve and more valuable data. It allows us to com­pre­hend the who­le sto­ry and find out what was respon­si­ble for the error. The shift of respon­si­bi­li­ty from who to what not only help with under­stan­ding, lear­ning, and making pro­ject impro­ve­ments but also keep a respectful, open min­ded and enga­ging working environment.