Software bliver stadigvæk bygget på antagelser, anekdoter, idolisering og af hierarkiets prestige.

onsdag den 31. januar 2024

software: en potentiel mulighed for en virksomhed eller organisation for at understøtte målsætningen omkring enten at innovere, øge den forretningsmæssige økonomiske værdi eller på anden vis være bedre stillet ift. effektivitet og produktivitet.

software: eksterne eller internt vendte produkter, features, komponenter eller systemer, som har til formål at adressere ovenstående.

Da Jan og jeg for nogle år siden indledte vores samtaler og diskussioner omkring vores erfaringer og udfordringer i og med organisationer, som bygger software, var omdrejningspunktet, at mulighederne for at supportere og lære organisationer nogle bedre vaner i forbindelse med softwareudvikling, var ret store.

En af de udfordringer, vi begge har og havde været så stor en del af tidligere, er det faktum, at software ofte bliver drevet med udgangspunkt i en "god idé", ofte enten udklækket hos en leder eller et stort ego, men hvis hypoteser aldrig bliver valideret i den virkelige verden.

Vi var begge overbeviste om, at modenheden i organisationer og virksomheder skulle testes og valideres, fordi vores hypotese omkring ovenstående ikke var andet end vores egen pendant til "god idé", og vi vidste naturligvis heller ikke, hvad den virkelige verden ønskede sig, før vi involverede os i den.

Vores egen forventning var, at vi i det mindste kunne få taletid omkring vores budskaber hos virksomheder, der set udefra kæmpede med at få det meste ud af deres softwareorganisation.

Vi har aldrig nogensinde villet agere på samme vis som den typiske konsulentvirksomhed, hvor mantraet i grove træk alt for ofte er "gør som vi siger, fordi vi siger det" eller "I gør det forkert, I skal gøre sådan her". Det er en pinlig bevisførelse og på mange måder en arrogant og manglende kontekstforståelse, som desværre lever i alt for stor udstrækning i vores branche.

Vi havde selvfølgelig antagelser omkring vores hypoteser. Nogle skulle også vise sig at være korrekte. Men grundlæggende skulle det vise sig, at vi hurtigt blev udfordret af, at stort set ingen var interesseret i at blive fortalt, at deres initiativer og idéer ville nyde godt af at blive udfordret et andet sted end virksomhedens tankeland.

"Jeg har bygget software i 30 år uden at have talt med en eneste bruger," - softwareudvikler ansat i en softwarevirksomhed.

Vi ville ind tidligere.

Når vi oplevede teams på nært hold og betragtede deres udfordringer sammen med dem, var deres udfordringer sjældent af synderlig teknologisk karakter. Bevares, kompetente (tekniske) mennesker, som forstår, at målet for deres arbejde i virkeligheden ikke handler om at skrive kode eller tegne streger imellem systemer, skal man naturligvis gøre sig en smule umage for at tiltrække.

Men vi ville ind længe før den første linje kode, den første tegning på en tavle eller første skærmbillede blev udfærdiget. Vi ville ind der, hvor ledelsen begyndte at tro på, at virkeligheden for deres initiativer og idéer stemte overens med det tankeland, de befandt sig i.

Og det ville vi udelukkende for at spare dem for den potentielle hovedpine og de langstrakte perioder, som ud fra vores erfaringer fortalte os, at tiden brugt på endeløse møder, rygklapperi og monologer fra dem med mest senioritet, var tid, der ikke kom igen. Vi ville ind der, hvor vi kunne hjælpe med at udfordre deres billede af virkeligheden og hjælpe med, hvad det rigtige var for dem at bygge.

Hvorfor noget er en god idé, er jo et valideringspunkt, som skal udstilles og testes, ikke fordi idéen er dårlig, men fordi idéen er værdiløs, før den resulterer i noget virkeligt i den virkelige verden. Du kan ikke se ind i fremtiden, og selvom du gerne vil have ret, så er det en yndefuld egenskab hos mennesker at hvile i, at det er helt okay at tage fejl og derefter komme videre. Deraf "fail fast".

Af samme grund eksisterer der i rigtig mange virksomheder en forberedelse, som er fuldstændig uforløst, fordi initiativer ofte har det med at udspringe mere på baggrund af en leders stjerner på skulderen end på baggrund af at have brugt energi på at forberede sig og validere sine hypoteser, så det man producerer rent faktisk også stemmer overens med det, som virkeligheden efterspørger.

Vi ville ind der, hvor vi fik mulighed for at supportere og lære organisationen og lederne nye vaner, som de i forlængelse af os kunne bruge i deres egne organisationer.

