It-udviklere jubler over opbakning fra eksperter: Kontrol-fikserede chefer ødelægger innovationen


Kontrol-fikserede chefer ødelægger innovationen

AWS re:Invent 2017, Las Vegas: Det kan ikke nytte noget at tale om digital innovation og it-udvikling i verdensklasse, hvis man samtidig holder fast i gamle dogmer og vil være en kontrollerende chef. Det viser ny forskning – og det vækker begejstring hos softwareudviklerne.

Kim Stensdal
ComputerWorld


AWS re:Invent 2017, Las Vegas: Der blev klappet og grinet indforstået adskillige gange under et meget populært indlæg på denne uges store udviklerkonference, AWS re:Invent 2017 i Las Vegas.

Omkring 1.000 af de i alt 40.000 deltagere på Amazon-konferencen var mødt op for at høre et nyt forskningsprojekt. Her har man med udgangspunkt i 2.000 virksomheder rundt omkring i verden undersøgt, hvad der skaber og kendetegner en god it-organisation.

Udgangspunktet for oplægget var DevOps, som er meget i fokus på AWS-konferencen, men budskabet var samtidig, at man ikke kan gå DevOps-vejen med succes, hvis ikke også man er villig til at gøre op med gamle dogmer og vaner.

”Evnen til at udvikle og levere software med hastighed og stabilitet. Det er det, DevOps handler om,” forklarede Nicole Forsgren, der er chief scientist i DevOps research and assessment (DORA) og Ph.D i management information systemer.

”Efter at have undersøgt det i fire år, ser jeg ingen ulemper. Det er ikke sådan, at det ene går ud over det andet,” forklarede hun.

DevOps er for alle – også selvom du får en anden besked

Nicole Forsgren spurgte ud i salen, om der var nogen af de fremmødte udviklere, der havde prøvet at få at vide af chefen eller andre ledere, at den måde, man udvikler og driver software på i de mest fremadstormende it-virksomheder, ikke kan overføres til deres egen virksomhed?

Det kunne de fleste nikke genkendende til med et smil på læben.

Nicole Forsgren kunne dog samtidig oplyse deltagerne om, at det ikke passer – for de arbejdsmetoder og modeller, de dygtigste digitale virksomheder anvender, kan bruges af alle. Og det vil være med succes.

”Budskabet er, at der ikke er nogen undskyldninger. Det her vil virke for alle. Også selvom måske du får at vide, at det kun vil virke hos de andre,” sagde hun.

”Virksomheder med en høj performance i it-organisationen har dobbelt så stor sandsynlighed for at øge profitabiliteten, markedsandelen og produktiviteten.”

”Og det handler ikke kun om økonomi, for nogle gange er der mere i livet end penge,” forklarede Nicole Forsgren og nævnte konkret kundetilfredshed og højere kvalitet af produkter og services som nogle af de gevinster, man kan opnå ved en helhjertet satsning på DevOps.

”Det er også et stort problem, at folk brænder ud i it-branchen. Det kan vi gøre noget ved med det her, så det handler om meget andet end penge.”

LÆS OGSÅ: Her er Danmarks bedste it-arbejdsplads: Aarhusiansk it-virksomhed vinder Great Place to Work for store it-virksomheder

Cheferne skal give plads til fejl og eksperimenter

Jez Humble, der er CTO og medforfatter til bogen The DevOps Handbook og også er med i DevOps-forskningsprojektet, kom med en pointe, der fremkaldte særlig stor jubel blandt udviklerne.

Man har nemlig undersøgt, om virksomhederne opnår bedre og mere stabil software ved at have en traditionel kommando- og kontrol-kæde, hvor chefer og højtstående ledere skal godkende nye ændringer og tiltag. Det viser sig, at det bestemt ikke er tilfældet.

”Det forringer hastigheden signifikant, men gør ikke noget positivt for performance eller stabilitet.”

Endnu værre er det ifølge Jez Humble: ”Der er ikke en ret stor sandsynlighed for, at de folk, der skal gennemgå ændringerne, rent faktisk kan gennemskue, om det vil ødelægge noget i softwaren. Vi kan ikke engang selv gennemskue det som udviklere.”

”Vi kan se, at det faktisk er bedre slet ikke at have nogen ’change approval process’,” forklarede Jez Humble.

”Når du arbejder med små batches og gør brug af minimum viable products, gør det dig i stand til at udforske og eksperimentere. Det gør det muligt at søge og reagere på kundefeedback, og det skaber gennemsigtighed i arbejdet på tværs af værdikæden og giver teams autoriteten til at skabe og ændre,” forklarede Jez Humble.

