DI, GEMBA Innovation og DTU har sammen udviklet og afprøvet en effektiv innovationsmetode til hardware. Agile Stage-Gate, som metoden hedder, kombinerer agile principper fra softwareudvikling med porteføljestyring fra Stage-Gate®. Agile Stage-Gate er udviklet specielt til mellemstore virksomheder og er afprøvet med succes i tre produktionsvirksomheder.

Manglende udnyttelse af innovationspotentialet

DI’s Innovationsbarometer peger på, at danske virksomheder har for mange projekter på samme tid, som tager for lang tid. Ressourcerne spredes over for mange aktiviteter, og virksomhederne kommer for sent på markedet. Konsekvensen er, at virksomhederne ikke udnytter deres innovationspotentiale fuldt ud.
Årsagerne til dette kan være mange. Vi mener, at en af de vigtigste årsager er manglende systematik i processen fra idé/behov til markedsintroduktion, dvs. hele innovationsprocessen. Innovation må ikke kun være det kreative lyn eller den tilfældige kundehenvendelse, som bliver til det nye kerneprodukt. Innovation er en disciplin, hvor virksomheden arbejder systematisk og konsistent med at bringe nye produkter på markedet.
En anden væsentlig årsag er, at mange virksomheder ikke formår at prioritere projekter tidligt og holde fokus på og dedikere ressourcer til de vigtigste innovationsprojekter. Ved at ville for meget reduceres innovationshøjden og udviklingstiden forlænges.
Agile Stage-gate er en innovationsmodel, som dækker hele innovationsprocessen fra ide til markedsintroduktion. Flere virksomheder har med succes introduceret agile udviklingsmetoder i kombination med Stage-Gate, men indtil videre har erfaringerne været baseret på store virksomheder og ofte software.
Vi har i dette projekt tilpasset Agile Stage-Gate til mellemstore danske virksomheder og testet innovationsmodellen i tre danske produktionsvirksomheder. I artiklen præsenteres Agile Stage-Gate og resultaterne af testen.

Stage-Gate og agile udviklingsmetoder kombineres

Metoden består af en overordnet proces og en tilhørende værktøjskasse.
Agile Stage-Gate er en innovationsmodel, der består af to dele:
Stage-Gate som er en beslutningsmodel og porteføljestyring af virksomhedens innovationsprojekter og ledelsens styringsredskab.
Agile udviklingsmetoder som bruges til at afvikle de enkelte innovationsprojekter.

Begge dele er vist i nedenstående figur:

Dokument1

Det øverste lag af modellen er Stage-Gate d.v.s. en faseopdelt innovationsproces fra idé til produktlancering. Mellem hver fase er der en såkaldt gate, som er et beslutningspunkt, hvor ledelsen tager stilling til, om produktudviklingen skal fortsætte, sættes på hold eller stoppes. I hver fase bliver virksomheden klogere på produktet, de tekniske muligheder og markedet. Ved et gate-review vurderes det, om projektet/produktet fortsat forventes at give de ønskede resultater. Et gate-review sker på baggrund af fastsatte kriterier for, hvad projektet/produktet forventes at bidrage med, for eksempel udtrykt som pay-back time. Gate-reviews er ikke hygge-diskussioner, men eksameniner, hvor det vurderes, om produktet lever op til forventningerne. Formålet er at sikre, at virksomhedens udviklingsressourcer anvendes på de bedste projekter, og om nødvendigt at ulønsomme projekter lukkes så tidligt som muligt på et oplyst grundlag. Derfor sker der samtidig en sammenligning af alle udviklingsprojekter og deres aktuelle præstation og potentiale, en såkaldt porteføljestyring.
Det er samtidig ledelsens styringsredskab til at sikre, at porteføljen af udviklingsprojekter afspejler virksomhedens strategi og roadmaps, hvor det er angivet, hvilke større nye produkter/lanceringer der forudses i de kommende år.
Antallet af gates varierer efter behov, og vi har valgt de fem viste faser i figuren, fordi de dækker hovedfaserne i et produkts vej fra idé til lancering.
Det andet lag – den nederste del af modellen – er de agile udviklingsmetoder, som bruges til afvikling af de enkelte udviklingsprojekter. ’Agil’ henleder tankerne på det at være adræt og tilpasningsdygtig, hvilket netop er kernen i de agile metoder. I agil udvikling planlægges og specificeres produktet løbende, og der ligger ikke en færdig produktspecifikation, når projektet startes. Agil udvikling accepterer, at forståelsen af produktet udvikler sig over tid, og at features vil ændre sig. Derfor passer agile udviklingsmetoder bedst til innovationsprojekter med høj kompleksitet, hvor resultatet fra starten ikke er givet.
Det agile projekt består af 1) projektmodel, 2) sprintprocessen og 3) metoder.

