Modulet helt kort

Processen i udviklingen af jeres digitale forretningsmodel skal sikre, at den model I ender med både understøtter jeres forretningsstrategier også sikrer, at I bedst muligt kan udnytte de forretningsmæssige muligheder der ligger både i digitaliseringen af jeres eksisterende forretningsprocesser og i nye digitale processer. Udviklingen skal også sikre, at jeres digitale forretningsmodel fortsat kan udvikles og tilpasses, så jeres kunder hele tiden kan få den forretningsmæssige oplevelse som I ønsker, og så I hele tiden kan tilpasse jer og jeres forretningsmodel og digitale processer til det marked som I er i.

Valg af udviklingsproces

Den egentlige udvikling af konkrete løsninger – hvor I konkret bygger løsningerne – til en digital forretningsmodel kan gennemføres på mange forskellige måder. Hvilken vej frem man vælger, og hvilke værktøjer man tager i brug, vil afhænge af mange ting, for eksempel:

• Hvad det konkret er, der skal udvikles – digitale løsninger er mange ting,
• Hvilke ressourcer der er til rådighed,
• Hvilke erfaringer I har
• Hvordan I foretrækker at arbejde

Der findes mange veje at gå, men lige netop til udvikling af digitale løsninger – produkter, services, processer og så videre – er agil udvikling blevet meget populær. Princippet bag agil udvikling er et fokus på hurtig og kontinuerlig værdiskabelse, som beskrevet i modulet Grundprincipper.

Agil udvikling er en struktureret og iterativ udviklingsproces, som på én og samme tid kan give:

• Hurtigt implementérbare resultater,
• Mulighed for en høj grad af løbende brugerinddragelse, og
• Stor fleksibilitet i forhold til løbende tilpasning til ændringer, ønsker og krav

Dermed kan agil udvikling give en god sikkerhed for, at slutresultatet lever op til forventningerne. En af de centrale egenskaber ved agil udvikling er, at der løbende skabes delresultater, som kan implementeres og som derved genererer værdi fra start. Man venter altså ikke med at høste værdi, indtil alle delresultater er sat sammen og det endelige udviklingsmål er nået.

At tage fat på agil udvikling behøver ikke at være svært: Man kan tage det i små bidder. Start med én proces, eller bare en del af én proces, og tænk den agil, gør dén agil, ved at tage værktøjerne og metoderne i brug. Når den del fungerer, tages den næste bid – den næste proces – og sådan fortsætter det.

Den agile udviklingsproces

For nogle virksomheder vil agil udvikling være en ny måde at tænke udvikling på. Det helt centrale i agil udvikling er, at udviklingsprocessen fra start til slut ikke længere er én lang og kontinuert proces. Når man udvikler med agil udvikling, deler man hele udviklingsprocessen op i korte, strukturerede “bidder”, som kaldes “sprints”.

Hvert sprint skal bidrage til det samlede produkt med en ny funktionalitet, som umiddelbart kan implementeres, afprøves og evalueres og lanceres – altså tages i brug! Den agile udviklingsproces er illustreret nedenfor

“Den agile udviklingsproces” af Digitale Forretningsmodeller til Fremtiden under licensen CC BY-SA 4.0

På den måde opnår man hurtigt i forløbet implementérbare resultater, som kan generere værdi. Den samlede løsning bygges på denne måde op bid for bid af funktionaliteter, som bliver udviklet og genererer værdi undervejs, og som kan tilpasses og optimeres undervejs, fordi de allerede bliver testet i praksis.

“Vandfaldsprocessen og den agile proces” af Digitale Forretningsmodeller til Fremtiden under licensen CC BY-SA 4.0 CC BY-SA 4.0

Sammenlignet med den traditionelle kontinuerte udviklingsproces, som ofte kaldes vandfaldsmodellen, og som først for alvor skaber værdi i sin slutningen, består agil udvikling egentlig af en række små og koncentrerede “komplette udviklingsprocesser”, nemlig de enkelte sprints. Hver sprint indeholder både design, udvikling, afprøvning, review og lancering af resultatet, og hver sprint skaber dermed egen værdi. Den samlede løsning er summen af alle de afprøvede og trinvist lancerede resultater.

Vi anbefaler og beskriver i dette modul to konkrete værktøjer til at styre den agile udviklingsproces kaldet Agil Tavle og Scrum.

Ligeledes findes også en række gode værktøjer til at få klarlagt forventningerne til resultatet – både de formelle forventninger og de forventninger, der måske ikke er sat ord på – og til at få lavet gode og brugbare specifikationer på det, der skal udvikles. Vi anbefaler og beskriver i dette modul de to værktøjer kaldet Use Cases og User Stories.

Agile værktøjer

