Fra it-udvikling til digital innovation

– af Søren Bronnée Sørensen, Viceadm. Partner

Mange virksomheder mener, at de er digitale. De har en række velfungerende it-systemer, som løbende vedligeholdes af den interne it-afdeling, der netop er gået over til en agil udviklingsmetode. Men for at være en digitalt innovativ virksomhed, kræves der mere end agil it-udvikling. Denne artikel gennemgår udviklingen i it-udviklingsmetoder og beskriver, hvordan digital innovation skal suppleres af innovationsmetoder i forretningen.

It-udvikling er, ikke mindst sammenlignet med andre udviklingsdiscipliner som ingeniør- og arkitekturfagene, et relativt ungt område med kun ca. 60 år på bagen. I de første mange år var der mest fokus på at forædle hovedværktøjet – programmeringssproget – og brugen heraf. Men efterhånden som it-løsningerne blev mere og mere komplekse, og samtidig blev mere og mere kritiske for virksomhedernes drift – så kom der fokus på udviklingsmetoderne.

Traditionel it-udvikling

Op gennem 70’erne og 80’erne skabtes de traditionelle it-udviklingsmetoder – de metoder, som vi dag ofte refererer til som ”vandfaldsmetoder”. Det skyldes, at mange af disse metoder blev illustreret som vist i figur 1. dvs. startende i øverste venstre hjørne og sluttende i nederste højre hjørne, som et vandfald faldende fra venstre mod højre.

Figur 1: Generisk model for vandfaldsmetoder

Grundforudsætningerne i alle vandfaldsmetoderne er følgende:

• En potentiel it-løsning kan beskrives på en klar og struktureret måde, således at den efterfølgende kan udvikles.
• Når løsningen er udviklet, så kan den efterfølgende sammenlignes med beskrivelsen for at vurdere, om løsningen reelt svarer til denne.

Arbejdsdelingen mellem forretningen (brugerne) og it-udviklerne har været en central del af udviklingen i vandfaldsmetoderne. I dag er det alment anerkendt, at en vandfaldsmetode baserer sig på en kravspecifikation, der udarbejdes af forretningens brugere og efterfølgende danner udgangspunkt for udviklingsarbejdet. Dette ses også i rammeværker som Prince2 og Statens Projektmodel. Kravspecifikationen spiller også en central juridisk rolle i forbindelse med anskaffelse af it-løsninger fra eksterne leverandører. Kravspecifikationen er det centrale bilag i udbudsmaterialet og kontrakten, der specificerer den leverance, som kunden ønsker fra leverandøren.

Agil it-udvikling

I 2001 mødtes en række softwareudviklere i USA for at definere et egentlig grundlag for agil it-udvikling, hvilket førte til: ”Manifesto for Agile Software Development”. Dette manifest indeholder 12 udviklingsprincipper:

1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Working software is delivered frequently (weeks rather than months).
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals, who should be trusted.
6. Face-to-face conversation is the best form of communication (co-location).
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.

En række af “fædrene” til manifestet var allerede i 90’erne meget aktive i at definere og bruge det agile rammeværk Scrum. Grundidéen i Scrum blev defineret allerede i en artikel i Harvard Business Review i 1986, hvor Scrum var tænkt som en metode til forbedring af industrielt produktdesign. Men det blev it-området, der tog Scrum til sig, og op gennem 90’erne blev it-rammeværket udviklet og indgik som et centralt grundlag for det agile manifest.

Scrum introducerede mange af de centrale elementer, der i dag anvendes i agil udvikling, såsom: product backlog, sprints, product owner og scrum master. Selve Scrum-processen er illustreret i figur 2:

Figur 2: Scrum-processen

Scrum-processen er iterativ. Den bygger på en product backlog, der løbende udbygges af brugerne i form af user stories, der beskriver udviklingsønsker. Scrum Master og Product Owner udvælger en række user stories, der indgår i et sprint, hvor udviklingsteamet udvikler funktionaliteten i henhold til user stories. Efter sprintet er næste version af løsningen klar, der så tilgår Product Owner til accept. I et sprint retrospective evaluerer alle de involverede sprintet og gennemfører eventuelle forbedringer til processen.

De seneste år er der kommet metoder som SAFe (Scaled Agile Framework) og LeSS (Large Scale Scrum), der kombinerer/udbygger den agile proces med f.eks. porteføljestyring og arkitekturrammer. Ikke mindst SAFe er blevet populær blandt større danske virksomheder – netop fordi kombinationen af en agil tilgang og en stærk governance passer bedre til dem end den ”rene” og mere anarkistiske Scrum-proces.

DevOps

