Reloads agile proces forklaret
Vores procesmodel forklaret til kunder og samarbejdspartnere

Vores agile proces

Softwareudvikling er ofte komplekst. Økonomi og tidsplaner skrider ofte i IT projekter, fordi der viser sig en masse behov undervejs, eller der bliver udvikles features, der ikke er brug for. Enten fordi de er alt for svære at bruge, eller også eksisterede behovet slet ikke i virkeligheden. 
Der er også mange andre faktorer, som gør det komplekst. Rammerne for projekterne ændres nemlig altid. Hver gang vi kaster os ud i at skulle lave en ny digital løsning, så der er nye funktionalitetskrav, nye mennesker, en ny forretningssituation, ny teknologi, nye prioriteter og afhængigheder - og i det hele taget andre omstændigheder. Derfor kan to IT-projekter aldrig være ens - og derfor er det pr. definition komplekst. Denne usikkerhed skal omfavnes for at komme sikkert i havn.

Når vi i Reload indgår i udviklingen af et digitalt produkt, vil vi være med til at sikre, at det bliver en succes. Vi har set og udviklet en lang række løsninger, og vi har et ret godt begreb om, hvad vi kan og ikke kan med teknologi til trods for, at den udvikler sig med lynets hast. 
 

Alice og Mads i aktion for et større agilt projekt for Region Sjælland.

Værdien skabes af ændret adfærd

Ingen digitale løsninger skaber dog værdi i sig selv, det er den menneskelige adfærd, som løsningen understøtter, der skaber værdien. Hvis vi vil skabe mere værdi, skal vi altså ændre adfærd hos nogle mennesker. Derfor fylder fokus på menneskelig adfærd og interaktion meget i vores proces. Før vi sætter udvikling af en feature i gang, skal vi først være helt skarpe på præcis af hvem og hvordan vi forventer den feature skal bruges, samt hvordan det i sidste ende skaber værdi - og er investeringen dét værd for os? Bliver vi i tvivl om, hvorvidt der kunne være billigere eller bedre løsninger, eller om de antagelser vi baserer vores cost / benefit betragtninger på holder, så tager vi os tid til at blive klogere, før vi træffer en beslutning. 

Vi bliver klogere undervejs - sammen

Typisk bliver vi så meget klogere undervejs, at vi ender med løsninger, der er markant anderledes end først forventet. Kun hvis hele organisationen er med til at skabe og trimme løsningen, kan vi skabe det værktøj som understøtter jeres digitale virke på bedst mulig vis. Det kræver, at I kan stille med en Produkt ejer, som kan arbejde uafhængigt og på tværs af siloer, som har fuldt beslutningsmandat inden for de aftalte projektrammer, og har den nødvendige tid til at være en aktiv part i processen. Hvis Produktejeren ikke tidligere har været med til at udvikle større digitale løsninger i en agil proces, anbefaler vi træning/undervisning forud for samarbejdet.

Vi håndterer risiko ved ikke at aftale alt på forhånd

Vi tror altså ikke på, at løsninger, som er færdigspecificeret og aftalt på forhånd, ender med det bedste resultat. Derfor arbejder vi ikke med aftaler som låser os fast på konkrete funktionalitetsleverancer. Det er angstprovokerende at gå ind i et forløb uden at vide, hvad man kommer ud med på den anden ende. Det forstår vi. Det kan virke som en stor risiko, men risikoen for at vi simpelthen ikke fokuserer rigtigt, hvis vi skulle fastlåse løsningen på forhånd, er i vores optik langt større. Dels fordi løsningens præmisser typisk er forældede, før nogen får glæde af den, og dels fordi, at fastlåser vi både økonomi og funktionalitet, så er den eneste parameter, vi har at skrue på, når noget uforudset viser sig, kvaliteten!

10 gode grunde til at vælge en agil tilgang

1. Det rigtige produkt
I IT projekter ser vi ofte, at mange features aldrig eller sjældent bruges. Med agil udvikling er der fokus på at bygge det rigtige produkt frem for det “aftalte produkt”.

2. Udnyttelse af reel feedback
Fordi vi leverer fungerende software tidligt, så kan vi nå at få feedback fra projektorganisation, ressourcepersoner, pilot/beta-brugere eller rigtige brugere, og prioritere videreudvikling herudfra.  

