MVKJG 2: Fråga varför tills du får en smäll

I det snudd på magiska ordet varför ryms ett otroligt kraftfullt sätt att lära sig mer om vad som helst.

Det berättas ibland sedelärande historier om chefer hos biltillverkaren Toyota som kommer till insikt om sina egna bristande inköpsdirektiv när de frågar varför det finns en oljefläck på golvet. De lyckas helt enkelt härleda det stora från det lilla, med den frigörande frågan: “Varför?” Det visar sig att de själva är ansvariga för oljeläckaget, eftersom de stipulerat inköp av oljefilter från den billigaste leverantören, som tyvärr också visade sig vara den sämsta.
Själv brukar jag använda mig av ett ganska praktiskt verktyg som ibland kallas varför-hur-trappan [1]. Har man tillgång till något att rita på ritar man helt enkelt en liten trappa, och lägger gärna till en pil som pekar upp för trappan med texten “Varför”, och en pil som pekar nedåt med texten “Hur”. Sen är det bara att skriva in det vi vill lära oss mer om någonstans mitt på trappan, och sedan följa trappstegen i endera riktningen. Tar vi ett steg uppåt frågar vi oss varför, går vi nedåt frågar vi oss hur.

Så här till exempel: vi borde börja skriva fler automatiska tester, skriver vi på mitten av trappan (eftersom någon just föreslagit det efter att ha läst MVKJG 1. Sen frågar vi oss varför, och skriver in svaret på steget ovanför: så att vi effektivt kan fånga och ta bort fler fel. Steget ovanför kommer nästan av sig själv, vi vill såklart bygga en felfri produkt, och anledningen till att vi vill det är förstås att vi vill ha fler kunder.

Vi kan gå nedåt också, genom att fråga oss hur. Varför inte rekapitulera från toppen? Vi vill ha fler kunder. Hur kan vi få det? Genom att ha en felfri produkt. Hur kan vi få en felfri produkt? Genom att hitta och eliminera så många fel som möjligt. Hur då? Genom att skriva automatiska tester som hjälper oss i testarbetet!

Sen kan vi fortsätta ännu längre ner förstås. Hur ska vi skriva automatiska tester? Genom att lära oss hantera ett ramverk för att skriva och aggregera tester. Hur ska vi lära oss ett sånt ramverk? Genom att köpa in böcker och planera in tid för lärande i vårt arbete.

Den här enkla modellen är vansinnigt användbar när man planerar ett projekt eller en iteration. Genom att placera in bitar av planen i trappan kan vi känna om de ligger på rätt nivå. Är de lagom konkreta, lagom målorienterade?

När jag hjälper till att planera iterationer vill jag till exempel att de funktioner och kvaliteter vi planerar i ska uttryckas så att utvecklingsteamet själva kan välja hur man vill uppnå dem. Blir vi konkreta för tidigt riskerar vi att låsa in våra tankar och eliminera möjligheter. Är vi för abstrakta blir det svårt att se om det vi planerar verkligen är genomförbart.

Proffsteknik: låt trappan evolvera till ett träd av orsakssamband som sprider sig i alla riktningar. Det finns ju alltid fler sätt att förklara orsaken till något, precis som det finns fler sätt att åstadkomma ett visst resultat.

Ett varningens ord på vägen dock. Konsulten och författaren Gerald Weinberg har pekat ut [2] att en fortsatt undersökning av ett problem ofelbart leder fram till problemets källa, som med största sannolikhet är din uppdragsgivare. På Toyota pratar man om fem varför. Jag brukar kalla metoden för “fråga varför tills du får en smäll på käften”. Det återspeglar bättre den sanna potentialen i denna grovt underskattade teknik.

—-

[1] Jag lärde mig verktyget i den suveräna “Att sälja och ta betalt för kunskap” av Britt-Marie Ahrnell och Rolf Edman.

[2] Se till exempel den roliga Secrets of Consulting, Gerald Weinberg.

Published by Tobias Fors

I'm a software management consultant. I help other people succeed with software development. In my work, I help teams and organizations be more effective and ship software.