Mens vandfaldsmetoderne og de agile metoder begge har fokus på at optimere selve it-udviklingsprocessen, så har DevOps fokus på at optimere processen på tværs af udvikling og idriftsættelse af en løsning. DevOps er rent sprogligt en sammensætning af ”Development” og ”Operations”.

De fleste danske virksomheder har implementeret rammeværket ITIL® (Information Technology Infrastructure Library) som grundlag for deres it-drifts- og support-processer. ITIL er skabt med det formål at sikre en stabil og effektiv it-drift, og bygget op omkring ”changes” som den centrale styringsmekanisme. Når først man har etableret en stabil løsningsdrift, så er enhver ændring principielt en mulig risiko for ustabilitet, som skal minimeres ved at styre ændringen igennem en række veldefinerede processer. Så ITIL har fasttømret en opfattelse af, at udvikling og drift er to klart adskilte hovedprocesser, der bindes sammen af en overlevering af en ændring.

Idéen om DevOps blev første gang introduceret i 2008 – og kommer helt naturligt ud af de agile it-miljøer. Der findes ikke et alment accepteret rammeværk for DevOps – og man kan stille spørgsmål ved, om DevOps kan ses som en egentlig metode. De fleste fagfolk definerer DevOps som agil udvikling kombineret med et ”lean mindset” understøttet af en række ”practices” og en høj grad af automatisering gennem en ”tool chain”.

Devoteam gennemførte i efteråret 2017 en undersøgelse af DevOps i danske virksomheder (Hent undersøgelsen her). Basalt set anvender virksomhederne to forskellige tilgange til etablering af DevOps:

• ”You build it – you run it”. Dvs. udviklingsdelen strækkes langt ind i driftsdelen – understøttet af værktøjer og fuldt automatiserede processer – hvorved en udvikler overtager ansvaret for idriftsættelse.
•  Joint Feature Teams. Dvs. små fælles teams med ressourcer fra både udvikling og drift. Her kan man klare sig med en mindre automatiseringsgrad.

Virksomhederne rapporterer, at den største udfordring, men samtidig også en af de væsentligste forbedringer ved brug af DevOps, er kulturændringen – samarbejdet på tværs af it-organisationen. For det er den ændrede kultur, der giver hurtigere levering af løsninger og løsningsforbedringer.

Digital designudvikling

Fælles for it-udviklingsmetoderne er en basal forudsætning om, at brugerne kan definere, hvad de ønsker sig ud af en kommende it-løsning. Enten i form af krav i en kravspecifikation, eller i form af User Stories i en Product Backlog. Men hvis det ikke er tilfældet, så kan det være nødvendigt at gennemføre en mere åben og kreativ problemløsningsproces. Så hvor it-udvikling fokuserer på at realisere en beskrevet løsning på den mest effektive måde, så har designudvikling fokus på at finde den bedste idé/løsning at realisere. Det er illustreret i fig. 3.

Figur 3: Design og realisering som samlet proces

Bemærk, at figuren ikke forsøger at beskrive selve realiseringsmetoden – den kan være lineær som i en vandfaldsmetode eller iterativ som i en agil metode.

En af de mest kendte metoder til designudvikling er Design Thinking. Metoden, som vi kender den i dag, udspringer af IDEO-miljøet på Stanford University i starten af 90’erne. IDEO er i dag en global virksomhed indenfor design og innovation. Design Thinking bygger på følgende principper:

• Kvalificer problemforståelsen ved at undersøge problemet fra mange perspektiver, men fremfor alt ud fra et menneskeligt adfærdsperspektiv.
•  Kvalificer idéer til løsninger kontinuerligt med potentielle brugere, kunder og andre relevante interessenter for at vurdere idéernes potentiale.
• Arbejd visuelt med repræsentationer af viden og idéer.
• Byg prototyper til at kommunikere og teste idéer til løsninger med relevante aktører.

Der er mange versioner af Design Thinking, men en af de mest ”klassiske” metode-tilgange er vist i figur 4:

Figur 4: Design Thinking metode

I dag findes der andre metoder, som f.eks. Pretotyping og Design Sprints, der udfylder samme rolle som Design Thinking. Design Sprints kan ses som et komprimeret Design Thinking forløb.

Der er mange, der sammenblander agil udvikling og designudvikling. Og det er rigtigt, at de bygger på nogle af de samme principper i form af det iterative, tæt interaktion med målgruppen, hurtig respons på konkrete forslag, mv. Men formålet med dem er stadig forskelligt; agil udvikling skal realisere en blivende løsning, mens designudvikling skal finde den rigtige løsning til realisering.

Designmetoderne har fundet deres vej ind til virksomhederne i takt med, at de er kommet i fokus på kundevendte digitale løsninger. Her anvendes designmetoderne hovedsagelig til to formål:

1. Som metode til udvikling af den bedste brugergrænseflade i såvel kundevendte (customer experience) som interne it-løsninger (employee experience). Bl.a. anvender en stor leverandør som SAP Design Thinking til design af nye interne brugergrænseflader til deres standardsuite.
2. Som metode til digital forretningsudvikling med det formål at skabe øget samlet værdi for virksomhedens kunder. Her arbejdes der med forretningsmodel, value proposition, produkter og services og den samlede kundeoplevelse.

Der er mange danske virksomheder, der er kommet i gang med 1, mens 2 stadig er forbeholdt de digitalt mest innovative private og offentlige virksomheder.

Vejen til at blive en digital virksomhed

Hvad har de virksomheder så gjort, der er længst fremme digitalt? De er gået begge veje. De har gjort deres it-udviklingsproces mere agil, og de har arbejdet med digitalt design i deres forretningsudvikling. Med udgangspunkt i disse opgaver er udviklingsmodellen, der er vist i figur 5, blevet udarbejdet. Modellen viser, at man er nødt til at bevæge sig ud af begge akser – både it- og forretningsmæssigt – for at blive en digital virksomhed.

Figur 5: Digital udviklingsmodel

Der er stadig mange – ikke mindst blandt de små og mellemstore virksomheder – der stadig befinder sig i område 1 som digitale begyndere. De større virksomheder er allerede i gang med at flytte sig, og mange har været i gang i 2-5 år. De bedste af dem har bevæget sig op i område 4 – og er at opfatte som seriøse digitale spillere i deres branche. Der er meget få danske virksomheder, der allerede er digitale ledere.

Det skal understreges, at man som virksomhed godt samtidig kan arbejde med to sæt udviklingsprocesser: en traditionel tilgang, der anvendes på problemer og løsninger, der kan løses traditionelt – og en agil/digital tilgang, der anvendes på f.eks. mere kundevendte problemer og løsninger, der kræver hurtige ændringer med høj ændringsfrekvens. Dvs. man er som virksomhed både i område 1 og område 4 – og har derved en bi-modal operating model.

Overgangen til agil udvikling såvel som digitale designmetoder afstedkommer en række udfordringer for virksomhederne. De mest gennemgående er:

• Sammenkobling af digital experience udvikling med it-udvikling. Der findes ikke standardmetoder, der kombinerer f.eks. Design Thinking og agil it-udvikling – om end der lige nu arbejdes med det i branchen. Det er virksomheden selv, der skal forestå sammenkobling, hvilket ikke er trivielt. Skal det være to helt adskilte processer med overlevering – eller skal det være en sammenhængende proces fra start til slut?
• Værktøjsvalg. It-udvikling fordrer værktøjer, så man har god adgang til ressourcer og kan vedligeholde sine it-systemer i mange år. I arbejdet med user experience kan man mere frit vælge værktøjer og skifte rundt mellem disse.
• Det er meget svært, og nogle gange umuligt, at sammenkoble digital experience udvikling med vandfaldsbaseret it-udvikling. Det er ikke hensigtsmæssigt (og meget frustrerende) at se en hurtig og agil designproces gå over i en mere langsommelig vandfaldsproces underlagt estimering og prioritering i porteføljestyringen. Det er Devoteams erfaring, at en traditionel it-afdeling har sværere ved at arbejde sammen med en digital forretning end en agil it-afdeling.
• Adgang til ressourcer og kompetencer. At arbejde med agil udvikling kræver nye og andre kompetencer end traditionel udvikling. Og ressourcerne med disse kompetencer er svære at tiltrække og fastholde. Mange virksomheder vælger derfor at gennemføre en agil transformation i deres eksisterende organisation. Det er en tidskrævende og svær proces – og ikke alle i den eksisterende organisation formår at omstille sig.
• Design- og agile processer kræver et tæt samarbejde med ens målgruppe. Dette gør udflytning af udviklingsopgaver til ”low-cost” områder mere vanskelig. De fleste danske virksomheder har bygget deres udflytningsmodel på udveksling af specifikationer, der baserer sig på traditionel it-udvikling. Men der begynder at komme løsninger på dette – baseret på digitale kommunikationsværktøjer.
• Virksomhedens brug af Design Thinking er begrænset til at arbejde med user experience. Mange virksomheder har slet ikke udbredt det til at omfatte design af fysiske produkter, serviceydelser, mv. Det kræver en anden type af Design Thinking eksperter med andre kompetencer.

Devoteam vil i kommende artikler komme med konkrete bud på, hvordan en virksomhed kan udvikle sig, både på it-udvikling og den digitale designproces.

ITIL® is a registered trade mark of AXELOS Limited

Vil du vide mere? 

Så er du velkommen til at kontakte Per.

Vi stiller gerne op til faglige indlæg og individuelle møder om emnet.