allan ebdrup bloghoved ny

Mangler der tillid til udvikleren i din virksomhed?

Hvordan opbygger vi tillid i vores arbejdskultur?

Det spørgsmål har jeg, mere eller mindre bevidst, været optaget af, siden jeg blev leder for et udviklingsteam for ca 1½ år siden. Og i dag har jeg fået et mere naturligt udgangspunkt i tillid. Det har været en spændende personlig rejse. Jeg er så heldig, at vi nu har en hel udviklingsafdeling, hvor arbejds-kulturens fundament er tillid. Mine gode kollegaer hjælper mig hver dag.

Et personligt eksempel, Enterprise-Arkitekten

Da jeg, på en tidligere arbejdsplads, arbejdede som enterprise-arkitekt skrev jeg et dokument med firmaets reference-arkitektur. Ledelsen havde bedt om en reference-arkitektur, fordi de havde set andre organisationer have en.

Jeg syntes selv, at jeg havde gjort et meget godt job; skrevet den kort og forklaret hvorfor hvert punkt var med. Det var vigtigt for mig, at jeg var imødekommende. Jeg skrev i indledningen at reference-arkitekturen bare var vejledende. Man måtte gerne bruge komponenter, der ikke var nævnt, men så skulle man lige vende det med arkitekten - altså spørge om lov.

I dag ser jeg tydeligt det forkerte i, at jeg ville have intelligente, selvstændige mennesker til at spørge mig om lov, hvis de vil gøre noget andet, end hvad jeg har beskrevet som ramme i et teknisk dokument.

Der, hvor jeg arbejder I dag, har vi har bevidst ingen IT-arkitekter af nogen art. Samtlige udviklere har titlen “Senior Software Developer”. De eneste andre titler er for dem med personaleansvar.

Hvis vi vokser til en størrelse, der nødvendiggør IT-arkitektrollen, vil jeg indføre den som et service-organ. IT-arkitekterne vil komme på banen, når teamet beder om deres hjælp, og teamet vil selv tage beslutningen om, hvordan tingene skal gøres. IT-arkitekten vil altså ingen ‘magt’ have, udover hvad hun/han kan ‘sælge’ til teamet og overbevise teamet om.

Når du er dygtig, vil du helt naturligt forsøge at få andre til at gøre ‘det rigtige’. Det er helt i orden. Men gør det uden at diktere din ‘lov’. Overbevis i stedet - og vær indstillet på at gå langt for at sælge din idé. Vær indstillet på, at i første omgang kan du måske kun få teamet til at lave en prototype, der bygger på dine idéer, for at få noget mere empiri for at idéen er god. Byg eventuelt prototypen selv. Vær rede til at indrømme, at du tog fejl.

Det følger naturligt, at den eneste måde du kan sælge dine idéer, er ved at sætte dig i andres sted. Du skal gøre en indsats for at forstå deres hverdag.

Teamet skal leve med de valg, der bliver taget. Det er dem, der ved bedst.

Princippet med at ‘sælge’ din idé, overbevise og sætte sig i andres sted i stedet for at diktere ved ‘lov’, er en hjørnesten i kulturen mellem udviklerne på vores teams.

Lederen

Tillid skal også gennemsyre den måde, man agerer på som leder. Formodentlig ikke overraskende, men lad mig tage noget som jeg mener, måske kontroversielt, ofte er et eksempel på dårlig ledelse: Deadlines.

Deadlines kan være forfærdelige størrelser. De får folk til at tage uigennemtænkte valg, som man skal betale prisen for igen og igen, når løsningen er umulig at vedligeholde, udvikle videre på eller performer dårligt. Derudover stresser deadlines udviklerne.

Der er to grunde til at lederen opstiller deadlines.

Den første grund er, at du har planlagt arbejdet så dårligt, at du ikke kan være færdig til tiden, medmindre du bruger deadlines til at presse dine udviklere.