3. Time-to-Market
80% af alle market leaders har været først på markedet med deres produkt. Med agil udvikling, leveres der løbende - så snart, vi mener at have noget, der er bedre end, hvad vi har i dag. Fungerende leverancer giver desuden muligheden for at teste integreret hele vejen igennem udviklingsprocessen og arbejde med produktions(nær) data tidligt.

4. Kvalitet 
Kvalitet er svært at beskrive up-front . Men det er vigtigt at forstå, at hvis vi binder os til en “fixed scope + fixed price” leverance, er det typisk kun kvaliteten, der kan skrues på - og sjældent til det bedre.  

5. Fleksibilitet 
Ændringer i (eller ny viden om) markedet / konkurrenter / egen organisation / teknologisk udvikling kan trigge naturlige scope-ændringer, som den agile proces giver mulighed for rent faktisk at realisere.

6. Gennemsigtighed 
Meget involvering og tæt samarbejde med kunden skaber gennemsigtighed i processen og gennemtvinger en stærk forventningsafstemning, hvor evt. uoverensstemmelser tages med det samme, frem for at samle sig til bunke.

7. Bedre Risk Management
Før vi faktisk udvikler noget, når vi at tale funktionalitet og diverse edge-usecases meget bedre igennem end, hvad en typisk kravspecifikation dækker. Det skaber klarhed og bevidsthed om hvad og hvordan tiden bruges, og det betyder at vi løbende kan justere fokus, ift. ny viden og/eller ændrede forudsætninger i projektet. Man kan sige, at der er større risiko for ikke at imødekomme organisationens initielle forventninger, hvilket kræver ekstra fokus på løbende forventningsafstemning, men der er en mindre risiko for at udvikle et produkt der ikke har reel forretningsværdi. 

8. Budget kontrol
Fordi vi har fleksibilitet i scope og styrer mod et fast budget, vil der ikke komme uforudsete ekstraudgifter i form af et change budget, der løber løbsk.

9. Indbygget medejerskab 
Den aktive involvering af organisation, redaktion, ressourcepersoner og andre interessenter, betyder at de gennem hele processen kan komme med input og prøve dele af det færdige produkt af. Det fører automatisk til et medejerskab. De, der skal bruge systemet, føler ikke de får trukket noget ned over hovedet, og produktet fungerer, når det lanceres.  

10. Vi er i samme båd
Fordi aftalen er skruet sådan sammen, at vores kunder køber tid frem for funktionalitet, er vi sammen om at udnytte den tid, vi har til rådighed bedst muligt. I modsætning til en fixed scope kontrakt med et indbygget modsætningsforhold ift. hvad der skal læses ud af en given kravspecifikation.

Målstyring som grundlæggende koncept

I vores perspektiv styrer vi produktudvikling. Det, at vi pakker det ind i en række mere eller mindre arbitrært afgrænsede projekter må ikke styre vores beslutninger om produktet, og at projektet i sig selv lykkes giver ingen garanti for succes samlet set - tværtimod kan det komme til at skabe et alt for kortsigtet fokus. 

Vi anerkender selvfølgelig, at vi har en projektøkonomi at rapportere op imod og styre indenfor, men fokus er på løsningens fulde levetid og total cost of ownership. Vi tilrettelægger derfor ikke vores proces rundt om det enkelte projekt og taler ikke om “projektfaser”. I stedet giver det mening for os at organisere arbejdet i sprints og to typer af opgaver: “Discovery opgaver” og “Delivery opgaver”. Dette er en kontinuerlig og fleksibel proces, som der kan skrues op og ned for, alt efter behov og økonomi.

Dette har vi forklaret nærmere i “Reloads samarbejdsmodel”. Her beskriver vi helt overordnet hvordan og hvorfor vi arbejder som vi gør, og vi eksemplificerer vores grundlæggende tilgang og mindset. 

Resten af dette dokument beskriver lidt mere jordnært hvordan en typisk agil proces fungerer i praksis og i hverdagen hos os. Dvs. lige fra møderytmer og nogle af de mange styringsredskaber vi bruger for at komme sikkert frem til målet.

OBS

Hvis du ikke har læst om vores samarbejdsmodel, så start med at læse den nu.
Den er grundlaget for at forstå processen og nogle af metoderne som er beskrevet herunder.

Vores agile proces i praksis

Fokusområder inden vi for alvor går i gang

Før vi kan træde til som partnere og rådgivere i udviklingen af en ny løsning, skal vi dog have en dybere forståelse for jeres virke, og hvordan I er organiseret. Vi skal forstå, hvilken viden der allerede er, som vi kan bygge videre på, og hvilke forhold, vi skal lære mere om.

