Chris Hofstetter

Fail fika - för att lära oss av misstag måste vi kunna göra misstag

2019-05-03 Blogg Kravhantering Test Läst 810 gånger

Innan jag började jobba inom IT pluggade jag ingenjörslinjen inom mark, väg och vatten vid ett universitet i Kalifornien. Universiteten i regionen tävlade årligen i olika ingenjörskonster till exempel genom att bygga kanot av betong och sedan köra paddellopp mot varandra. Jag fick äran att leda ett team som tävlade med broar som vi designade och byggda av glasspinnar och vanlig vit lim. Bron som klarade högsta spänning under tryck vann.

De olika lagen gick till vägs på ungefär samma sätt. Vi designade utifrån de principerna vi hade nyligen lärt oss på utbildningen. Vi använde oss av datorprogram för att kontrollera och optimera vår design – en justering av vinkeln här eller avståndet mellan skarvställen där.  Vi trodde att vi med dessa kunskapar kunde ha rätt från början, att det bara var att bygga utifrån våra specifikationer, och sedan köra. Några av oss testade våra broar i en maskin som mätte upp spänningen under belastning.  Det var rätt imponerande vilka laster våra broar av glasspinnar klarade av innan ”failure” dvs innan brön började böja sig vilket ledde till förminskad spänning. Vårt team tog det ett steg vidare än de andra teamen, vilket visade sig vara en avgörande skillnad. Vi modifierade bron genom att förstärka den svagaste punkten, och limmade om. Samtidigt byggde vi en helt ny bro med samma modifierade design. Då hade vi två broar att testa och jämföra med. Varje bro vi byggde, med modifierad design efter den tidigare misslyckade, blev starkare och därmed ännu mer framgångsrik än sin föregångare. Därutöver observerade vi något oväntat. Den bron som tidigare hade testats och gått sönder redan en gång, presterade ännu bättre än vår ”färska” bro av identisk design som vi byggde på nytt. Vi bestämde oss för att gå till botten med vår observation. Detta ledde till en innovation, en genombrott där vi upptäckte att vi kunde förstärka en bro genom en initial belastning under en längre period. Denna förspänd konstruktionsteknik kombinerad med diverse designjustering längst vägen var två riktiga framgångsfaktorer. Under fler år tog vi hem förstapriset i tävlingen utan att konkurrensen kom i närheten av oss. Vår hemlighet låg i vår vilja att lära oss av misslyckande. Man kan säga så här i efterhand att vi hade en kultur där vi välkomnade misslyckande och jobbade med innovation som naturliga delar av vår utveckling.

Detta var längesedan i en bransch som inte hade så mycket med IT att göra. Jag ser ändå starka paralleller till trender inom systemutveckling idag. Med åren har vi insett att vi inte kan ha allt rätt från början. Vi kan därmed inte förvänta oss att de mest optimala lösningarna är byggda utifrån förbestämda, detaljerade kravspecifikationer. Visst måste vi tänka en del från början, och ta till nytta våra specialistkompetenser och tidigare erfarenheter. Vissa fel i hur vi tänker från början går däremot inte att upptäcka genom ett gediget förarbete. Vi måste istället observera och uppleva lösningar under användning för att identifiera nödvändiga justeringar och gå vidare. Det mest kraftfulla upplägget avseende kravinsamling och kravhantering är en balans mellan att tänka tillräckligt rätt från början och att vara lyhörd för ändringar sen. Genom att tillämpa täta avstämningar mellan leveransteam och verksamhetsrepresentanter, och genom att var mottaglig för fel och möjligheter så kommer vi att få ändrade eller nya krav längs vägen som leder till bättre lösningar än vad vi tänkt från början. 

Jag och mitt team har hållit utbildningar inom kravhantering och test i över tio år. I vår roll som utbildare kommer vi i kontakt med hundratals individer och kundorganisationer varje år. När vi delar erfarenheter med varandra får vi en känsla för vad som orsakar framgångar och misslyckande samt vilka trender som är på gång. Ibland kan en trend handla om att se på befintliga arbetssätt, tekniker och metodiker med nya ögon. Ett sådant arbetssätt är sprintdemon, även kallad för leveransdemo eller release-demo. Arbetssättet har varit väletablerat i Sverige under en längre period. De flesta svenska organisationer utövar någon variant på regelbundna demonstrationer där teamen samlas för att vissa upp och diskutera resultatet av arbetet som är hittills klart. När jag ställer frågan ”Vad är syftet med sprintdemon?” i klassrummet brukar jag få svar i stil med ”för att vissa hur långt vi har kommit”, ”för att få bekräftelse av vad vi gjort” eller ibland ”för att få återkoppling kring hur vi kan göra bättre”. Dessa svar är inte långt ifrån ett av många offentliga beskrivningar som man kan hitta, till exempel denna på scrum.org: 

Sprint Review:

“… During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. …” 

En trend som jag ser i vissa kretsar, och som jag gärna provocerar fram för att den ska etablera sig bredare, handlar om just hur vi ser på syftet med en sprintdemo. Syftet med en sprintdemo är att upptäcka fel. Om vi bara skulle bekräfta framgång skulle vi då inte behöva en sprintdemo, utan då skulle det vara bortkastad tid för alla inblandade.  Jag hade en deltagare på kursen ”Effektiv kravhantering” nyligen som piggade till sig när jag sade så. Hon berättade att på sin arbetsplats (en stor aktör inom finansbranschen) hade de nyligen infört ”fail fika”. Tanken med ”fail fika” var att etablera en kultur där det är okej att misslyckas snarare än något att undvika eller skämmas för. Genom den geniala ”fail fika” införde organisationen en ny, positiv syn på misslyckande (”fail”) och ett konkret arbetssätt (”fika”) för att dra lärdomar. 

I detta inlägg har jag berört ett par utvalda trender bland alla som vi tar upp i vår föreläsning ”Trender inom kravhantering” (premiär maj 2019). Dessa två trender handlar om en ny, mer positiv syn på misslyckande som ett nödvändig sätt att utvecklas, samt behovet av att ge plats till innovation för att skapa konkurrenskraft. Genom vår ”failure” under testning eller demonstrationer får vi värdefull information, inte bara om vad vi har klarat av utan även var och hur vi tänkte mindre bra från början. Ibland kan upptäckta fel leda till innovationer och oväntade framgångar, så länge vi jobbar på ett sätt som ger utrymme för lessons learned. Nästa gång ditt team misslyckas är det kanske dags för en ”fail fika”.

När det blir så här:

Kan ni göra så här:

Dela artikeln