Jojo, tænker du måske, men de kaster sig jo ud i det og prøver noget af i stedet for bare at give op på forhånd. Det har du helt ret i! Dét synes jeg faktisk også er meget sejt: At de er modige, nysgerrige og frygtløse og bare går i kødet på opgaven.

Dét, der går mig på, er den underliggende manglende respekt for, hvor lidt de ved og hvor meget de underkender, at den manglende viden vil få konsekvenser for resultatet. Det handler om den manglende respekt for, hvad viden og erfaring betyder for resultatet. I værste fald betyder det, at resultatet er ubrugeligt – i bedste fald at det har taget meget længere tid at nå frem til et brugbart resultat.

At det nogen gange lykkes, trods et større tidsforbrug, er med til at opretholde antagelsen om, at man sagtens kan bygge alt muligt selv. Man skal bare kaste sig ud i det. Men det betyder også, at der hele tiden er projekter, der fejler katastrofalt, fordi vi ikke har den nødvendige respekt for viden og erfaring.

Skåret helt ind til benet, handler det om ét ord:

 “Bare”

Jeg har lavet denne lille tegning, der viser, hvad problemet med “bare” er. Forestil dig, at du bliver præsenteret for en opgave, hvor ordet “bare” indgår: “Kan man ikke bare tilføje en knap der?”, “… og så skal programmet bare lægge det sammen” eller “Det skal bare kunne printes, gemmes som pdf og virke på mobil”.

Det er så lille et ord, “bare”, men det dækker over så stort et muligt udfaldsrum, at det kan gøre mig helt svimmel, når jeg hører ordet.

Problemet har jeg anskueliggjort med en lille tegning:

Når man står og kigger op på det, man udtaler sig om, så kan der bag dét, man ved, og dét, man udtaler sig om, gemme sig en masse “overraskelser”. Det kan være større eller mindre komplikationer, udfordringer eller ukendte forhold, der gør, at tingene forholder sig helt anderledes, end jeg tror. Det er alle disse røde søjler, som “bare” kan dække over.

For eksempel når deltagerne i et byggeprogram kaster sig hovedkuls ud i at bygge deres egen seng – men ikke ved, hvad en dyksav er eller hvordan den skal bruges. Det starter så fint med “Hvor svært kan det være at sætte nogle lægter og brædder sammen til en seng?!” og slutter med “Det var da dælens så svært det er at save en 3 meter lang MDF plade helt lige til, når skinnen til dyksaven kun er 60 cm”. En tømrer havde vidst det og haft både viden og erfaring til at finde en løsning. Men uden den viden og erfaring, bliver resultatet derefter.

Et andet eksempel er, når kunden efterspørger en ny funktion i et IT-program: “Hvor svært kan det være at sætte en knap ind der, der lige gør det?”. Men hvis den lille knap “bare” skal tage en masse data, stille dem op i en læsbar og overskuelig tabel, der både kan printes og gemmes som PDF, ja, så er den knap alt andet end “bare”.

Det kan også sagtens ske helt uforvarende internt i teamet. Ind kommer en opgave, der ved første øjekast ser nem og overskuelig ud. Men når opgaven åbnes op, udfolder der sig et mareridt af afhængigheder til andre systemer, behov for opdatering af serveren for at få adgang til en nyere version af et bestemt lille program eller behov for en lille men afgørende ændring i en formular, der gør, at alt indsamlet data ikke kan bruges.

Det skjulte magtforhold

Men det allerværste ved ” bare”, synes jeg faktisk er det skjulte magtforhold, der ligger i ordet. Det kommer til udtryk, når “bare” bliver brugt på den måde, hvor det implicit antages, at dét, som “bare” dækker over, ikke kan være så svært. At der ikke gemmer sig nogen røde søjler og at løsningen ligger lige til højre benet.

For hvis man så betvivler det og mener, at “bare” måske dækker over en masse røde søjler, så får man nemt skudt i skoen, at man har nej-hatten på eller man slet og ret ikke er klog nok til at forstå problemet korrekt. Og fordi de røde søjler netop er skjulte, er de jo ikke til at hive frem som argumenter for, at det ikke er “bare”! Man står tilbage med vage argumenter som, at det ikke føles helt sikkert eller man tror, at der kan være en udfordring.

Men alt andet end nagelfaste argumenter kan ikke tage livet af “bare”. Derfor vinder “bare” alt for ofte – og resultatet er, at man senere i projektet kan evaluere, at det var mere kompliceret end man troede…