Vi skal have kortlagt de behov og forventninger der er i spil til jeres løsning, og herudfra skitsere overordnede koncepttanker. Vi kan have brug for at tegne nogle streger, der sikrer sammenhængen i en god løsning.

Nedenfor er skitseret hvilke fokusområder, vi skal igennem. Hvordan vi præcis tilrettelægger workshops, arbejdsmøder, analyse og designarbejde afhænger meget af temperament, samt hvor gennemarbejdet og opdateret et vidensgrundlag, I allerede har. Udgangspunktet er, at I præsenterer eksisterende viden indenfor området for os, hvorefter vi sammen løbende vurderer behovet for løbende afklaring.

Team og proces
Grundig gennemgang af proces, roller og forventninger til os selv og hinanden samt et socialt arrangement, hvor vi kan lære hinanden lidt bedre at kende.

Hvem er I? 
Gennemgang af jeres organisation, vision, og de strategisk tanker, der ligger til grund for en ny løsning. 

Strategi og målgrupper
Gennemgang af kendte målgrupper og centrale brugerscenarier for jeres nye løsning

Roadmapping
Gennemgang af (high level) feature ønsker og heraf en Impact Mapping som tager højde for betragtninger om strategi og brugeradfærd, samt illustrere prioriteringen af behov, ønsker og idéer.

Tekniske afhængigheder
Analyse af det tekniske setup herunder særligt fokus på centrale integrationer og særligt komplekse features.

Koncept og principper
Som udgangspunkt for design af en ny løsning udvikles typisk et koncept der beskriver de overordnede principper for arkitektur, applikationsdesign, informationsarkitektur, navigation, interaktion og look & feel.

Konceptet sikrer, at udvikling og specifikation af løsningens forskellige indholdsområder og funktionaliteter tager afsæt i en overordnet ambition og prioritering, som hele tiden tager udgangspunkt  den bærende idé og principper og derfor giver en meningsfuld og konsistent brugeroplevelse.
 
Alle de ovenstående ting er en blød start på det vi kalder “discovery opgaver”.

Discovery og delivery opgaver

Når først hele teamet har god forståelse for jer og jeres behov, går vi ind i et udviklingsforløb som i princippet er struktureret til at køre kontinuerligt, også selvom vi i praksis kommer til at skrue op og ned afhængigt af budget og behov. 

Vi har arbejdet med mange variationer af agile metoder - og eksperimenterer løbende - men for at gøre en lang snak kort, så fungerer det efter vores erfaring bedst, når de afklarende og implementerende aktiviteter følges ad og informerer hinanden

Det nytter ikke så meget, at kun udviklingen kører agilt - hele tanken er jo, at vi skal opnå et kort feedback loop og lære af det - og så skal alle andre discipliner lige fra design, ux og strategi jo også være i spil, efterhånden som vi bliver klogere. Derfor forsøger vi at gøre det hele løbende og deler det ikke op i to spor, men derimod bare op i discovery og delivery opgaver.

Discovery: Byg de rigtige ting

Med discovery-opgaver fokuserer vi på, hvordan vi kan bygge “det rigtige”. Det kan være en eksplorativ og kreativ proces, hvor vi prøver ideer af, interviewer folk i målgruppen eller kigger på eksisterende data. Vi skaber viden. Backloggen (opgavelisten) består af research spørgsmål, leverancen er svar, og det er oftest en iterativ proces, hvor vi løbende retter vores hypoteser til. Vi ender med nogle svar som i sidste ende sikrer, at vi fravælger de mindre gode idéer og sender de gode videre som velspecificerede user stories med validerede bagvedliggende antagelser.

Delivery: Byg tingene rigtigt

Med delivery-opgaver fokuseres på kvalitet, performance, scalability og lign. User stories fungerer som udviklings-specifikationer, og leverancen er produktionsklare features klar til at blive deployet (udrullet) og taget i brug. 

Ét team

At der er to typer af opgaver er dog ikke at forveksle med to separate teams. Det er ét team, alle dem der arbejder sammen om jeres nye løsning, og de arbejder sammen i én proces, den har bare to typer af opgaver. Det er vigtigt, at alle så vidt muligt inddrages i, hvad der arbejdes på på tværs af opgaver. Det er vores erfaring, at det er en nøglefaktor i forhold til at skabe den gensidige team-ansvarsfølelse der er et af elementerne, hvis man vil opnå et high performance team.