Til at styre de enkelte sprints og sørge for, at de på samme tid er både agile og effektive – altså at de hele tiden kan tilpasses virkelighedens forandringer, når der fx sker ændringer i specifikationer og mål, og samtidigt skrider effektivt fremad – og til at styre den samlede proces, findes der en lang række forskellige metoder og værktøjer. Når den slags værktøjer bliver taget i brug, bliver de en integreret del af den agile proces. To eksempler på den slags metoder er en Agil Tavle og Scrum.

Agil Tavle

Den Agile tavle bidrager til at kunne opretholde benhård og vedholdende prioritering og styring. Styring af varer, opgaver, produktionsplanlægning og så videre. Metoden hedder oprindeligt Kanban og stammer fra Toyota, som angiveligt blev inspireret af supermarkedernes måde at styre deres beholdning af varer på hylderne: Ikke for meget, ikke for lidt, hele tiden tilpasset behovet hos kunderne og på hylden lige netop til tiden. Med andre ord: Agilt.

Den Agile tavle og prioritering af opgaver er de helt centrale værktøjer. På den Agile tavle synliggør man for alle, for eksempel med Post-It-sedler, hvilke opgaver der er prioriteret, og om den enkelte opgave er på “To-Do-listen”, “I gang”, “Under test” eller “Afsluttet”. Opgaver, som ikke er på den Agile tavle, skal ikke løses nu!

Se nedenfor et eksempel på hvordan den agile tavle anvendes med input fra User-Stories.

“Agil Tavle” af Digitale Forretningsmodeller til Fremtiden under licensen CC BY-SA 4.0 CC BY-SA 4.0

Bemærk, at opgaverne ikke nødvendigvis løses i nummerrækkefølge.

Opgaver som er på To-Do-listen er prioriterede og skal udføres. Derefter flyttes opgaver på tavlen trinvist fra To-Do til I gang, til Under Test og til sidst til Afsluttet, og på denne måde bliver både prioritering, flow og fremdrift synlige for alle.

Om en opgave er på “To-Do-listen” kan for eksempel være bestemt af, om den er en del af en Use Case eller en User Story. Use Case og User Story bruges til at beskrive, hvilke behov der skal opfyldes for, at brugeren af det, man udvikler, kan få den ønskede oplevelse i en given situation.

Den Agile tavle er et relativt simpelt værktøj, som tager udgangspunkt i de processer og arbejdsområder, man kender og allerede arbejder med. Indførelse af den Agile tavle kræver ikke, at man “ommøblerer” alle sine processer; i stedet tilpasser man sin agile proces til situationen og virkeligheden.

Fokus i den agile udviklingsproces ligger i virkeligheden på få ting:

• Synlighed omkring det arbejde, som afdelingen udfører
• Prioritering af opgaverne: Fokuser på at gøre de nødvendige ting og intet andet
• Flow i arbejdets udførelse, fordi man fjerner flaskehalse
• Åbenhed omkring hvem, der laver hvad
• Et stop for uproduktiv og frustrerende multitasking – med andre ord: Hold op med at begynde på alt muligt på samme tid og fokuser i stedet på at afslutte det, du gør.
• Løbende feedback omkring afdelingens samarbejde og effektivitet

Dette kan opnås ved at anvende værktøjet Agil tavle. Gevinsten er både bedre produktivitet, færre fejl, og større tilfredshed blandt medarbejderne.

Ønsker du at vide mere om den Agile tavle, kan du i modulet Implementering læse om hvordan værktøjet alternativt kan anvendes.

Scrum

Scrum er en effektiv metode til at styre hele den agile udviklingsproces, og den kan også bruges til sikre den efterfølgende udviklingsmæssige vedligeholdelse af resultatet. Scrum er egentlig mest beregnet til komplekse produkter og løsninger, men metoden kan sagtens tilpasses til udvikling af mindre komplekse ting. Oprindeligt var Scrum tænkt til udvikling af software, men i dag bruges metoden på kryds og tværs af alle brancher, som udvikler produkter, og den kombineres også med andre metoder.

Med Scrum opdeles af den samlede udviklingsproces i korte tidsbegrænsede forløb kaldet sprints, og hver sprint er karakteristisk ved, at både opgaverne der skal løses og målet der skal nås i en sprint er fastlagt, og at resultatet af en sprintet potentielt skal kunne lanceres, f.eks. som en delfunktionalitet i det samlede produkt – og dermed blive værdiskabende – straks når sprinten er afsluttet.

I den tid en sprint varer, mødes alle deltagerne dagligt til “den daglige scrum”, et kort stående møde hvor hver deltager meget kort – fx på maksimum ét minut – gør rede for sine udførte opgaver dagen før, sine planlagte opgaver i dag, og om der er behov for hjælp til noget. Status, dagens udfordringer og eventuelle ændringer diskuteres under ledelse af en fast ”Scrum Master”.