Lederne blev et nøgleord her, fordi vi fandt ret hurtigt ud af det, som vores egen hypotese blev valideret ud fra - at det er de færreste organisationer, som er designet og drevet på baggrund af nutidige muligheder om at skabe et bedre miljø og fundament for ens softwareorganisation. Vi fandt ud af - vi havde allerede en antagelse herom - at langt størstedelen af organisationer til stadighed er designet på en måde, som helliger enkeltpersoners position frem for den samlede enheds kapacitet.

Kommunikation er i dag helt og aldeles gratis. Hvorfor ønske sig en leder, hvis rolle det er at kommunikere oppefra og ned? Hvorfor have en leder bestemme, hvordan et team skal adressere en given problemstilling?

Der ligger et enormt ego gemt i, hvordan de triangulære organisationer er designet, og det er også vores klare overbevisning, at det er en kæmpe fejl at lade enkeltpersoner udøve sit ansvar på baggrund af idéen om, at det de foretager sig, må være rigtigt, fordi ellers ville de jo kunne opleves som inkompetente.

Hvis en enkelt person er så dygtig til at komme med svarene, så lad vedkommende sidde ved klaveret og spille med, indtil sangen er færdig.

Vi arbejdede sammen med et par virksomheder og i teams, som har været ret fantastiske i deres evne til at organisere sig og forankre det mandat, autonomi og ansvar fra en kompetent ledelse. Det har været en gave at opleve, hvordan nogle organisationer evner at skabe en sådan arbejdsplads.

Men vi har fundet det afsindig svært at komme ind på det tidspunkt, vi gerne vil ind på. Idéer har det nemlig med at være sejlivet, og jo flere klap på skulderen ophavsmanden modtager, jo større energi får idéen. Vi har simpelthen ikke været gode nok til at få vores argumenter plantet, især omkring det at skulle forbedre organisationens evne til at forberede sig "inden vi går i trykken".

Default er den gode idé.

Vi havde specielt et engagement, som skulle vise sig at være en lærerig oplevelse. Vi har aldrig haft et ønske om nogensinde at gå ind i et udviklingsforløb med mindre, der foreligger en afklaring omkring hvorfor det forløb eksisterer, og hvad grundlaget for beslutningerne er baseret på.

Vi har hverken tid eller lyst til at bruge andre folks penge på at lave noget, som ikke kan understøttes med data fra virkeligheden. Det har været hele vores eksistensgrundlag ikke at omdanne en såkaldt god idé til noget, der alligevel ikke gav mening.

Så vi starter aldrig med at tegne diagrammer eller designe systemer på en tavle, eller sidde i møder og snakke om, hvem vi skal købe hvad fra og hvornår.

Vi arbejder med mennesker i den virkelige verden, og lader dem skyde med skarpt på baggrund af de hypoteser, der opstilles, så vi på den måde kan få indsamlet evidens og dannet grundlag. Det er sådan, det er nødt til at være, taget alle de forgangne års fejlede initiativer i betragtning.

I det her tilfælde – vores lærerige eksperiment – havde vi indledt en dialog med en virksomhed, som var så forblændet af deres egen idé, at selvom de godt kunne se værdien i at få den valideret i den virkelige verden, så var deres tro på idéen så stor, at de valgte at udvikle produktet i stedet for først at teste dets hypoteser af.

Det fik os alligevel til at indse og begribe omfanget og alvoren omkring idéens magt og dens tag i menneskerne, der er investeret i den. Det var jo ikke fordi vi ikke havde set det før – vores data viser os, at 80% af alle virksomheder, vi har været en del af, bygger software på den baggrund – men det kommer alligevel bag på os, hvor vigtig ens egen virkelighed synes at blive brugt som drivkraft for en idé.

Det har samtidig også vist sig flere gange, i andre kunderelationer, at når et team finder det udfordrende at vide, hvilken retning noget skal bevæge sig i, så default'es der ofte til den "gode idé", som så alligevel senere viser sig at være ingenting værd.

Af samme grund mener vi, fordi vi har været i de her forhold mere end bare et par gange, at det er langt mere værd at forberede sig langsommere end at bygge hurtigere. Du kan ikke snyde dig til evidens eller bruge ude-af-kontekst data fra andre. Du er simpelthen nødt til at teste og validere dig frem til dine egne data omkring den kontekst, I befinder jer i, og det kan spare dig for mere end bare tid og penge.