Løsning er her, at lade være med at tage mere arbejde ind, end du kan nå at levere i ordentlig kvalitet. Det kan vi tillade os, fordi vi bygger et produkt, som skal leve og videreudvikles i mange år.

Selvfølgelig har vi også deadlines en gang imellem. Men de fleste af disse kommunikerer vi overhovedet ikke til teamet. I stedet sørger vi for at planlægge os ud af det, så vi som udgangspunkt kan være færdige mindst en måned før deadline. For som jeg skrev, fører deadlines til dårlige valg.

Den anden grund til at have deadlines er manglende tillid til udviklerne.

Hvis jeg ikke får mine udviklere til at estimere opgaver og committe sig til en deadline, så bruger de bare fire dage på en opgave, der kun burde tage to dage.

Det er et virkeligt eksempel; sådan er der ledere, der tænker!

Prøv i stedet at lade udvikleren gøre arbejdet uden en deadline. Hvis udvikleren har svært ved at holde næsen i sporet og lige skal fikse noget mere hele tiden, så tag som leder en samtale med udvikleren om det.

På vores teams er der meget få udviklere, der har tendens til at blive distraheret. Jeg ser det som en styrke at have nogle få udviklere, der går så meget op i kvalitet, at de ikke kan lade være med at rydde op, hvor end de kommer i koden. De udviklere har gjort utroligt meget gavn på den lange bane med deres oprydning.

Vi lader udviklerne arbejde uden deadlines og tager i stedet samtaler med den enkelte, hvis hun/han ikke kan få færdiggjort sin opgave. Gennem denne coaching er udviklerne nu blevet i stand til selv at stoppe op, når opgaven er ved at stikke af fra dem. De kan lede sig selv og færdiggøre arbejdet til tiden, helt uden deadlines.

Ingen tillid ingen innovation

Da jeg først blev opmærksom på tendensen til at ville bestemme, og hver gang tænkte: “Kunne vi gøre det her på en anden måde?”, så ændrede min opfattelse af verden sig. Nu ser jeg problemet overalt i IT-afdelinger. Den manglende tillid - der ikke bare ødelægger glæden ved arbejdet, men også ødelægger produktiviteten.

Man kan ikke være produktiv, når man hele tiden skal spørge om lov og er stærkt begrænset af stramme rammer.

Manglende tillid er et udbredt fænomen. For egen regning, vil jeg påstå at opgøret med den manglende tillid, også er det der manifesterer sig i The Agile Manifesto’s “Individuals and interactions over processes and tools”-princip.

For at have succes med tillid er det min erfaring, at den skal gå hånd i hånd med en lyst til at eksperimentere og udforske. Tag ejerskab over udviklingsprocessen. Den skal udvikles løbende og eksperimenteres med. Roller skal omdefineres og ansvar omfordeles. Møder skal afskaffes eller formen laves om. Afdelinger skal nedlægges. Som led i vores udvikling har vi afskaffet både QA og driftsafdeling. QA er erstattet af at bygge kvalitet ind i udviklingsprocessen og driftsafdelingen er erstattet af self-service løsninger i skyen.

Jeg siger ikke, at vi helt har undgået at der en gang imellem er nogen der bestemmer over andre, men vi har reduceret det kraftigt. Vi arbejder stadig videre på at udvide rammerne for tillid.

Fokus på tilliden i dette blogindlæg et bare et nedslag på ét aspekt af mange, der former vores kultur i udviklingsafdelingen. Det kan ikke stå alene. Nogle andre aspekter er:

  • Vær tæt på kunderne. Få en klar forståelse af, hvorfor vi gør, hvad vi gør, og hvilken effekt det har.
  • Personerne i teamet er i centrum for at løse opgaven med alle deres talenter.
  • Lad være med a spørge om lov. Just do it.
  • Undgå bureaukrati og regler.
  • Teams bestemmer i stor grad selv, hvordan de vil organiseres.
  • Nemt at release - continuous deployment.
  • Bekæmp frygt for at fejle - styrk eksperimentering og innovation.
  • Hver fredag bestemmer du selv, hvad du vil arbejde på, så længe det kommer vores brugere til gode, direkte eller indirekte. Tekniske forbedringer er helt i orden.
  • Evaluer sammen, lær og gør det bedre.
  • Vær åben om fejl, du begår.
  • Del viden.
  • Et af vores mål er at levere højere kvalitet, samtidig med at vi gør det hurtigere.
  • Lav open source, du kan være stolt af i arbejdstiden.
  • Deltag i community-events og konferencer.