Hvad er løsningen?

Det, vi så godt kan lide ved Scrum er, at der er events med det formål at håndtere netop “bare”på en konstruktiv måde uden skjulte magtforhold. For der er jo nogle “bare”, der vitterligt er “bare”. Kunsten er, at få dem skilt ud fra de “bare”, der er fyldt af røde søjler.

Vi har stillet tre scenarier op, der gør det nemt for dig og dit team at vurdere, hvilken slags “bare” I står overfor:

Har I løst "bare" før?

Det er denne slags “bare”, der ikke dækker over uventede røde søjler. Det kan være et både simpelt og komplekst “bare” – men I ved, hvordan I skal løse det og hvordan vejen hen til løsningen er. Med andre ord så har I både den nødvendige viden og erfaring til at “bare” faktisk er “bare”.

Vil I tjekke, at alle I teamet er enige om, hvad “bare” er for en størrelse, så er “Planning Poker” et rigtig godt redskab til lige netop dét. Her kan I nemlig se, om I vurderer “bare” til det samme og tage en snak om, hvorfor I gør eller hvorfor I ikke gør.

Har I løst en lignende opgave før?

Eventen “Refinement” er rigtig god til netop denne snak. Her er formålet at bryde opgaven ned i mindre dele, så den bliver overskuelig og mulig at estimere.

Men det er svært at vurdere, om der gemmer sig røde søjler i opgavens “bare”. Derfor er det en god idé at bruge tid på at lave en oversigt over tidligere opgaver og deres “bare”. Oversigten kan I bruge til at sammenligne den nye og ukendte opgave med. Sæt ord på, hvordan den nye opgave både ligner og ikke ligner tidligere opgaver.

Det er også her en god idé at spørge kollegaer eller eksterne eksperter til råds. Formålet er at afdække udfaldsrummet – ikke at få deres løsningsforslag. Hør dem til, hvad der oftest går galt, hvad de største katastrofer er og hvad deres tre anbefalinger er.

Hvert “bare” kræver sin løsning – men vejen hen til løsningen behøver I ikke opfinde selv!

Er det allerførste gang?

Så er vores anbefaling, at I laver et pilotprojekt. Sæt tid af i et sprint til at blive klogere, så I har et bedre udgangspunkt for at vurdere “bare”.

Pilotprojektet har et særligt formål: At afdække, hvad der kan gå galt og hvad udfaldsrummet er. Det er nærliggende at lave et pilotprojekt, hvor målet er at gøre det så rigtigt, korrekt og godt som muligt. Men det giver ikke de bedste og mest værdifulde erfaringer! I stedet skal målet være at finde frem til så mange fejlkilder som muligt. Det giver nemlig en meget bedre forståelse af, hvad der kan gå galt.

Skal I eksempelvis lave en webservice, er det nærliggende at lave en prototype med fokus på svartider. I optimerer alle enheder, så alt kører så perfekt som muligt og giver den laveste svartid. Så kan I nemlig bekræfte med pilotprojektet, at det er muligt at opnå en bestemt lav svartid.

Men pilotprojektet giver jer ikke nogen viden om, hvad der kan gå galt. Hvad nu hvis der er 1000vis af samtidige kald? Hvad hvis nogen af dem kommer fra en langsom forbindelse og andre fra en hurtig? Hvad hvis der er pakketab på grund af dårlig dækning? Alle de fejlkilder gør, at den opnåede svartid måske slet ikke er mulig at opnå i drift – og måske viser det sig endda, at der er faktorer hos modtageren, der gør, at svartiden slet ikke behøver være så lav.

Respekt for viden og erfaring

Vi håber, at du og dit team kan se, at respekt for viden og erfaring kan lede til bedre løsninger. Det kan nemlig gøre, at næste gang, I hører “bare”, så stopper I op og overvejer, hvilket slags “bare” der er tale om. Og forhåbentlig kan I også vise kunden, chefen, kollegaen eller hvem, der nu sagde “bare”, at “bare” ikke altid er “bare”. Nogen gange betyder “bare”, at der er en masse, vi ikke ved. Og andre gange, så er “bare” lige en linies kode eller tre.

Få vores allerbedste guldkorn direkte i din indbakke

Få vores allerbedste guldkorn direkte i din indbakke

Tilmeld dig vores nyhedsbrev og få vores bedste tips og gode råd.

Tak! Du modtager nu en tjekliste direkte i din indbakke