Vi anser os selv som en del af den bevægelse, som udover at være kompetente og passionerede omkring vores virke, opfatter og oversætter den agile filosofi og kultur som noget, der handler mere om at blive klogere på det, man bygger, frem for at gætte sig frem igennem lukkethed og ubarmhjertige vilkår. Altså handler det om at bygge det rigtige ved hurtigt at kunne modtage feedback fra den virkelige verden.

Jeg er et eller andet sted rigtig ked af, at agile har fået så dårligt et "rep", men med indførelsen af de ellers så smukke og pragmatiske muligheder, i hvad der syntes at være uforanderlige organisationer, er de på sin vis blevet misbrugt som en knækket løftestang, med troen på, at kulturændringer kan læres igennem kurser, tegninger, certificeringer og titler.

Kvalitet går langsomt men I vil hele tiden gøre tingene hurtigere.

Loven om "leaky abstractions" får hvert år en stadig større betydning for alvoren om, i hvilken retning branchen bevæger sig, når der laves investeringer i forbindelse med at forbedre den produktive og effektive tilstand for alle virksomheder, som bygger software.

Prøv for sjov skyld at se på, hvad der er blevet talt om på diverse konferencer, samt hvilke litterære værker der er udgivet de sidste 10 år, og frem til i dag, også dan dig dit eget billede af, hvor langt du egentlig synes, vi som branche har rykket os. Læg dertil din organisations forandring oveni.

Hvis du med fuldstændig ro kan sige til dig selv, at med flere af de samme abstraktioner, er vi blevet bedre, så chapeau til dig. Godt gået. Really!

Udfordringen er bare, at jo flere abstraktioner vi smider ovenpå hinanden, des mere skal vi forholde os til. Så selvom abstraktionen synes at gøre os i stand til mere, er der i samme ombæring mere, vi skal jonglere med. Så med en pseudo-forøgelse af produktivitet eller effektivitet medfølger der et stadig større kognitivt og økonomisk pres.

Jeg finder det glædeligt, når de mennesker, hvis litteratur jeg ynder at læse, eller hvis karriere jeg finder nogenlunde tidsløs, til stadighed beviser, at de "nederste" abstraktioner stadig er dem, som er mest betydningsfulde for, hvordan tingene reelt hænger sammen. Men jo længere jeg bevæger mig op i abstraktionerne, jo længere bevæger jeg mig imod popkulturens karakteristika om fuckability, larm og hurtige resultater.

På den måde finder jeg meget lidt tvivl omkring, at Jan og jeg desværre har været klemt op i et paradoksalt hjørne. De mennesker og virksomheder, der godt ved, hvordan man gør, har nemlig ikke brug for sådan nogle som Jan og jeg. Dem, som vi mener godt kunne bruge vores viden og data, enten leder de forkerte steder, eller også ønsker de, bevidst eller ubevidst, at mærke frustrationerne igennem deres egne erfaringer, og for sig selv.

Udviklingen af teknologi går stærkere, end vi når at forholde os til den, og det er svært at få øje på - bl.a. taget loven om "leaky abstractions" i betragtning - hvordan flere abstraktioner skal hjælpe os til rent faktisk at blive bedre. Det gælder ikke kun IT; det er ligeså udtalt en bekymring andre steder i verden. Bare kig op og se, hvem der forsøger at sælge dig mere teknologi.

Personligt finder jeg kvalitet andre steder end i teknologiens verden. Kvalitet for mig er en helt anden størrelse, og det kan være betagende at sidde og betragte historien og kurverne omkring den.

Når jeg nu sidder her og kigger på de materialer, som er brugt, og det håndværk, som er udført, på mit svenskbyggede sejlskib fra 1986, så bliver jeg hele tiden overrasket over, at nogen har formået at lave noget, der "lever" i så barske omgivelser (vand, salt, sol og vind), og som stadig er så holdbart og driftsikkert. Det er kvalitet.

Eller når jeg studerer min instruktionsbog til min Mercedes OM636, og det gør jeg flere gange om året, så falder jeg fuldstændig i staver over, hvor detaljeret og veldokumenteret det produkt er. Det er for mig en enestående oplevelse at sidde der og prøve at forstå, hvordan man kunne samle et team, og rent faktisk komme i mål med at udvikle noget så velfungerende og smukt. Det er kvalitet.

Jeg har derimod absolut ingen forventning til, at vi alle sammen skal hellige den samme forståelse eller ønske om kvalitet. Det ville være en yderst arrogant forventning. Men den laveste kvalitative fællesnævner må i en professionel setting adresseres, inden man bygger software, fordi den, udover at have betydning for selve kvaliteten af resultatet, også har en betydelig indflydelse på de mennesker, som deltager i forløbet omkring og i udviklingen.