Design foregår hele tiden

Designarbejdet i traditionel forstand (som i “vi laver noget i form og farver”) har en vigtig rolle at spille i begge typer af opgaver. 

I discovery-opgaver designer vi for at lære og for at skabe en fælles forståelse for løsningsrummet. Vi skaber muligheder, prøver ting af og finder ud af, hvad der virker. 

I delivery-opgaver designer vi for kunne levere et færdigt produkt. Det er her designarbejdet former og indarbejdes i den tekniske løsning og der er fokus på systematik, konsistens og genbrugelighed af komponenter i brugergrænsefladen.


 

Discovery - her skal vi blive klogere

Inden et sprint starter, så har vi afholdt et grooming møde, hvor vi tager fat i de vigtigste behov og features, vi kan identificere i vores Impact Map. Vi vurderer her risikoen for, at vi mangler viden, og vores antagelser derfor ikke holder. Dvs. hvis vi er stensikre på vores business case og vores kendskab til målgruppens brugssituation, skal vi selvfølgelig ikke bruge mere krudt på at analysere og iterere over design eller koncept. Men er der områder, hvor vi er mindre sikre, giver det mening at grave lidt mere i det.  

Det er selvfølgelig virkelig svært for os på dette tidspunkt at vurdere, hvor meget tid vi skal bruge på analyse og specificering af krav og ønsker for at kunne skære scopet rigtigt. 

Det svære ved den slags afklarende arbejde er, at man aldrig kan blive færdig. Du kan altid sikre sig lidt bedre, undersøge lidt mere, prøve lidt flere visuelle muligheder osv. af inden du føler dig klar til udvikling. Så ligesom du skal være knivskarp på ikke at agere efter antagelser, der burde valideres bedre, skal du den anden vej rundt være lige så skarp på, at den tid du bruger her, går fra tid du kunne bruge til udvikling og læring deraf. Du skal altså kun undersøge forhold, I ikke ved nok om, og hvor det er tiden værd.

Udgangspunktet er igen, at I diskuterer behov og relevant viden ift. den givne feature, og her giver det typisk mening at trække på forskellige ressourcepersoner som ved noget om det område. 

Ud fra en risikobetragtning beslutter vi, om eksisterende viden skal følges op af analyse (hvor stor risiko er der for, at vores viden er forkert eller forældet? Og hvor stort et problem har vi egentlig, hvis det viser sig at være sagen?).  

Selve analysen i sprintet kan altså bestå af meget forskellige aktiviteter. Målet er at besvare de spørgsmål, vi kan have ift. om vores idé og forventet cost/benefit holder. Typisk er det en balancegang mellem analyse processer og kreative processer at finde frem til den rigtige løsning.

The most expensive way to test your idea is to build production quality software Jeff Patton

Spørgsmål

Typiske aktiviteter (og altså måder at besvare spørgsmål på) kunne eksempelvis være: 

  • “Hvad er brugernes behov?”
    • Eksplorativ analyse via fokusgruppe interviews og feltundersøgelser, der kan afdække behov vi selv og vores brugere ikke ved, vi har. 
       
  • “Kan det teknisk lade sig gøre?”
    • Teknisk prototyping der kan verificere, om formodede teknologier og 3. parts moduler kan bruges i et specifikt scenarie. 
       
  • “Kan vi skabe den ønskede adfærd hos brugeren?”
    • Iterative designprocesser, baseret på visuelle prototyper, hurtige brugertests og feedback.

Vores antagelser giver anledning til spørgsmål

Disse spørgsmål vi skal stille udspringer oftest fra Impact Mappet. Vi antager, at en given funktionalitet ændrer en adfærd, og vi antager, at denne ændrede adfærd påvirker vores forretningsmål positivt. 
Hvis dette reelt er antagelser og ikke faktuel viden, så skal vi muligvis sørge for at blive klogere her.
Og dette er særligt tilfældet, hvis prisen for at udvikle et tiltag er høj, eller risikoen for projektet er høj, hvis antagelsen er forkert (det kan fx være nogle tekniske muligheder/begrænsninger eller fx en stor økonomisk omkostning). 
Det er ikke alting, vi kan undersøge og måle på forhånd, men det nemmeste er oftest at tage udgangspunkt i folks adfærd. 
 

Delivery - så skal der bygges fungerende leverancer

