Utfordringer ved Overgang til Smidige Programvareløsninger
Når virksomheter skifter fra tradisjonelle driftsmodeller til skybaserte løsninger, er et av de vanligste målene å oppnå økt smidighet. Dette gjelder ofte for hele organisasjonen, fra topp til bunn, og ideelt sett umiddelbart.
I teorien kan prosessendringer virke enkle. Man kan innføre scrum-seremonier og omplassere ansatte til nye roller som scrum-mastere, produkteiere og utviklingsteam. Verktøy som Jira, Azure DevOps og Miro-tavler kan også tas i bruk. Men hva med samspillet mellom disse verktøyene? Hva med å endre tankesett, atferd og arbeidsmåter? Det er her vi ser at endringsprosessen ikke alltid går knirkefritt eller raskt. La oss se nærmere på hvorfor.
Hva er et Leveransetransformasjonsinitiativ og hvorfor Gjennomføres det?
Mange bedrifter benytter fortsatt den tradisjonelle fossefallsmetoden for leveranse. Dette innebærer:
- Først å planlegge det endelige produktet og estimere kostnadene.
- Deretter å starte en omfattende prosess for kravspesifikasjon, inkludert detaljerte diskusjoner, spørsmål, enighet og eventuelle nye diskusjoner.
- Å bekrefte budsjettet basert på estimater.
- Å designe løsningen, ha møter med interessenter, utarbeide dokumentasjon, innhente tilbakemeldinger og godkjenne det funksjonelle og tekniske designet.
- Å implementere løsningen basert på designet, det vil si å utvikle det ferdige produktet.
- Å gjennomføre ulike tester som enhetstester, systemtester, funksjonstester, integrasjonstester, ytelsestester, regresjonstester og brukertester, samt dokumentere og innhente godkjenning.
- Å distribuere løsningen til produksjonsmiljøet hvor brukerne tar det i bruk.
- Å planlegge en supportfase for å korrigere eventuelle feil.
Hele denne prosessen kan ta fra noen måneder til flere år, og resultatene blir først synlige mot slutten. Dette medfører en lang ventetid før man får se om løsningen er vellykket eller ikke.
Dersom det oppstår endringer underveis, kreves en endringsforespørsel, noe som innebærer at designet må revideres og godkjennes på nytt. Dette forlenger tidsplanen ytterligere.
Det er tydelig at denne metoden ikke er smidig. Hver endring krever en omstart av hele prosessen.
Overgang til Smidige Metoder
Hvordan kan vi endre denne situasjonen og bli mer smidige? Ansatte har ofte jobbet med fossefallsmetoden i mange år og er komfortable med sine roller og ansvar. En overgang til smidige metoder kan oppleves som en trussel mot deres innarbeidede posisjoner, og dette skaper motstand.
Endringer av denne typen kan derfor fremprovosere sterk motstand fra de berørte.
#1. Omstrukturering av Team
Det første og relativt enkle steget er å omstrukturere de ansatte i scrum-team. Dette kan gjøres basert på funksjonsområder eller annen logisk inndeling.
Selve inndelingen går ofte greit, men problemet oppstår når ansatte fortsatt er knyttet til de gamle strukturene. Selv om de er en del av et nytt scrum-team, jobber de i praksis fortsatt etter gamle oppsett, fordi de fremdeles har uavsluttede oppgaver fra den gamle organiseringen. Ledelsen fokuserer ofte mer på å starte nye ting, enn å fullføre gamle.
Dette resulterer i et scrum-team som ikke er fullt dedikert. Det er rett og slett en gruppe mennesker som nå har mer å gjøre. Det blir mindre tid til scrum-relatert arbeid, samtidig som forventningen fra ledelsen er at de skal levere i de nye scrum-teamene. Denne situasjonen er ofte dømt til å mislykkes.
#2. Planlegging av Scrum-Seremonier
Det er lett å beordre teamene til å delta i regelmessige scrum-møter (sprintseremonier). I det minste hvis teamene ikke er spredt over flere tidssoner, noe som ofte er tilfellet.
Problemene oppstår når folk ikke deltar regelmessig. Dette kan føre til ulike problemer, avhengig av hvem som mangler og hvor ofte. For eksempel:
- Hvis produkteiere ikke deltar på planleggings- og foredlingsseremonier, har teamet ingen nye oppgaver å jobbe med. Eller beskrivelsen av oppgavene er så dårlig at teamet ikke kan starte arbeidet.
- Hvis scrum-mastere mangler, mister teamet grunnleggende scrum-orkestrering.
- Hvis teammedlemmer ofte mangler, blir det vanskeligere for teamet å synkronisere arbeidet og kommunisere effektivt. Det krever også flere møter for å ta igjen, som igjen stjeler tid fra andre oppgaver.
Det er ikke nødvendigvis ansattes feil at de ikke deltar. Det er selve oppsettet som gjør det vanskelig, ofte på grunn av parallelle oppdrag som nevnt over.
#3. Teamets Stabilitet
Et scrum-team med struktur og seremonier vil ikke utvikle seg uten stabilitet over tid. Et halvt år er et minimum, og et år er ideelt. Uten stabilitet kan teamet ikke forbedre seg, og man oppnår ikke et fullt uavhengig team som håndterer spurtene på en effektiv måte. Man må stadig utdanne og lære opp teammedlemmene for at de skal forstå scrum-tankegangen og prosessene. Dette er en utfordrende situasjon å håndtere.
Ledelsen undervurderer ofte denne utfordringen. Å se på teammedlemmer som «ressurser» og planlegge deres «utnyttelse» fra kvartal til kvartal er en sikker vei til ineffektivitet.
#4. Nye Roller for de Samme Ansatte
En annen hindring er å omplassere ansatte til nye roller. De som tidligere hadde lederstillinger med stor innflytelse, kan nå bli produkteiere. Selv om dette er en viktig rolle i et scrum-team, kan det oppleves som en svekkelse av deres tidligere status.
Produkteiere må nå synkronisere med scrum-mastere og prosjektledere. De er fortsatt ansvarlige for innholdet, men ikke for leveringsprosessene. Dette krever at de gir opp noe av sitt tidligere ansvar, noe som kan være vanskelig.
#5. Arbeidsmetoder
Det er vanlig å høre at man må lære nye arbeidsmetoder for å være konkurransedyktige i et marked der smidighet er et krav. Men hva betyr egentlig disse nye arbeidsmetodene?
Fra ledelsens perspektiv handler det ofte om å oppnå mer på kortere tid. Etter å ha etablert scrum-team, forventes det at hvert teammedlem leverer dokumenterte resultater daglig. Hvis dette ikke skjer, stiller ledelsen spørsmål ved om den smidige prosessen fungerer som den skal.
Ledelsen forventer at hvert minutt skal telle og at scrum-teamene ikke skal ha noe ledig tid, rett og slett fordi alle prosessene er på plass. Dette er ledelsens definisjon av «nye arbeidsmetoder».
Denne forventningen er ikke realistisk. Man kan ikke forvente at ansatte skal jobbe mer bare fordi prosessene er endret. Noen vil kanskje jobbe mer, men selv denne gruppen blir begrenset ved å fylle dem med for mange oppgaver.
Forskjellen Mellom Mål og Virkelighet
Beskrivelsen av det ønskede sluttmålet er ofte god og fornuftig. Den bygger på følgende prinsipper:
- Stabile scrum-team som jobber med uavhengige backlogs med tydelige KPI-er og OKR-er.
- Produkteiere som utvikler gode veikart og planlegger innhold som leveres i henhold til tidsplaner.
- Definert backlog-innhold med detaljerte funksjoner før arbeidet starter.
- Pålitelige testprosesser utføres samtidig med den vanlige sprintutviklingen.
- Regelmessige utgivelser til produksjon, helst etter hver sprint, men minst en gang i måneden.
- Risikohåndtering og kommunikasjon mellom scrum-teamene i tilfelle avhengigheter.
I realiteten er det vanskelig å oppnå disse punktene:
- Scrum-teamene er ikke stabile og endres ofte. Man investerer tid i opplæring, men når teamet begynner å forstå prosessen, omorganiseres teamet. Veikart endres, utsettes eller kanselleres.
- Produkteiere har ikke full oversikt over detaljene i veikartet, og delegerer oppgaver om å bygge backlog-innhold direkte til teamet. Teamet må derfor bruke tid på å finne ut hva de skal utvikle, i stedet for å utvikle.
- Testprosesser er manuelle og krever mange trinn, godkjennelser og komplekse prosesser. Testingen kan derfor ikke fullføres innenfor samme sprint som utviklingen.
- Utgivelser til produksjon henger ofte flere sprinter bak.
- Kommunikasjonen mellom teamene er kaotisk og ineffektiv. Produkteiere gir ofte teamet for mye innhold hver sprint, noe som fører til stress fordi det er umulig å fullføre alt.
Rettelse av Feilene
Basert på erfaring fra flere smidige transformasjonsprosjekter, vil jeg oppsummere noen av de vanligste feilene og gi subjektive meninger om hvordan de kan overvinnes.
#1. Rett Ansvar for Riktige Roller
Å fordele ansvar på en annen måte enn hva som er definert i scrum-prinsippene, vil føre til at hele initiativet mislykkes.
- Produkteiere skal eie innholdet og vedlikeholde backloggen. De er ansvarlige for historiene i backloggen, og dersom disse ikke er godt definert, må de ta grep for å rette på det. De skal derimot ikke ha innflytelse på scrum-teamets oppgaver eller budsjettbeslutninger.
- Scrum-mastere skal ikke ha ansvar for backlog-innholdet. De skal orkestrere seremoniene og utdanne teamet i smidige arbeidsmetoder. De skal ikke være sekretærer for produkteierne, men beskytte teamet mot produkteiere og andre interessenter.
- Hvert scrum-team bør ha en leveranseleder. Denne personen skal knytte sammen produkteier, scrum-master og utviklingsteamet, definere leveringsprosesser og løse eventuelle risikoer, problemer eller konflikter. Leveranselederen er ansvarlig for bemanning og budsjett. De skal skape et miljø der alle kan yte sitt beste.
- Utviklingsteamet skal utvikle historiene fra backloggen. De kan bistå produkteier med å utvikle innhold for enkelte historier, men er ikke ansvarlige for innholdet som bygger opp veikartet.
#2. Stabilt Team
Det er viktig å investere i teamets smidige utdanning. Å la denne kunnskapen forsvinne etter noen måneder er bortkastet tid.
De fem første sprintene kan brukes som en læringskurve for å bli kjent med scrum-aktivitetene. Når hele teamet er komfortabelt med disse, kan man starte den kontinuerlige forbedringsprosessen. Hvis teamet endres regelmessig, vil man ende opp i en evig loop av kunnskapsoverføring og opplæring. Et slikt team vil neppe nå sitt fulle potensial, og ledelsen vil lure på hvorfor det var mer effektivt før.
Så bygg teamet, invester i kunnskap og behold teamet stabilt for videre utvikling. Da kan den konstante veien mot perfeksjon begynne.
#3. RACI-Matrise
Det er fornuftig å lage og avtale en RACI-matrise (Responsible, Accountable, Consulted, Informed) mellom alle teamene før man starter arbeidet. Dette kan eliminere mye forvirring fra starten.
Dette er spesielt viktig i de tidlige fasene av transformasjonsinitiativet. Ellers vil folk begynne å lure på hvem som skal gjøre hva, spesielt i situasjoner som ikke er eksplisitt definert.
Her er et eksempel på en RACI-matrise for noen ansvarsområder. Ditt prosjekt kan ha et annet sett. Det er viktig å fange opp de aktuelle.
| Oppgave | Requestor | Leading Lead | Product Owner | Scrum Master | Dev Team |
| Sprint Planning Sessions | C/I | C/I | A/R | C/I | I |
| Deliver Release Increment | N/A | I | A/I | C/I | R |
| Sprint Review | C/I | I | R | I | C/I |
| Sprint Retrospective | I | I | A/I | R | C/I |
| Definer Backlog | I | A/R | C/I | I | C/I |
Konklusjon
Det er mye mer å skrive om, ettersom det er mange måter en smidig transformasjon kan spore av på. Hensikten var å peke på noen av de vanligste problemene. Selve initiativet er en god idé. Det kan fort bli et mareritt hvis man ikke følger noen grunnleggende regler. Jeg har fremhevet noen av dem. Bruk sunn fornuft, så går det som regel bra. 🙂
Til slutt anbefales det å sjekke ut gode læringsressurser for Agile-sertifisering.