Kvalitet kan udover at være en holdning også samtidig være en skrøbelig tilstand, som kræver, at en organisation udviser kurage og tryghed overfor de mennesker, hvis tilstedeværelse og energi de trods alt har et betydeligt råderum over, og som der er en forventning til, kan stemple ind.

Lederens rolle

En sideeffekt af de ting, Jan og jeg har oplevet i vores virke sammen, har bl.a. været, at de ting, som har været et velkendt negativ i årtier, stadig i stor udstrækning bliver brugt som støttekrykker, også selvom branchens kompetente og velansete litterære og udøvere har formidlet viden og statueret grundige eksempler på, at de er mindre gunstige ift. at drive udvikling af software.

Vi har måttet sande, at organisationer til stadighed er forankret omkring et triangulært organisationsdesign, hvor levn fra den traditionelle "switchboard manager" stadig har til formål at kontrollere og kommandere.

Organisationer har haft den udfordring, siden kommunikation er gået fra at være dyrt til at være gratis. Og de sidste 15 år har kommunikationen altså været gratis. Derfor har en af lederens primære roller ændret sig, fra ikke længere at agere bindeled imellem teams eller ledelse, sidde i toppen af trekantens snævreste linjer og kommandere nedad og rapportere opad.

Sådan ser verden ikke ud i dag, og jo før man accepterer det, des mindre vil det gøre ondt på ens organisation. Inden General Motors gik konkurs, bad en VP i GM om, at man fotograferede hele fabrikken hos Toyota, fordi GM måtte kunne opnå den samme mulige succes, hvis de blot kopierede Toyota-fabrikken.

At kommunikation er gratis, har de færreste organisationer grundlæggende accepteret – der er stadig alt for meget institutionel indoktrinering og hierarki (jeg kunne godt tale om ægte diversitet samt inklusion) – og det koster til stadighed virksomhederne rigtig dyrt.

Vi har set og været en del af teams, som er blevet bedt om at vente på, at et andet menneske i virksomheden er blevet færdig med sit eget arbejde, før et 10, 20, 80 personers team kunne komme videre.

Vi har oplevet, at teams skal sende support-emails for at ville udgive sin software.

Vi har oplevet, at et team ud af mange teams har bestemt, hvordan alle andre teams skal strukturere deres arbejde.

Vi har deltaget i agile transformationer. Sågar DevOps transformationer. Vi har endda selv brugt ordet digital transformation, fordi vi troede, vi kunne sparke døren ind hos dem, der alligevel ikke vidste, hvad det betød.

På et tidspunkt vil medarbejdere, som sidder fast i flaskehalse, magtesløshed, endeløse ligegyldige agenda-løse møder om tankeland, venten på såkaldte nøglepersoner, ikke længere acceptere, at de ikke kan udnytte deres eget voksne råderum og tage affære igennem deres egne kommunikationsstrukturer.

Så når samfundsdebatten også er koncentreret om spørgsmålet om, hvorfor vi skifter arbejde som aldrig før, og virksomheder har hamrende dygtige mennesker væltende ud af bagdøren, så tror jeg ikke, det er forkert at pege på det her som en betydelig udfordring.

Det har heldigvis vist sig at fungere langt mere effektivt at lade sine teams og medarbejdere eje ansvaret og have mandatet til selv at kunne gøre det, de mener er bedst for den forretningsmæssige egenskab, de har fået stillet i sigte.

"Organisationen", som de fleste af os har været i berøring med som professionelle, er i Jan og min lille bog, mega udfordret. Ikke blot fordi den ikke længere formår at bevise sit værd på et organisatorisk plan, men fordi verden er så forandret, at vi som mennesker ikke længere kan se os selv navigere i sådan et hierarki.

Da jeg mødte Said, en tidligere lektor på CBS, og min tidligere og helt igennem fantastiske kollega i Microsoft, sagde han til mig: "I er 10-15 år for tidligt på den, der er ikke mange som forstår, hvad det er, I forsøger."

Vi koncentrerer os ikke synderligt om fremtiden, vi koncentrerer os om, hvad vi har nu og her, og hvad der kommer i morgen, må vi forholde os til dér.

Vi har fået valideret et par af vores egne hypoteser igennem dialog og smørrelse med vel omkring hundrede virksomheder.

Vores idé om at få virksomhedens initiativer ud af tankelandet med målet om at:

• Eksperimentere og validere sig frem til det, hvad der er rigtigt at bygge.
• Supportere lederne ved at etablere gode vaner i og omkring sin softwareorganisation.

Hvis du vil have flere detaljer, må du tage kontakt til mig.