Delivery-opgaver lever typisk som user stories i en traditionel Scrum proces. Det betyder, at vi har en backlog (opgavelisten) som er en løst struktureret opgaveliste af “user stories” med de specifikationer, vi former og validerer med discovery-opgaver. Det er altså at betragte som en dynamisk kravspecifikation, selvom det er også er vigtigt at forstå, at det ikke er meningen (eller opnåeligt), at alt i backloggen skal laves. 

Derimod skal den løbende prioriteres, forfines og justeres efterhånden som tiden skrider frem. Vi vælger løbende en håndfuld opgaver og implementerer dem i et sprint, hvorefter de færdige funktionaliteter kan demonstreres (og per definition er produktionsklare).

Scrum processen kort forklaret

Selve Scrum-processen kan du finde masser af bøger og materiale om. Men jeg vil lige forklare helt kort, hvordan vi snitter den på en måde der erfaringsmæssigt fungerer godt for os. Dette er vores udgangspunkt, når vi starter nye projekter op.

Et udviklingssprint varer typisk 2 uger og inkluderer forberedelse til det kommende sprint samt til leveranceafprøvning. I Reload tror vi fast på, at det er essentielt, at vi bruger tid sammen som samlet team og har mulighed for at træffe hurtige beslutninger sammen. Vi stiller for eksempel lokaler til rådighed, så vi og vores kunder kan sidde fysisk sammen minimum én dag om ugen udover de faste møder.

Jo mere teamet er fysisk sammen, desto bedre.

Herover: Eksempel på et sprintforløb, hvor der arbejdes mod et MVP - Minimal Viable Product

Møde: Sprintplanning (Hver sprint)
Vi gennemgår de estimerede udviklingsopgaver og prioriterer, hvilke opgaver der har højest værdi/prioritet, og dermed skal i scopet for udviklingssprintet.

Forløb: Udvikling og test (2 uger)
Vi arbejder på én opgave ad gangen per udvikler og færdiggør en ny version af løsningen, der kan afprøves ved sprintets afslutning.

Møde: Demo, retrospektiv, og rapportering (Hver sprint)
Vi demonstrerer sprintleverancen samt vender processen og evt. forbedringer hertil. Vi leverer også en sprintrapport, der opsummerer status på fremdrift, økonomi, scope, risici, og vigtige beslutninger.

Møde: Daily scrum / standup (Hver dag i sprint)
En kort, stående, gennemgang af dagens opgaver, og status på hvad der blev lavet siden i går. Bruges til at vidensdele og identificere roadblocks. Alle er velkomne på mødet. 

Møde: Backlog grooming (Hver sprint)
Her forbereder vi opgaver til næste sprint. Dvs. vi snakker dem igennem, finder ud af hvilke opgaver der kræver yderligere afklaring, og estimerer de opgaver vi forventer skal med i næste sprint. I veletablerede teams kan dette også ske løbende. 

Forløb: Afprøvning og feedback (1 uge)
Vi forventer, at I umiddelbart efter et sprint afprøver leverancen, bliver fortrolige med den nye version af jeres løsning, og giver feedback vi kan tænke ind i de kommende leverancer.
 

Vi skaber løbende læring gennem korte feedback loops

Inkrementel udvikling er trinvis udvikling. Et trin ad gangen - en feature ad gangen. Så frem for at nedbryde og udvikle scope ud fra de tekniske lag (først datagrundlag / funktionalitetslag / præsentationslag), så skal du nedbryde i fulde funktioner, små prioritérbare bidder, der giver værdi i sig selv. Det, du tager ind i sprintet bør altså være så afgrænsede features, at de kan færdiggøres og være klar til produktion ved sprintets ende. På den måde kan de komme ud og generere faktisk værdi, mens I udvikler på de næste.

Vertikale slices

Værdi er ikke nødvendigvis produktion. Oftest skal der en del sprints til, før man er nået til et produkt der kan publiceres. Men det skal ud og prøves af, om ikke andet hos interessenter i organisationen. Således skaber du feedback og dermed viden. Og det er værdifuldt!

Færdiggørelse er jo så et elastisk begreb i denne sammenhæng, og det er her, at det iterative og udnyttelse af feedback loops kommer ind i billedet. Vi anbefaler altid, at første version af en ny feature er så skrabet som overhovedet muligt, men aldrig mere skrabet, end at vi (hvis den er færdig) vil kunne lukke den ud i produktion, som den er. 