Projektmodel

Projektmodellen tager udgangspunkt i en overordnet projektplan, som ikke er endeligt specificeret. Vigtige elementer er:

  • En produktvision og/eller nogle overordnede produktmål, som skal guide udviklingsteamet.
  • En opdeling af projektet i et meningsfuldt antal faser og herunder sprints.
  • Et estimat for nødvendige ressourcer og kompetencer.
  • En rollefordeling. Hvem skal være: Produktejer, Scrum-master, udviklingsteam, stakeholdere.

Agil udvikling består af et antal korte, tidsafgrænsede sprint på 1-4 uger. Der kan være flere sprint i en fase. Udviklingsteamet skal være dedikeret til at arbejde på projektet et betydeligt antal timer om ugen, og de skal have autoritet og kompetence til at træffe flere beslutninger uden ledelsens indblanding (empowerment) samt acceptere, at sprintet ikke kan ændres, når det er i gang. Hardwareprojekter involverer udviklere med meget forskellig faglighed f.eks. printpladedesign, indkapsling, overflade etc., og i perioder, hvor der arbejdes med grænseflader mellem en eller flere fagligheder, er det væsentligt, at de berørte parter placeres fysisk sammen, mens arbejdet pågår (co-location).

2. Sprintprocessen

Sprintprocessen stammer fra Scrum (en softwareudviklingsmetode), og er en ritualiseret proces, som gennemløbes i hvert sprint. Produktejeren laver den første Product Backlog (BP), som er en liste over features, funktioner og større aktiviteter i projektet. Teamet og produktejer planlægger det første sprint, som indeholder en prioritering af PB, hvad der skal nås, og hvornår det skal være nået (definition-of-done).
Det daglige koordineringsmøde (daily scrum) på 15 minutter er et vigtigt ritual, hvor hele teamet deltager. For nogle projekter eller perioder af projekter vil et dagligt møde være for meget, men minimum to gange ugentligt er nødvendigt for at fastholde opmærksomhed og fremdrift i projektet. Koordineringsmødet synkroniserer teamets opfattelse af projektet og sørger for, at leverancer bliver leveret og evalueret.
Teamet består oftest af nøglemedarbejdere med flere opgaver, end de har tid til. Mødet sikrer, at teamet prioriterer opgaver og afsætter tid til projektet. Det er pinligt gentagne gange at rapportere, at man ikke lige havde nået opgaven. Projektets indbyrdes afhængigheder betyder, at manglende leverancer resulterer i, at teamet som helhed kommer til at vente. Dette krydspres er en stærk personlig motivation for, at deltagerne afsætter tid til at løse deres opgaver.
Scrum-masteren faciliterer mødet og sikrer, at dagsorden gennemgås på aftalt tid. Det kan være motiverende at lægge mødet 15 minutter før frokost – det giver en naturlig trang til at afslutte i tide. Tekniske problemer og diskussioner skal identificeres, noteres og efterfølgende løses af de berørte parter. Lange koordineringsmøder leder til frustration, og deltagerne mister motivationen for at deltage.
Et sprint afsluttes med et demo-møde, hvor resultaterne af sprintet præsenteres for produktejeren, stakeholders og evt. en nøglekunde, som giver feedback. Ud fra dette justeres PB, og et nyt sprint planlægges. Selve teamet evaluerer sprintet alene med fokus på processen, for at forbedre samarbejdet i næste sprint.
Erfaringen fra de tre virksomheder viser, at det at arbejde i sprint er en stærkt motiverende, men samtidig en hård arbejdsform, hvor teamet hele tiden skal love en leverance, som efterfølgende vurderes af andre. Særligt for udviklere, som har været vant til at arbejde alene, er sprint og koordineringsmøder en udfordring. Det handler ofte om at ændre vaner og lære den nye arbejdsform, og der er en tilbøjelighed til, at teamet i starten lover mere, end det kan holde, og dermed havner i den sociale gabestok på sprintmøderne. Efter nogle sprint vil teamet finde balancen.

Dokument2

Figur 2: Sprintprocessen i Agile Stage-Gate.