Men alt det må jeg gemme til andre blogindlæg.

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Niels Buus

Dejligt med en virksomhed der behandler udviklere som medarbejdere der udvikler produktet og ikke som fabriksarbejdere der skal piskes, fordi de ellers bare vil fortabe sig i værdiløse ting som refactoring, der jo ikke giver nogen målbar forretningsværdi.

Det minder mig om en jobsamtale jeg var til for noget tid siden. Her fik jeg at vide at nye stories blev estimeret i fællesskab og at estimatet dannede grundlag for en timeallokering for hver story. Brugte man mere tid end allokeret, så var det for egen regning. Og brugte man mindre, så var det egen fortjeneste.

Det synes udviklingschefen fungerede rigtigt godt. Det gjorde det nemt at budgettere og sikrede at udviklerne performede.

Dog klagede selv samme udviklingschef som jeg var til samtale hos over at kodekvaliteten i virksomhedens produkt var middelmådig, at testdækningen var mangelfuld og at mange af kodebasens afhængigheder ikke var opdateret i årevis.

Jeg tror det var fornuftigt nok at jeg takkede nej til muligheden.

  • 8
  • 0
#2 Anders Gram Mygind

Herligt at høre, at tillid i den grad kan lade sig gøre i IT branchen. Jeg tror der er mange (mellem-)ledere i IT branchen, som vil have svært ved at sluge den kamel. Jeg har oplevet steder, hvor der var et krav om 75% udfaktoreringsgrad udover deadlines samt meget styring på den innovative del af det at være udvikler/konsulent.

  • 2
  • 0
#3 Peter Johan Bruun

Allan, stort kompliment til dit indlæg, du har fat i noget ufatteligt væsentligt, og måske endda det der i sidste ende afgør om en IT virksomhed overlever eller ej. Jeg er under alle omstændigheder imponeret.....

Vi behøves vel ikke at nævne CSC som modstykket ? ;o))

  • 3
  • 0
#5 Deleted User

...kan jeg kun være enig! Jeg startede desværre min karriere et sted, hvor holdningen var, at udviklere bare skulle presses, så skulle de nok levere. Altså, man fik en liste med 20 førsteprioriteter, skulle på stående fod præcis-estimere, og blev talt ned, hvis man brugte længere tid derpå. Ikke et godt sted.

Senere har jeg heldigvis haft fornøjelsen enten at have chefer, der tidligere har været udviklere, eller har en forståelse for den kreative proces, udvikling også er. Selvom jeg arbejder indenfor mobiludvikling i den digitale bureaubranche, er der en følelse af respekt om mit (og mine kollegers arbejde).

Hvis jeg skulle koge dit indlæg ned til ét ord, er det netop respekt. ALT for mange steder bliver udviklere set som et nødvendigt onde... "kodeaber", "nørder", m.fl., som man helst så sparet væk eller outsourcet til Indien for 10% af prisen. Naturligvis får man et shitty produkt ud af det. Derimod, de arbejdspladser hvor der er respekt om udviklernes faglighed, kreativitet, person og professionalisme... er der plads til at tænke selv—hvilket i sidste ende giver bedre produkter og gladere kunder...

  • 5
  • 0
#6 Kasper Tidemann

Allan, mange tak fordi du har delt dine tanker her. Det er uden tvivl noget af det bedste og mest rammende, som jeg har læst om forholdene som softwareudvikler. Dine beskrivelser ligger på linje med mine egne oplevelser på området - desværre, kan man sige.

  • 0
  • 0
Log ind eller Opret konto for at kommentere