Arbejdsmarkedet

IT-udviklere jubler over opbakning fra eksperter: Kontrol-fikserede chefer ødelægger in­nova­tio­nen

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.

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.”

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å