3. Metoder

Metoderne i Agile Stage-Gate understøtter sprintprocessen, og de bidrager overordnet med at give teamet retning. Scrum tavlen er det centrale værktøj til at give overblik over sprintet, da alle aktiviteter er inddelt i ”Planlagt”, ”I gang”, ”Færdig”. Scrum tavlen er omdrejningspunktet for koordinationsmøderne.
Produktvisionen er en samlet beskrivelse af det færdige produkt og en vigtig ledetråd for udviklingsteamet i de tidlige faser, hvor produktspecifikationerne er svage.
Brugerhistorier understøtter produktvisionen ved at beskrive situationer eller features, hvor produktet bruges og løser et brugerbehov. Det er afgørende, at det er reelle brugere, som indgår i brugerhistorierne. Når udviklerne projicerer deres personlige, tekniske entusiasme på en brugerhistorie, er der sjældent overlap med de rigtige brugeres ønsker. Produktet bliver over-udviklet, glemmer kundernes behov, eller bliver for dyrt.
Vores erfaringer viser, at det især er gavnligt at sætte udviklerne i direkte kontakt med slutbrugerne. Første gang er det angstprovokerende, fordi det jo er udviklerens ”barn”, som er til diskussion, og tænk hvis det ikke er godt nok. Når angsten og de personlige følelser har lagt sig, er der en dyb læring at hente. I det ene projekt medførte slutbrugermøder, at et helt planlagt segment blev skrottet, fordi kunderne allerede havde en billigere og mere fleksibel løsning, end den konstruktion, som virksomheden planlagde. Til gengæld var der en dyb læring om brugssituationer, som førte til et nyt, stærkt produkt.
Kriterier for færdig (definition-of-done) er en fastlæggelse af elementer i product backlog’en, som skal leveres i slutningen af sprintet. Hvad vil vi vise, og hvad er godt nok? Uden kriterier vil den enkelte udvikler selv anlægge kriterier styret af faglighed, som i ekstreme tilfælde udvikler sig til teknisk perfektionisme. Dermed tager løsningen længere tid og rammer i værste fald ikke markedet. Kriterier for færdig er en eksplicit diskussion og formulering af kriterier for, hvad der kræves for, at et element er færdigt. Diskussionen trækker på produktvisionen og brugerhistorierne, og teamet skal levere løsninger, som netop opfylder kriterierne – hverken mere eller mindre.

Resultater fra test i tre danske hardware virksomheder

Agile Stage-Gate blev testet i Weibel Scientific, Easyfood og DPA Microphones i 2017. Virksomhederne blev indledningsvis trænet i brug af Agile Stage-Gate af GEMBA Innovation og modtog i testperioden support og coaching af konsulenter fra Dansk Industri og GEMBA Innovation. Agile Stage-Gate blev testet på en enkelt fase i et produktudviklingsforløb (se Figur 1).
Ved projektstart blev virksomhedernes eksisterende innovationsmodel kortlagt, Og efter projektet blev innovationsmodellen igen vurderet, og medarbejdere og ledere blev interviewet om erfaringer og effekter af forskere fra DTU MAN.
Overordnet har Agile Stage-Gate resulteret i:

  • Ca. 20% reduktion i udviklingstid i forhold til sammenlignelige projekter.
  • Bedre overblik over innovationsprocessen.
  • Øget succesrate (estimeret ud fra en bedre defineret og forstået kundegruppe samt kundefeedback).

Udviklingsomkostningerne ved brug af Agile Stage-Gate er ikke højere end ved normale projekter, men den hurtigere udviklingstid medfører, at ressourcerne bruges på kortere tid. Denne tidsbesparelse bør kunne omsættes til hurtigere time-to-market og øget indtjening.
De tre virksomheder modtog alle træning og instruktioner i brug af Agile Stage-Gate, men de valgte selv at lave egne tilpasninger. F.eks. lavede DPA et designdokument efter en kundeundersøgelse, som er en tilpasning af product backlog. Designdokumentet blev projektets referenceramme i de (mange) tilfælde, hvor medarbejdere projicerede deres egne idéer om kundernes ønsker ind i produktet. I Easyfood var der erfaringer med design thinking og business model canvas i produktudvikling, og disse blev integreret som metoder i sprintprocesserne. Weibel oplevede under første sprint, at dedikerede ressourcer på projektet var et problem for virksomhedens øvrige drift, da udviklerne også havde opgaver med produktion og salg. Derfor blev der indført en uges pause efter et sprint, så udviklerne kunne løse den kø af opgaver, som havde hobet sig op.
De tre eksempler er ikke enestående og viser, at Agile Stage-Gate er en fleksibel metode, men der er nogle få elementer, som er afgørende for robusthed og effekt:

  • At organisere projekter i sprint.
  • At hvert sprint har en konkret leverance, som skal præsenteres og evalueres.
  • At der afholdes mindst 2 koordinationsmøder om ugen.
  • At hele sprintteamet deltager i koordinationsmødet – på alle møder.
  • At brugerindsigt og kundeforståelse guider designvalg.
  • At projektet respekteres,så udviklerne reelt har tid til at deltage.
  • At ledelsen afsætter ressourcer og skaber opbakning til metoden.

