Prosjektveiviseren med Scrum
Vanskelig kombo
Når jeg forstod at Direktoratet for IT (Difi) hadde tenkt å tilby kurs i Prosjektveiviseren med Scrum fikk jeg umiddelbart lyst på denne utfordringen. For utfordrende er det til gangs!
Disse to rammeverkene kommer i utgangspunktet fra to ulike verdener og lar seg ikke i uten videre kombinere på en enkel måte. Scrum er et svært enkelt – og dermed tilpasningsdyktig – rammeverk med noen få klare aktiviteter og regler, definert i Scrumguiden (juli 2016). Det er ikke rom for å endre på Scrum.
Her er presentasjonen om dette temaet fra #SmidigDig. Her er video av foredraget.
Ulikhetene
Prosjektveiviseren er en tradisjonell “Tall-gate” eller “Phase-gate” modell med faser i sekvens. Formelle beslutningspunkter i faseovergangene. Fokus er på “ovenifra-og-ned” styring (virksomhetsstyring, prosjekteierstyring og prosjektstyring). Jeg har selv vært med på å lage slike (for en del år siden).
Virksomheten utreder en idé og utarbeider mulige konsepter. Grundig analyse og planlegging i starten. Deretter starter et prosjekt som lager mer detaljerte planer og analyser og deretter gjennomfører prosjektet iht plan. Prosjektet avsluttes og resultatet overføres tilbake til virksomheten som realiserer de planlagte gevinstene.
Prosjektveiviseren er “dokumentdrevet” og krever at alt som utarbeides lagres i ulike forhåndsdefinerte dokumenter. Kommunikasjonen mellom de ulike interessentene foregår altså i stor grad gjennom dokumenter. Følger man denne veiviseren vil man estimere omfanget for deretter å låse dette. Endringer som kommer etter dette skal gjennom formell endringsbehandling. Veiviseren åpner for at man kan iterere i gjennomføringsfasen, men tar ikke stilling til hyppige eller én enkelt leveranse. Gevinster realiseres – som man lett ser av figuren – på slutten.
Scrum er et enkelt rammeverk for smidig gjennomføring av kunnskapsarbeid – opprinnelig laget for programvareutvikling. Smidig ble definert som en slags motreaksjon mot de plan- og dokumentdrevne, ovenifra-og-ned-orienterte modellene som dominerte i 2001.
Scrum er basert på empirisk prosesskontroll i korte iterasjoner, hvilket innebærer at man trygt kan starte et initiativ uten alt for mye forarbeid. Smidig foreskriver helt eksplisitt at graden av forarbeid må holdes på et minimum. Alle iterasjonene skal resultere i et ferdig produktinkrement som skal evalueres i samarbeid med interessenter/brukere; Skal vi levere det? Er vi på rett vei og kan fortsette, eller må vi justere kursen – eller kanskje avbryte hele satsningen? Og hva fungerte godt som vi skal fortsette med og hva skal vi forbedre i neste sprint?
Scrum baserer seg på at alt arbeid gjøres av tverrfaglige, selvorganiserende team med myndighet til å fatte raske selvstendige beslutninger. Alle team har en Produkteier som vedlikeholder en produktkø – en dynamisk og ordnet liste over det som skal gjøres. I Scrum går kommunikasjonen først og fremst gjennom å skape gjennomsiktighet. Avhengigheter (Impediments) bekjempes, slik at kommunikasjonsbehovet holdes på et minimum. De som behøver å vite status kan enkelt se hva som foregår gjennom alle de hyppige leveransene og gjennom å følge med på produktkøens utvikling. Den mest kraftfulle formen for kommunikasjon skjer ansikt-til-ansikt.
Det er mulig å følge de fleste Scrum-reglene uten å være særlig smidig i henhold til manifestet. Og det er fullt mulig å jobbe i iterasjoner uten å ende opp med et helt ferdig inkrement. Det er selvsagt mulig (og alt for vanlig) å unnlate å forbedre prosessene i hver sprint. Det er fullt mulig å låse omfanget på forhånd, selv om man har til hensikt å lære underveis og forventer store endringer. Og det er fullt mulig å lage team som ikke fullt ut er selvstyrte eller tverrfaglige. Spørsmålet er om det er særlig smart.
Som man nå forstår baserer disse to modellene seg på to ulike tankesett. Med Prosjektveiviserens innebygde tankesett vil vi resonnere “dette kommer til å bli vanskelig og krevende – så her må vi gjøre grundig forarbeid”.
Med smidig tankesett vil vi tenke “dette kommer til å bli vanskelig og krevende – så her må vi komme i gang raskt slik at vi vinner erfaring”.
Ulike leveransemodeller
Det er altså mulig å bruke Scrum uten å være særlig smidig. Dette vil være nødvendig for mange organisasjoner for å komme i gang. Vi må ikke være naive og tro at en tradisjonell organisasjon kan endre tankesett over natta. Dette vil være en evolusjon i retning av gradvis hyppigere leveranser. Derfor kan det være fornuftig å se nærmere på ulike måter å bruke prosjektveiviseren på – alt fra den helt tradisjonelle med en leveranse på slutten, til den smidige varianten der man må gjøre visse grep for å tillate hyppige leveranser og læring underveis. Jeg har kalt dem type 1 til type 4.
Disse typene er ikke tatt ut av løse lufta. Jeg har hatt mange på Scrum kurs (ca 1000 de siste 5 årene) der mange enten jobber i offentlig sektor eller er konsulenter i offentlige prosjekter. Så disse typene er et resultat av det jeg har oppfattet gjennom dialogen i kursene.
Type 1: Basismodellen
Kjennetegn:
- Grundig analyse, utredning og planlegging.
- Komplett, låst omfang
- Én leveranse
- Gevinstrealisering på slutten
Anvendelsesområde: Når brukernes behov og løsningen er godt forstått. Lite endringer underveis.
Utfordring: Stor risiko, da antagelser får leve helt til slutten. Usikker og svært sen gevinstrealisering.
Type2: Iterasjoner
Kjennetegn:
- Grundig analyse, utredning og planlegging.
- Komplett, låst omfang
- Iterasjoner med leveranse til “test-system”
- Én leveranse
- Gevinstrealisering på slutten
Anvendelsesområde: Når brukernes behov er godt forstått. Løsningen er middels godt forstått. Lite endringer underveis.
Utfordring: Stor risiko, da antagelser får leve helt til slutten. Usikker og svært sen gevinstrealisering.
Type3: Inkrementer
Kjennetegn:
- Grundig analyse, utredning og planlegging.
- Komplett, låst omfang – som regel grovt definert
- Iterasjoner med ekte leveranser
- Løpende gevinstrealisering
Anvendelsesområde: Når brukernes behov er middels godt forstått. Løsningen er usikker og trenger utprøving. Lite endringer underveis.
Utfordring: Endring fremdeles kostnad; Galopperende kostnader da endringene som kommer fra lærdommen fra inkrementene lett fører til tillegg.
Type4: Smidig
Kjennetegn:
- Rask analyse og planlegging med andre metoder enn tradisjonelle (Build-Measure-Learn, Lean Canvas, User Story Mapping, Impact Mapping, Co-Design etc)
- Solid visjon
- Åpent omfang
- Iterasjoner med ekte leveranser
- Løpende gevinstrealisering
Anvendelsesområde: Innovasjon; Når brukernes behov er uklare og løsningsrommet er åpent og trenger utprøving. Forventer endringer og læring underveis.
Utfordring: Stor endring for hele verdikjeden. Manglende kompetanse på de ulike smidige metodene og teknikkene. Manglende kontinuerlig totalintegrasjon blir smertefullt.
Konklusjon
Man kan velge å bruke Scrum som gjennomføringsmodell på mange ulike måter i kombinasjon med Prosjektveiviseren. Spørsmålet er hva man baserer valget på. Dette kreve modenhet og evne til å gjøre en informert selvevaluering.
Når usikkerheten og kompleksiteten er stor bør man altså gå for Type 4 som nettopp er en problemløsningsprosess for slike utfordringer. Dette er den eneste muligheten for å jobbe smidig. Fremtiden vil kreve utstrakt bruk av denne typen prosesser. Det er fullt mulig å følge en metode til punkt og prikke, uten å oppnå det man ønsker. Gode metoder og rammeverk er fint og viktig, men det er ikke nok. Fremtiden vil kreve at vi tenker på en slik måte at vi lett tar inn læring og endringer underveis.
På kurset Prosjektveiviseren med Scrum vil vi bruke en hel dag på å gå igjennom slike beslutningsprosesser og å drøfte fordeler og ulemper med ulike modeller og tankesett.
Mer info om kurset og påmelding her
In: ledelse, prosjektledelse, Scrum · Tagged with: organisasjon, prosjektstyring, Scrum, Smidig, Styring