Af Anne Dam Jensen, PRINCE2 Agile Træner
Flere og flere private og offentlige organisationer implementerer agile metodikker i disse dage. Udover håbet om den tidlige gevinstrealisering og hurtige læring er mange af den opfattelse, at den agile tilgang reducerer risikoniveauet kraftigt.
Hvor der kan være en del sandhed i de to første opfattelser, kan en agil tilgang ikke reducere risikoniveauet. Læs hvorfor i artiklen:
Flere og flere private og offentlige organisationer implementerer agile metodikker i disse dage. Udover håbet om den tidlige gevinstrealisering og hurtige læring er mange af den opfattelse, at den agile tilgang reducerer risikoniveauet kraftigt.
Hvor der kan være en del sandhed i de to første opfattelser, kan en agil tilgang ikke reducere risikoniveauet. Læs hvorfor i artiklen:
Den agile tilgang kan højst reducere risikoen for, at vi leverer det forkerte produkt, og dét er under den forudsætning, at den agile tilgang anvendes korrekt, og organisationen også implementerer den adfærd, som er så vigtig for, at de agile tilgange, rammer og værktøjer fungerer korrekt.
Hvad mange måske glemmer er, at den agile tilgang har iboende risici, som bliver nødvendige at styre:
Hvad kan man gøre for at imødegåisse risici? Man kan jo altid sørge for, at alle i organisationen er klædt ordentligt på, og at alt kører efter bogen, men det er vist kun i teoribøger, at verdenen ser sådan ud.
Her følger nogle af de råd, som jeg vil give til en projektleder, der arbejder agilt og har identificeret nogle af disse risici:
1. Risiko: Lille fleksibilitet
Man skal huske, det at scope eller de-scope projektet drives af forretningen/brugerne, men er en teamindsats. Hvis din styregruppe ikke er med på, at fleksibilitet og prioritering er en ting, der kan diskuteres, så prøv at forklare den, at prioritering og fleksibilitet af omfang/scope er afgørende for at beskytte kvaliteten af leverancen og sikre, at projektorganisationen kan overholde deadlines.
Mange styregrupper er desværre af den opfattelse, at scope er det samme som kvalitet, så det gælder om at forstå forskellen, om at få indgået gode aftaler om prioritering. I yderste tilfælde kan det være, at trykteste den manglende prioritering ved at spørge om følgende: ”Hvis I ikke får det hele, vil I så ingenting have?”
2. Risiko: Manglende Product Owner
Det ses til stadighed, at teams udvikler og tester produkter uden tilgang til en repræsentant fra kunden.
Mange kunder entrerer med eksterne leverandører uden at afsætte de nødvendige ressourcer til at arbejde med leverandørens team. Til leverandøren vil mit råd være: Sørg for at stille et krav om, at jeres kunder stiller med en repræsentant, hvis I skal arbejde agilt.
Hvis kunden ikke kan/vil det, så bed om produktbeskrivelser og hejs risikoflaget omkring fejlleverance: I risikerer at levere det forkerte produkt - ikke at produktet er leveret forkert.
Til kunden, som ikke kan få direkte adgang til leverandørens agile team, er rådet: Find en anden leverandør. Det er din business case, der bliver hårdest ramt.
3. Risiko: Geografisk spredte teams
I it-branchen sendes mange udviklings- og testopgaver stadigt til udlandet med de kommunikative problemer, som dette medfører – ikke kun pga. distance, men også pga. sprog-, kultur- og tidsforskelle, etc.
Jeg ved, at det er billigere, men man introducerer risici i projektet, som kan koste på den lange bane. Nogle af de penge, der spares kunne måske bruges til at lære at forstå hinanden noget bedre. Lave fælles kick-off møder, indkøbe godt videoudstyr og dygtiggøre sig i anvendelse af mange af de internetplatforme, der indeholder videomuligheder. Udveksling af ressourcer (bytte arbejdsplads) kan også afhjælpe noget af denne risiko.
Til det sidste skulle man måske også overveje, hvor agil man egentlig kan være i sådan et set-up. Måske skal man kravspecificere noget mere eller trække nogle af de meget udviklende eller innovative opgaver hjem. Opgaver, der kræver at forretning- og leverandørsiderne kan arbejde tæt sammen.
4. Risiko: Detaljerede kontrakter
Der arbejdes måske med en ekstern leverandør, hvor samarbejdet har ringe grad af tillid. Der har været hårde kontraktforhandlinger, og alt er derfor specificeret til punkt og prikke. Der er dermed overhængende risiko for at få leveret det specificerede produkt, men som ingen længere har behov for.
Hvordan kan man imødegå denne risiko? Prøv at se på jeres standardkontrakter. Er der mulighed for at specificere leverancen ud fra outcome (læs: resultat) i stedet for output (læs: produkt). Det er den svære øvelse at kunne angive retning uden at låse specifikationen. Så måske skal der bygges prototyper, måske skal der defineres minimal viable product for at få hurtig valideret læring.
Overvej også, om du som kunde skal købe udviklingstid og testtid i dine kontrakter. Det kræver selvfølgelig, at du har sat dig godt ind i, hvordan leverandørens folk arbejder, og hvordan de udvikler dine produkter. Men det er dine produkter, dine penge og dermed din business case… og dine risici.
© Anne Dam Jensen, PRINCE2 Agile Træner og PR2 – Januar 2018
Hvad mange måske glemmer er, at den agile tilgang har iboende risici, som bliver nødvendige at styre:
- Risiko: Styregruppen vil ikke prioritere leverancerne – og slet ikke up-front.
- Risiko: Din Product Owner (eller tilsvarende rolle) er ikke til stede.
- Risiko: Dine teams er geografisk spredt.
- Risiko: En meget detaljeret specifikation i kontrakten mellem kunde og leverandør.
Hvad kan man gøre for at imødegåisse risici? Man kan jo altid sørge for, at alle i organisationen er klædt ordentligt på, og at alt kører efter bogen, men det er vist kun i teoribøger, at verdenen ser sådan ud.
Her følger nogle af de råd, som jeg vil give til en projektleder, der arbejder agilt og har identificeret nogle af disse risici:
1. Risiko: Lille fleksibilitet
Man skal huske, det at scope eller de-scope projektet drives af forretningen/brugerne, men er en teamindsats. Hvis din styregruppe ikke er med på, at fleksibilitet og prioritering er en ting, der kan diskuteres, så prøv at forklare den, at prioritering og fleksibilitet af omfang/scope er afgørende for at beskytte kvaliteten af leverancen og sikre, at projektorganisationen kan overholde deadlines.
Mange styregrupper er desværre af den opfattelse, at scope er det samme som kvalitet, så det gælder om at forstå forskellen, om at få indgået gode aftaler om prioritering. I yderste tilfælde kan det være, at trykteste den manglende prioritering ved at spørge om følgende: ”Hvis I ikke får det hele, vil I så ingenting have?”
2. Risiko: Manglende Product Owner
Det ses til stadighed, at teams udvikler og tester produkter uden tilgang til en repræsentant fra kunden.
Mange kunder entrerer med eksterne leverandører uden at afsætte de nødvendige ressourcer til at arbejde med leverandørens team. Til leverandøren vil mit råd være: Sørg for at stille et krav om, at jeres kunder stiller med en repræsentant, hvis I skal arbejde agilt.
Hvis kunden ikke kan/vil det, så bed om produktbeskrivelser og hejs risikoflaget omkring fejlleverance: I risikerer at levere det forkerte produkt - ikke at produktet er leveret forkert.
Til kunden, som ikke kan få direkte adgang til leverandørens agile team, er rådet: Find en anden leverandør. Det er din business case, der bliver hårdest ramt.
3. Risiko: Geografisk spredte teams
I it-branchen sendes mange udviklings- og testopgaver stadigt til udlandet med de kommunikative problemer, som dette medfører – ikke kun pga. distance, men også pga. sprog-, kultur- og tidsforskelle, etc.
Jeg ved, at det er billigere, men man introducerer risici i projektet, som kan koste på den lange bane. Nogle af de penge, der spares kunne måske bruges til at lære at forstå hinanden noget bedre. Lave fælles kick-off møder, indkøbe godt videoudstyr og dygtiggøre sig i anvendelse af mange af de internetplatforme, der indeholder videomuligheder. Udveksling af ressourcer (bytte arbejdsplads) kan også afhjælpe noget af denne risiko.
Til det sidste skulle man måske også overveje, hvor agil man egentlig kan være i sådan et set-up. Måske skal man kravspecificere noget mere eller trække nogle af de meget udviklende eller innovative opgaver hjem. Opgaver, der kræver at forretning- og leverandørsiderne kan arbejde tæt sammen.
4. Risiko: Detaljerede kontrakter
Der arbejdes måske med en ekstern leverandør, hvor samarbejdet har ringe grad af tillid. Der har været hårde kontraktforhandlinger, og alt er derfor specificeret til punkt og prikke. Der er dermed overhængende risiko for at få leveret det specificerede produkt, men som ingen længere har behov for.
Hvordan kan man imødegå denne risiko? Prøv at se på jeres standardkontrakter. Er der mulighed for at specificere leverancen ud fra outcome (læs: resultat) i stedet for output (læs: produkt). Det er den svære øvelse at kunne angive retning uden at låse specifikationen. Så måske skal der bygges prototyper, måske skal der defineres minimal viable product for at få hurtig valideret læring.
Overvej også, om du som kunde skal købe udviklingstid og testtid i dine kontrakter. Det kræver selvfølgelig, at du har sat dig godt ind i, hvordan leverandørens folk arbejder, og hvordan de udvikler dine produkter. Men det er dine produkter, dine penge og dermed din business case… og dine risici.
© Anne Dam Jensen, PRINCE2 Agile Træner og PR2 – Januar 2018
