Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Jeg fik lidt af min ellers veloverståede juleferie afbrudt af en infight med en erfaren udvikler.
Nu lyder det værre, end det er, for faktisk kan jeg enormt godt forstå, hvor han kommer fra, og derfor bad jeg denne udvikler sende mig nogle flere ord og tanker via mail.
Helt kort fortalt havde jeg lavet et LinkedIn-opslag, hvor jeg udtrykte min frustration over, at udviklere og it-folk altid synes at ville nørde med deres koder, mens vi andre såkaldte forretningsfolk i stedet har fokus på at skaffe nogle flere kunder i butikken.
Nu forsøger jeg jo imidlertid at lytte højere til andre, så jeg læste den lange mail, som den venlige udvikler sendte mig, med stor nysgerrighed.
For hvorfor dælen forstår de udviklere ikke, at vi jo altså ikke kan leve af, at de skal sidde og hygge sig med deres koder og umættelige behov for kodekvalitet? Hvorfor kan de ikke bare fokusere på at få skippet noget afsted, som med det samme er målbart og gør en forskel?
Jeg har lovet den pågældende udvikler, at han kan forblive anonym af hensyn til hans nuværende arbejdsplads, hvor han genkender den potentielle konflikt, jeg beskriver oven for.
Han er imidlertid en ganske erfaren herre i branchen og taler derfor med en del vægt, skulle jeg mene.
Det skriver han
Lad mig derfor give ham ordet og citere lidt fra hans lange mail:
”Over kaffemaskinen kan vi (udviklerne og IT) godt blive enige om, at gammel kode bør skrives om, at der bør skrives unit tests, og at der bør arbejdes med forskellige design patterns. Men når vi står ved tavlen og 'scrumer', er det 'forretningens usynlige hånd', der dikterer hvilke opgaver, der prioriteres højest.
Snarere end at programmører har fået frihed til at lave en løsning på bedste vis indenfor et sprint, er forretnings-deadlines og krav flyttet helt ind i den daglige overvejelse, om det nu også giver værdi at lave refaktorering, code coverage og 'fancy' design patterns.
Man kan risikere at blive beskyldt for at sætte sig i et hjørne og nørkle med sine favoritemner og ikke have sans for, hvad der er væsentligt at lave først.
Det bliver let forståelsen, at programmøren bare skal "løse opgaven hurtigst muligt fra A-Z uden for mange fejl."
Kan godt genkende det
Især den sidstnævnte sætning kan jeg i den grad nikke genkendende til, for det er præcis det, som programmøren skal i mine øjne.
Hvad i alverden skulle jeg da ellers ansætte ham eller hende til?
Imidlertid må jeg også indrømme, at min udvikler-ven kommer med nogle gode argumenter for, hvorfor det ikke er så enkelt endda.
Han har i sin tid som softwareudvikler i det private erhvervsliv oplevet flere omstruktureringer og organisationsændringer i forbindelse med indførelse af tankesættet agil udvikling, som jo er det, han beskriver i citatet ovenfor.
Der investeres i kurser og materialer, så alle har styr på, hvad 'ceremonier' (ikke statusmøder), 'artefakter' (ikke dokumenter) og teamroller (ikke stillingsbetegnelser) er.
På powerpoints ser denne tilgang fornuftig ud, men det er blot ikke uden udfordringer, når vi som iværksættere og ledere skal have udviklerne med.
Svær at efterleve i praksis
Problemet med denne form for tænkning og kultur, der vel bedst kan beskrives som en ”en gør-det-nu-bare-færdig kultur”, er nemlig, at det kan være ganske vanskeligt at efterleve i praksis iblandt mange udviklingsteams.
Et it-team er typisk lavet tvær-funktionelt, så 'alle skal kunne lave alt', men kompetencerne er skarpt fordelt på de enkelte, så førnævnte tilgang kan blive vanskelig at gennemføre i praksis.
Testere skal/kan ikke kode, og programmører kan/bør ikke teste som en bruger af systemet (blandt andet på grund af bias).
Så der opstår nemt en mini-vandfaldsstruktur, der presser udviklingen mere, end den var tidligere.
For eksempel opfattes test som bidragende til flaskehalsen, da 'unittest og automatiserede test' altid kan laves, når koden er lavet og klar til testerne.
Forværres betydeligt
Sådanne problemer forværres ofte betydeligt, når der er tale om større komplekser, hvor (kode-) opgaver ikke kan opdeles (eller ikke bliver opdelt) i 'vertikale' og uafhængige dele, men hvad er så løsningen, hvis denne ”gør det nu bare”-tilgang ikke altid virker i praksis?
Min udvikler-ven og jeg kunne heldigvis blive enige omkring én ting: Listen Louder-filosofien, som jeg efterhånden udviklede for en række år siden, giver også rigtig god mening, når vi taler om det, jeg tidligere ville have kaldt for kodenørkleri.
Pointen er nemlig, at der faktisk vil kunne vindes meget ved, at de enkelte dele i ovenstående processer bliver italesat fra flere forskellige synsvinkler, inden man kommer for langt.
Det kan måske for ledelsen opleves som kodenørkleri.
Men for udviklerne kunne det have betydet, at en fejl ville være opdaget tidligt ved en iteration af løsningen frem for, at den først opdages så sent i forløbet, at der ikke er tid til at løse den, og den derfor sættes på en backlog – prioriteret af forretningen.
Det er således, ligesom så meget andet her i livet, ikke et spørgsmål om enten-eller, men nærmere både-og.
Det dur ikke, at vi som ledere og iværksættere bare presset på og konstant vil i mål før tid, mens det omvendt selvfølgelig heller ikke er holdbart, hvis udviklerne går i unødige detaljer på bekostning af kritiske forsinkelser i deres leverancer.
Det begynder og slutter formentlig ved, at vi skal blive bedre til at lytte højere til hinanden og forstå, hvor vi hver især kommer fra.
På den måde bliver det et samarbejde frem for en infight.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.