Ofte er dette også måden, vi styrer budgettet på. Typisk er det de færreste behov og features, vi helt kan undvære at komme omkring, men ofte kan vi vælge at gøre mere eller mindre ud af en given feature. Både fordi vi gerne vil have feedback og lære, før vi udvikler den dyre løsning, og fordi vi vil være sikre på, at vi kommer hele vejen rundt, er fokus i udviklingen af en ny løsning altså altid på, hvor simpelt vi kan skære den. Når vi så først er hele vejen rundt, kan vi arbejde mere iterativt og backloggen kommer i højere grad til at bestå af forbedringer til eksisterende features frem for nye features. 

Ved sprintets afslutning præsenterer vi de færdige løsninger. Vi får jeres umiddelbare feedback, og I får adgang til at prøve jeres nye løsning. Så vurderer vi endeligt, om den er klar til produktion, eller om den skal have en iteration mere først. 

Vi elsker kage-analogier

Typisk er det de færreste behov og features, vi helt kan undvære at komme omkring, men ofte kan vi vælge at gøre mere eller mindre ud af en given feature. Både fordi vi gerne vil have feedback og lære, før vi udvikler den dyre løsning, og fordi vi vil være sikre på, at vi kommer hele vejen rundt, er fokus i udviklingen af en ny løsning altså altid på, hvor simpelt vi kan forme og skære den. Når vi så først er hele vejen rundt, kan vi arbejde mere iterativt og backloggen kommer i højere grad til at bestå af forbedringer til eksisterende features frem for nye features. 

Lille og lækker

Hellere bygge en funktionelt lille, men virkelig velfungerende løsning og siden bygge på derfra. Så får brugerne en god oplevelse, og du får gang i et rigtigt sundt feedback-loop, som kan hjælpe dig med at prioritere det videre arbejde. 


 

Cupcake modellen, fra AdaptivePath

Grundtanken er, at vi undgår at bygge én stor lagdelt kage, der først er spændende, når den står færdig med glasur og det hele. I stedet bygger vi en lille, men perfekt lækker kage. En fuldendt cupcake. Er dine brugere begejstrede for den, jamen så kan du bygge den videre til en stor kage. Måske kan de ende med at få en bryllupskage. Men går du efter bryllupskagen fra starten af, kan det være, at den er så dyr eller kompleks, at du aldrig bliver færdig med den. Eller også ser den flot ud, men falder ikke i nogens smag.

Vi kalder det nogle gange for “cupcake modellen”, tyvstjålet fra denne blogpost.

Rapportering

Eksempel på Reloads sprintrapport

Efter hvert sprint rapporterer vi om status og fremdrift. Her kigger vi på, hvordan estimater udvikler sig efterhånden, som vi udspecificerer, og sikrer, at vi holder os indenfor budget. Sprintrapporterne er brutalt ærlige, også når det er svært. I så fald vil vi hellere finde en løsning på en sådan situation sammen end at forsøge at negligere det. Overskrifterne i en typisk sprintrapport er:

  • Opsummeret status beskrevet med ord
  • Punkter som er værd at bemærke (typisk showstoppers og centrale beslutninger)
  • Vurdering af risici med konkrete anbefalinger
  • Resumé af sprintets resultat
  • Status på fremdrift (på tværs af spor)
  • Overblik over prioriterede indsatser / epics
  • Status på budget forbrug 
  • Oversigt over sprints og allokering fremadrettet

Du kan læse mere om, og se eksempler på, vores sprintrapporter i denne artikel.

Kundens roller og ansvar

Vi forventer, at I som kunde er en aktiv del af hele processen. Idet vi ikke har endeligt specificerede krav fra start, og forventer at de ændrer sig løbende, så er det nødvendigt, at vi specificerer kravene og tænker løsningerne sammen i løbet af processen.

I hverdagen forventer vi at arbejde tæt sammen. Vi forventer, at jeres projektteam kan allokere minimum 1 dag per uge og i perioder endnu mere, op til fuld tid. Vi forventer ligeledes, at I kan stille med en Produktejer, som har mandat til at tage alle beslutninger inden for projektrammerne. 

Tak fordi du har læst så langt

Hvis du synes sådan noget her er interessant, så skriv dig op på vores nyhedsbrev. Her skriver vi løbende om relaterede emner, deler viden og konkrete erfaringer.

Og så vil du også blive inviteret til vores gå-hjem-møder, hvor vi og vores kunder deler rundhåndet ud af vores erfaringer.

Og ellers skal du være meget velkommen til bare at kontakte os med det samme :)