Ved afslutningen af den enkelte sprint holdes et “Sprint Review”, hvor sprintens resultater gennemgås, og hvor listen over resterende opgaver tilpasses. Med passende mellemrum holdes desuden et såkaldt “Retrospective”-møde, hvor man især har fokus på at lære af processen og på at bruge læringen efterfølgende.

Hver sprint starter med en struktureret planlægning, hvor berørte medarbejdere kan bidrage. Resultatet er en liste over de prioriterede opgaver i den kommende sprint. Listen kaldes en Backlog. Den svarer til “Skal-gøres / To-Do”-listen i Kanban. Input til de opgaver, som skal løses, kan fx komme fra Use Cases og User Stories. I løbet af sprinten skal opgaverne på backlog-listen udføres – og kun disse opgaver.

User stories

Use-cases og User-stories er to metoder som bruges til at identificere og beskrive hvilke brugerbehov, der skal opfyldes. Målet er at sikre, at brugeren af et produkt, en funktionalitet eller en ydelse får den oplevelse, som man ønsker som leverandør til brugeren. I sidste ende handler det om at sikre, at brugeren agerer som ønsket, og at man som leverandør til brugeren får det resultat, man ønsker.

De brugerbehov der identificeres gennem Use-cases og User-stories kan med fordel anvendes som input til den agile udviklingsproces og værktøjet Agil Tavle, der er beskrevet tidligere i modulet.

User-story

En User-story er en kort beskrivelse i “historieform” af fx hvad en kunde skal kunne gøre og opnå, når han eller hun besøger en webside eller måske bruger et bestemt produkt. Fokus er på hvilken værdi eller hvilket resultat, de opnår. User-story bør altid skrives fra brugerens synspunkt og i det sprogbrug, som brugeren forventes at have.

En User Story skrives gerne med udgangspunkt i et format oprindeligt udviklet af Mike Cohn: “As an [actor] I want [action] so that [achievement]….” som på dansk bliver til

For eksempel: “Som [bruger af e-boks] ønsker jeg [at sætte forskellige faneblade på mine beskeder] sådan at [jeg kan styre hvilke beskeder, der vises på skærmen]”.

En User-story tjener til at identificere hvilke funktioner, data, funktionaliteter og så videre, der er nødvendige for at kunne imødekomme brugerens ønsker og forventninger, og resultaterne bruges som input til den videre udviklingsproces.

“User-Story” af Digitale Forretningsmodeller til Fremtiden under licensen CC BY-SA 4.0

Ovenstående illustration er en User-Story fra en web-shop. Linien MVP (står for Minimum Viable Product) skiller det nødvendige ovenfor linjen fra eventuelle ekstra ting nedenfor linjen.

Selv om en User-story altid skal skrive i “historieformat” (som kan se ud på mange forskellige måder) og ud fra brugerens synspunkt, kan man ofte med fordel bruge et skema til at samle op på resultaterne, fordi det giver mulighed for at knytte yderligere oplysninger til historien.

I nedenstående eksempel kan I følge den fiktive virksomhed Dimseriet og lade jer inspirere til hvordan værktøjet kan anvendes. Eksemplet kan hentes i en printvenlig version via PDF linket nedenfor.

“Dimseriet User-Story eksempel” af Digitale Forretningsmodeller til Fremtiden under licensen CC BY-SA 4.0

User-Story
Print-venlig version i stort format

Praktisk information

• I arbejdet med at definere User-stories bør I, så vidt det er muligt, altid involvere rigtige brugere i beskrivelserne af rolle, handlinger og ønsker, og helst så mange brugere, at resultatet bliver passende repræsentativt.
• Vær indstillet på, at beskrivelsen af en User-story kan tage tid.
• Vær forberedt på, at beskrivelserne i en User-story ofte udvikler sig løbende, og den derfor jævnligt skal “genbesøges” og måske opdateres med ny information.

Vejledning trin-for-trin

1) Definér først den rolle, som den aktuelle user story handler om. Beskriv personen bag rollen med alle de karakteristika, som er relevante, f.eks. alder, holdninger, hobbyer, behov, drømme, beskæftigelse osv.-osv.

2) Giv derefter rollen et navn (og skriv det i “I rollen som”)

3) Beskriv nu den handling, som personen ønsker at kunne udføre. Beskriv handlingen set fra brugerens eget synspunkt, og med alle de oplysninger og detaljer, som er relevante i situationen. (Skriv handlingen i “Ønsker jeg “)

4) Beskriv det resultat, som personen i roller ønsker af sin handling. Beskriv også her med alle de oplysninger og detaljer, som er relevante i situationen (og skriv det i “Så jeg kan”)

