Da jeg jobbet som Product Manager og hadde ansvaret for å utvikle en ny skytjenste, var målet klart, og jeg hadde full kontroll – i alle fall trodde jeg det. Foran meg lå et nøye planlagt Gantt-diagram med nesten tusen linjer der flere parallelle prosesser på tvers av flere avdelinger var koordinert. Alt var satt opp: Hvilke funksjoner som skulle utvikles, hva som måtte komme før det neste, hvordan de skulle koordineres med markedsføring, drift, salg og support, og hvordan alt skulle passe sammen i den store helheten.
Men én ting var ikke fastlagt: Tidsaspektet. Vi visste hva vi ville bygge, men ikke akkurat når vi ville bli ferdige. Problemet var at utviklerne fulgte ikke planen min. De jobbet Agile. Og det var helt greit.
Vi skulle bygge et slott – men startet med hytter
Når du skal bygge et slott som skal bli et hotell og konferansesenter, kan du ikke vente til hele slottet er ferdig før du begynner å tjene penger. Derfor starter du med noen mindre hytter som du kan leie ut umiddelbart. Men for å ikke kaste bort tid og penger, må du planlegge disse hyttene slik at de senere kan slås sammen til en del av slottet.
Og selv om resepsjonen skulle utvides senere, ville betalingsløsningen fortsatt være den samme. Du kan ikke bygge et nytt betalingssystem hver gang du legger til et nytt rom – det må være kompatibelt fra starten. Du kan ikke bare bygge tilfeldig og håpe at det passer sammen senere.
Akkurat sånn måtte vi jobbe med vår skytjeneste.
- Vi kunne ikke vente et år på en full lansering som vi kunne bygge videre på.
- Vi måtte fokusere på de viktigste funksjonene først.
- Brukeropplevelsen måtte henge sammen fra dag én.
Det krevde to ting samtidig:
- Agile utvikling i små biter (hyttene) – slik at vi kunne lansere noe tidlig.
- En langsiktig plan (slottet) – slik at vi ikke bygget oss inn i et hjørne.
Så ja – vi jobbet Agile. Men vi gjorde det innenfor en strukturert ramme.
Hybridmodellen: Når Agile møter arkitekttegninger
Mange bedrifter tror de jobber Agile, men i virkeligheten kjører de en mellomting – akkurat som vi gjorde.
På overflaten så alt smidig ut:
- Utviklerne brukte sprints
- De hadde stand-ups
- De kjørte retrospektiver
Men min jobb var ikke å dykke ned i metodikken. Det jeg fokuserte på, var resultatene og fremdriften:
- Sikre at nye funksjoner passet inn i helheten.
- Koordinere lanseringer med markedsføring, salg og support.
- Holde fremdriften uten å låse oss i rigide tidsskjemaer.
Vi var smidige i småskala, men strategiske i det store bildet.
Hvor Agile kan du egentlig være uten en overordnet plan?
Mange tror at Agile betyr total frihet – at man bare starter sprintene uten en overordnet strategi.
Men uten en plan ville vi risikert å bygge noe fragmentert og usammenhengende.
Det er forskjell på å bygge småhus på måfå og å bygge hytter som senere kan bli en del av et slott.
“Det er lett å si at vi skal være Agile og jobbe inkrementelt. Men hvis vi ikke hadde tenkt helhetlig, kunne vi ha endt opp med en samling tilfeldige byggverk i stedet for en sammenhengende løsning.”
Hva med DevOps?
Når vi snakker om smidige arbeidsmetoder, går ofte DevOps og Agile litt om hverandre. Mange tror de betyr det samme, men det er to forskjellige ting.
| Agile | DevOps |
|---|---|
| Fokus på hvordan vi utvikler | Fokus på hvordan vi leverer og drifter |
| Iterativ utvikling i korte sprints | Automatisering av bygg, test og deploy |
| Handler om fleksibilitet og tilpasning | Handler om kontinuerlig leveranse og drift |
| Ofte brukt av utviklere | Involverer både utvikling, drift og infrastruktur |
Så ja, vi jobbet Agile på utviklingssiden, men vi hadde ikke en full DevOps-prosess.
“Før vi brukte Docker, var hver utrulling en potensiell hodepine med manuelle tilpasninger og ‘det funker hos meg’-problematikk. Det var alltid perfekt på testplattformen, men alltid noe som skar seg i produksjonen. Med Docker kunne vi pakke applikasjonen i containere, sikre at alt kjørte likt på tvers av utvikling, testing og produksjon, og unngå mange av de vanlige feilkildene. Men uten en fullstendig CI/CD-pipeline var vi fortsatt avhengige av manuelle steg for testing og utrulling, noe som gjorde at vi ikke helt kunne høste alle fordelene ved DevOps.”
Men selv om Docker var et forslag fra meg, var ikke implementeringen av Docker noe jeg bidro til. Min rolle var å godkjenne leveransen på testplattformen sammen med de eksterne utviklerne. Derfra tok den interne driftsavdelingen over og sørget for utrullingen.
Så selv om vi hadde et viktig element av DevOps på plass, manglet vi fortsatt den automatiserte flyten og sømløse deploy-prosessen som en fullverdig CI/CD-pipeline kunne gitt oss.
Hva lærte jeg?
I ettertid ser jeg at vi kunne ha forenklet prosessen ytterligere:
- Enda mer dynamiske milepæler
Noen ting måtte planlegges nøye (hovedstrukturen), mens andre kunne være mer fleksible (hvordan vi bygde hver enhet).
- Automatisering av leveranse
Med CI/CD (Continuous Integration/Continuous Deployment) hadde vi spart tid og unngått flaskehalser.
- Bedre samarbeid på tvers av avdelinger
DevOps handler om mer enn utvikling. Hadde drift og support vært tettere koblet på utviklingsløpet, kunne vi ha identifisert utfordringer tidligere.
Er vi egentlig Agile?
Det store spørsmålet er: Hvor mange bedrifter tror de er Agile, men egentlig jobber etter en hybridmodell?
- Har dere en fleksibel utviklingsprosess, men en rigid lanseringsplan?
- Må dere endre planene konstant fordi roadmap og sprints ikke er helt synkronisert?
- Blir ting fortsatt lansert manuelt, med mye håndholding mellom utvikling og drift?
Da jobber dere kanskje ikke så smidig som dere tror.
Konklusjon: Product Manager som dirigent for symfonien
Som Product Manager trenger du ikke være ekspert på alle prosesser og metoder de forskjellige avdelingene bruker – men det hjelper. Det du derimot må ha, er en overordnet forståelse av hvordan alt henger sammen.
- Agile, Waterfall eller andre metoder?
Det påvirker tidsaspektet og hva du kan forvente. - Markedsføringsteknikker?
De avgjør hvordan du kan koordinere lanseringer med utvikling. - Produktstrategier og prisstrategier?
De sikrer at produktet ditt treffer markedet riktig og kan selges effektivt. - Kunnskap om kundeservice?
Det hjelper deg å forstå hvordan drift og support må koordineres for å skape en god kundeopplevelse. - Og økonomi?
Det må veves inn i hele prosessen – fra tidsbruk og ressursfordeling til kampanjer og produktprioriteringer.
Når du ser det store bildet og forstår hvordan alle brikkene påvirker hverandre, kan du bli en enorm støtte for styret og ledelsen. Du setter ikke bare sammen en plan – du skaper et orkester som spiller en helhetlig symfoni, der hver avdeling bidrar med sin egen melodi, men der alt til slutt må harmonere i tråd med den retningen ledelsen ønsker og har satt.
Vi kan kaste rundt oss med begreper som microservices, lean, Agile, Waterfall og DevOps – men i bunn og grunn handler det om én ting: Hva som faktisk hjelper deg med å levere et godt produkt. Metoden er bare et verktøy, ikke målet i seg selv. Og hvem vet – kanskje det er du som en dag skriver den neste boka og setter navn på en ny metode?
Jobber dere virkelig Agile, eller har dere også en skjult struktur? Hvordan balanserer dere fleksibilitet og planlegging i utviklingsprosjekter? Del dine erfaringer i kommentarfeltet!
Legg igjen en kommentar