”Innovation er helt basalt at tage chancer, fordi du forsøger at gøre noget, der ikke er gjort før. Hvis du bliver straffet for at begå fejl, hvor sandsynligt er det så, at du vil løbe den risiko?” spurgte han retorisk ud i salen.

Mindre fokus på værktøjer – mere på kultur

Det er samtidig også vigtigt, at man forstår, at DevOps og moderne udvikling og drift af software kræver en indsats på flere fronter, og at de tekniske værktøjer i sig selv ikke kan gøre den store forskel.

”Der er dem, der forsøger at sælge dig DevOps-in-a-box, men det kommer ikke til at fungere,” forklarede Nicole Forsgren.

”Evnen til at levere software og udvikle software med høj hastighed og stabilitet afhænger af forskellige ting – teknologi, lean management og kultur. Værktøjer og teknologier er det, der faciliterer det. Men uden kulturen dur det ikke.”

Jez Humble tilføjede:

”Værktøjer er fantastiske. Vi elsker værktøjer. Men vi har brug for andre ting også.”

”DevOps er vigtigt, fordi vi har haft agile processer i så mange år, men alligevel mange steder nu har en model, der hedder ’water-scrum-fall’,” sagde Jez Humble – en udtalelse, der blev klappet en del af i salen, for mange udviklere kender nok alt for godt til det med, at man havner et sted imellem to verdener.

Dermed er vi tilbage ved budskabet om, at alle kan gøre det, som de kendte, internationale it-giganter gør med softwareudviklingen – blive langt mere innovative og agile.

Det er eksempelvis det, Amazon står for, forklarede Jez Humble og tilføjede så, at man bare skal gøre sig det klart, at det ikke sker uden videre.

”Det krævede en stor investering og lang tid for Amazon for at opnå det her. Men Amazon er ikke alene – mange andre virksomheder jagter også dette mål."

LÆS OGSÅ: Disse virksomheder vil danske it-folk helst arbejde for: Se de mest attraktive arbejdspladser

Publiceret 2017-12-11


Seneste artikler

7 ting, du kan forhandle dig til i stedet for mere løn
7 ting, du kan forhandle dig til i stedet for mere løn
Hvis du ved lønforhandlingen ikke får dit forventede beløb forhandlet hjem, kan du forhandle om andre ting. Her lister vi de mest gængse ting, ledere bliver mødt med.
Indrykket 15. januar på Informationsteknologi
Systematics logo
Systematic vokser så meget, at hele Aarhus kan mærke det: "Vi vil gerne have, at Aarhus bliver en it-hovedstad"
Systematics kæmpesucces kan mærkes i hele Aarhus. "Nogle vil kalde det et lokomotiv eller ligefrem en vækstmotor. Det betyder, at man kan uddanne sig og få arbejde som softwareprogrammør og så stadig blive i Aarhus," lyder det fra Smilets By.
Indrykket 8. januar på Informationsteknologi
5 tips til lønforhandlingen
5 tips til lønforhandlingen
Kom med om på den anden side af forhandlingsbordet og få 5 tips til lønforhandlingen fra en leder, der har forhandlet løn mere end 250 gange.
Indrykket 1. januar på Informationsteknologi
Miniguide til jobagent
Miniguide: Skab dig den bedste Jobagent
Jobagenten er en gratis service, hvor du hver morgen får tilsendt dugfriske jobannoncer – direkte i indbakken. Da du selv definerer hvilke job, du vil ha’ besked om, er du sikker på at få relevante jobannoncer. Samtidig kan du bruge tiden på noget andet, for Jobagenten gør søgearbejdet for dig.
Indrykket 25. december 2017 på Informationsteknologi
it-komet ComputerWorld
Her er den danske it-branches største komet: Har 10-doblet bundlinien på blot fire år
Årets it-komet: Efter flere forsøg med supersælgere i spidse sko og leaset Mercedes valgte It-afdelingen at fokusere på de eksisterende kunder. Fire år senere er bundlinjen tidoblet. Derfor er It-afdelingen Årets it-komet.
Indrykket 18. december 2017 på Informationsteknologi
Annonce:
Cookies på Jobindex

Vi bruger cookies til trafikmåling og til optimering af hjemmesidens indhold. Der gemmes cookies fra Jobindex og fra vores samarbejdspartnere. Ved at klikke videre på hjemmesiden accepterer du vores brug af cookies. Læs mere om vores cookies.