5) Beskriv derefter situationen ud fra jeres beskrivelse af rolle, handling og ønsket resultat, og skriv beskrivelsen i feltet “Når” under Accept-kriterier

6) Beskriv brugerens handling “set udefra” i feltet “og” under Accept-kriterier

7)  Beskriv det ønskede resultat af brugerens handling set fra jeres synspunkt i feltet “så” under Accept-kriterier.

8) Prioritér denne user-story i forhold til jeres øvrige user-stories.

9) Sæt eventuelt et tidsestimat på jeres user story, som indikerer, hvor lang tid det vil tage at udvikle

10) Giv til slut jeres user story en titel.

Use-cases

En Use-case er en beskrivelse af samspillet mellem et system – hvad enten det er software eller et eller flere fysiske produkter – og én eller flere personer eller andre systemer; både personerne og systemerne er da “brugere” i den aktuelle Use-case.

Use-cases skrives oftest som strukturerede dokumenter med en beskrivelse af fx:

• Mål med use-case
• Bruger eller brugere
• Forudsætninger (det, der allerede forudsættes sket i systemet)
• Standardhandlingsforløbet eller det primære successcenarie (hvad vil der normalt ske, beskrevet i trin)
• Alternative eller udvidede handlingsforløb
• Slutbetingelserne (hvad er der sket i systemet, når sidste beskrevne trin i handlingsforløbet er udført

Meget ofte er visualisering af brugssituationen sammen med beskrivelserne en meget effektiv vej. Se nedenfor illustrationen af en Use-case, der beskriver sammenspillet mellem et system, i form af en webstore, og personer, i form af kunde og virksomhed.

“Use-Case” af Digitale Forretningsmodeller til Fremtiden under licensen  CC BY-SA 4.0

Lige som User-stories tjener Use-cases til at identificere hvilke funktioner, data, funktionaliteter og så videre, der er nødvendige for at kunne imødekomme brugerens ønsker og forventninger, og resultaterne bruges som input til den videre udviklingsproces.

Use-case eller User-story?

Use-cases kan umiddelbart synes at være en mere effektiv vej til at identificere nødvendige input til en udviklingsproces, fordi Use-cases er mere fokuserede, rammesatte og præcise.

Man bør imidlertid være opmærksom på, at Use-cases netop derfor ikke altid kan bruges til at fange de brugerønsker og brugerkrav, som ikke er klart formulerede – måske fordi brugeren ikke kan formulere dem klart – men som ikke desto mindre kan være helt centrale og afgørende for brugeren og dermed også for den endelige løsnings succes. Det er derfor ikke et enten-eller, men et både-og!

Udbytte

Med agil udvikling – uanset om man bruger den Agile Tavle eller Scrum eller en blanding – får man en metode til at styre udviklingen, som giver synlighed, prioritering, involvering og åbenhed i processen. Relevante gennemarbejdede User-stories og Use-cases giver en reel forståelse af og indsigt i kunders og brugeres behov og forventninger, som er et stærkt grundlag for at udvikle løsninger, som vil fungere i virkeligheden og blive taget godt imod af brugerne.

Ekspertens råd

• Test altid løbende – også ud mod brugere/kunder
• Inddrag specialister der, hvor det er relevant
• Vær meget tydelig og specifik i jeres definition af, hvornår noget er ”færdigt”, både for opgaver, processer, resultater osv.
• Indfør om nødvendigt nye udviklingsprocesser i “bidder”, én proces ad gangen

Næste skridt

Sideløbende med opbygning af et nye mere fleksible arbejdsmetoder, som beskrevet her i Udviklingsprocessen er det relevant at teste de elementer i forretningsmodellen som netop er blevet designet og er under udvikling. Dette kan både gøres gennem Tidlig brugertest og pretotyping, der kan give indblik i kundes oplevelse af den konkrete løsning, og det kan gøres gennem Intern validering og test, der kan give indblik i hvorvidt jeres virksomhed har de interne egenskaber der skal til for at realisere den nyudviklede forretningsmodel.

I sidste ende er målet, at hele jeres komplette forretningsmodel er testet til en modenhed, hvor I er klar til at gå videre med Implementeringen af den.

Indholdselementerne ovenfor er udviklet gennem to projekter:

’Digitale Forretningsmodeller for Fremtiden’ af Aarhus Universitet, Aarhus Maskinmesterskole og Danish Technological Institute støttet af Industriens Fond. Materialet fra dette projekt er blevet vedtaget i overensstemmelse med CC BY-SA 4.0.

‘EU-IoT’ af Aarhus Universitet, Martel Innovate, Netcompany-Intrasoft, Fortiss, BluSpecs og finansieret af Horizon 2020 Framework Program under emne ID ICT-56-2020, bevillings-ID 956671.