Agile Stage-gate og hardware

Metoden stammer oprindeligt fra udvikling af software, og der var en naturlig bekymring, om metoden umiddelbart lader sig anvende på hardware. Selvom projektet overordnet er en succes, er der dog en række udfordringer, som man bør holde sig for øje:

  • Product backlog kan i software kobles direkte til features, som har relativt lille indbyrdes afhængighed. I hardware har features og elementer stor indbyrdes afhængighed f.eks. ved placering af et stik og en ledningsføring.
  • I software kan resultater testes umiddelbart. I hardware kræver dette, at en prototype fremstilles. I agile stage-gate kan det betyde, at hele sprintet/projektet stopper og venter på prototypen for at undgå, at sprintteamet mister deres synkronisering.
  • I hardware vil tidlige designvalg være afgørende for senere muligheder.

Med dette in-mente er Agile Stage-Gage i hardwareudvikling en attraktiv mulighed for produktionsvirksomheder, der ønsker at reducere udviklingstiden og skabe succes med komplekse innovationsprojekter.

Nemt og billigt at komme i gang

Agile Stage-gate lader til at være en effektiv innovationsmetode, vurderet ud fra de tre virksomheder. Omkostningerne til træning har været begrænset til i alt ca. to dage for sprintteamet, samt coaching i de første sprints.
Adgangsbarriererne for at komme i gang er derfor relativt lave, og metoden er beskrevet og tilgængelig. Den største barriere synes at være ledelsesmæssig, idet Agile Stage-Gate forudsætter et klart fokus og en klar prioritering af ressourcer og udviklingsprojekter. I mange virksomheder er udvikling ufokuseret ved, at der er for mange projekter i gang på samme tid. Ledelsen har deres idéer og projekter, udviklerne har deres egne teknologiske projekter, og ressourcerne bliver smurt for tyndt ud over alle projekter. Styring bliver til reaktiv brandslukning, hvor det nødvendige kun akkurat lige leveres.
Agile Stage-Gate med sprint og koordinationsmøder sætter ressourcediskussionen i fokus, ganske simpelt fordi udviklerne mødes for at aftale, hvad der skal laves. Og dermed bliver ressourcerne – eller mangel på samme – synlige i dagligdagen, og udviklere og ledelse tvinges til at prioritere.
Dette projekt har vist, at store effekter kan opnås allerede første gang Agile Stage-Gate bruges i virksomheden. Der er intet, der tyder på, at der har været negative effekter. Tværtimod rapporterer virksomhederne, at de vil fortsætte med at bruge metoden, så det er bare at komme i gang:

Fakta

Agile Stage-Gate® projektet blev finansieret af Industriens Fond. Projektet blev gennemført af Michael Nielsen og Jens Kristian Jørgensen, Dansk Industri, Tomas Vedsmand og Nikoline Hvidt, GEMBA Innovation, Kasper Edwards og Giulia Nardelli, Danmarks Tekniske Universitet, samt Professor Robert Cooper, som oprindeligt udviklede Stage-Gate® metoden. Agile Stage-Gate® blev testet i Weibel Scientific, Easyfood og DPA Microphones.

Links:

DI: https://di.dk/virksomhed/innovation/innovationforside/pages/agil-stage-gate.aspx
GEMBA: http://gemba.dk/agile-innovation-and-agile-stage-gate/
Metoden: http://orbit.dtu.dk/files/139598411/Guide_til_Agil_Stage_Gate_version_1.pdf
Værktøjskassen: http://orbit.dtu.dk/files/139598364/Agil_Stage_Gate_V_rkt_jskasse_version_1.pdf