Scrum og strategi
Harald Hegerberg. Publisert 07. november 2007 For å reparere myten om at alle IT-prosjekter leverer a) For Sent, b) Over Budsjett og c) Med Irrelevant Funksjonalitet er den gjengse oppfatning at svaret har ankommet. Enter Scrum.
Med hurtige iterasjoner, fokus på burn down og team som ikke konstant forstyrres av endrede krav er framtiden allerede ankommet. Veien blir målet, vi reiser sammen og alle ender på samme sted, på samme side i boken, funksjonaliteten er som avtalt, kvaliteten er i henhold til planlagt nivå - og tid og kostnader er under kontroll.
Andre, gammeldagse metodeverk konsentrerer seg om å planlegge før man går til aksjon - også kalt fossefall. Noen helt klare ulemper med dette er at fossefallsprosjekter har en tendens til å vare lenge, og de kravene man hugde i steintavlene ved prosjektets start er kanskje ikke like viktige lenger. Kostnadsrammene er fastsatt, og rigid endringshåndtering sørger for at det er vanskelig å omprioritere kravene underveis. Dersom man allikevel velger å endre kravene blir tidsrammene forskøvet og man må tilføre mer budsjettmidler. Fordelen, vil mange hevde, er at det er langt lettere å knytte dette til standard kontrakter og juridiske avtaleverk.
I hverdagen oppleves det slik at fossefallsprosjekter betinger en god del støtteleveranser. Dokumentasjon. I utgangspunktet vil det være en god idé å dokumentere sine planer og veivalg, slik at partene er enige om hvilke prioriteringer prosjektet har gjort. Men ofte er det slik at: a) leverandøren må sette av produksjonskapasitet (les: programmerere) for å dokumentere, og b) oppdragsgiver ikke har kompetanse eller tilgjengelig tid til å vurdere planene.
Dersom man i korte iterasjoner KODER i stedet for å dokumentere vil man være produktiv tidligere, og det blir enklere og mer oversiktlig for oppdragsgiver å ta stilling til resultatet, og å prioritere den viktigste funksjonaliteten. At standard kontraktsverk ikke ennå støtter denne partnerorienterte arbeidsformen skal jeg ikke komme nærmere inn på her.
Men: I prosjekter av strategisk natur vil ikke løsningsområdet være tydelig. Målsetningen kan være å øke inntekter; å redusere kostnader; å søke nye forretningsmuligheter. Å starte å kode noe på dag 1 vil i slike tilfeller være en relativt sikker måte å ødsle med tid og penger på. Man vil ikke kunne vite om man er på riktig plattform, med riktig personell, og man kan bare gjette på hva kravene til løsningen kan være.
Ingen fare, sier scrummerne. Scrum kan brukes til alt mulig, også strategiarbeid. Dette er selvsagt 100% korrekt, gitt at HELE prosjektet dreier seg om strategi. Men dersom første iterasjon dreier seg om strategisk fundament, andre iterasjon vil dreie seg om plattform- og leverandørvalg, tredje iterasjon om etablering av infrastruktur etc. har jeg følgende påstand: Dette er fossefall. Og det er fossefall med en uhensiktsmessig metode. Teamet vil måtte endres fra iterasjon til iterasjon, backlog kan ikke videreføres, koding må avvente anskaffelse og leverandørvalg etc. I slike tilfeller vil man være langt bedre tjent med å splitte opp i flere og mindre prosjekter. Eller å benytte en velprøvd fossefallsmodell med faseinndelinger, formaldokumenter og beslutningspunkter.
At Scrum inneholder samspillsregler og oppmuntrer til god internkommunikasjon i prosjektgjennomføring kan bare applauderes. At man har fokus på produktivitet og klare ansvarsforhold likeså. Men som verktøy må det være tilpasset oppgaven.
Hele sprinten trenger nødvendigvis ikke å dreie seg om strategi, men alt som avhenger av strategien bør flyttes til neste sprint. Om man først skal utarbeide strategi og så utøve den i en og samme runde blir det veldig vanskelig å tidsestimere andre runde.
andreas
Enig. Dette var det poenget jeg prøvde å komme fram til: Å ha én sprint som dreier seg om strategi FØR det “egentlige” utviklingsprosjektet starter minner nemlig svært om en mer tradisjonell tilnærming i form av et forprosjekt. I dette forprosjektet må man gjerne bruke scrum som arbeidsform, men spørsmålet er om det egentlig er så egnet?
I strategiprosesser har man ofte svært mange interessenter som må intervjues - og det er kanskje ikke klart hvem som er produkteier, siden det kan være ganske mange produkter å eie. Det er allikevel fornuftig med en iterativ tilnærming til strategiprosesser, siden det ikke alltid er like klart hva den beste veien til målet er, og hvilke prioriteringer man må gjøre underveis.
Sånn jeg ser det fyller Scrum (og andre Agile) metodikker to nyttige roller:
A) Det hjelper oss til å få prosjektene i mål innenfor rimelig tid og med relevant funksjonalitet.
B) Det fyrer opp den (litt) eldre garde som blir stive i blikket og begynner å mumle om at “man kan jo ikke bare….” og “man må jo også…”
En av verdiene som fremheves i Agile manifestet er “Working software over comprehensive documentation”. Jeg tror dette er helt riktig. Det viser seg ofte å være vanskelig å lage gode beskrivelser av software og hvordan skal fungere, særlig gjelder dette når detaljnivået begynner å bli høyt og det som bygges befinner seg “langt unna” i prosjektløpet. Et viktig poeng er også at beskrivelsen ikke bare skal være lesbar for andre arkitekter og utviklere, kunden må også kunne forstå beskrivelsen. Det er her Scrum kan komme til unnsetning med å sette fokus på det man faktisk skal levere, nemlig programvaren. Istedenfor å bruke masse tid på å beskrive hvordan det man bygger ser ut, så viser man heller fram programvaren man bygger og får kundens (og øvrige prosjektdeltageres) reaksjoner på denne - erfaringsmessig er det også dette som gir de beste tilbakemeldingene fra kundene. Et av nøkkelgrepene som Scrum gjør her er altså rett og slett at man istedenfor å beskrive hva man holder på med, så viser man fram det man holder på med - dette blir da også mye mer presist.
Som Harald påpeker er imidlertid ikke alle leveranser av denne typen. En leveranse i f.eks en strategifase er for det første på et helt annet abstraksjons- og detaljnivå enn det en utviklingsleveranse er på, i tillegg har disse leveransene ikke nødvendigvis et mer håndfast resultat enn dokumentasjonen som man kan ta tak i. En konsekvens av dette er at man kanskje ikke lenger har hverken problemstillingen “software vs dokumentasjon” eller mulighet for løsningen i form av “software fremfor dokumentasjon”.
Noen av de viktigste grepene i en strategifase er kanskje å få fram hva konsekvensene av det man foreslår er, og da ikke bare de konsekvensene man kan faktisk kan si noe om, men også de områdene som rett og slett er vanskelig å overskue på det stadiet man er på nå, til en viss grad blir dette risiko som man må ta med seg videre i prosjektet og være forberedt på å håndtere. Tror dette også er viktig, slik at man ikke plutselig tror at man nå er i en prosjektfase hvor vi er altoverskuende og at det vi lager vil overleve uendret gjennom resten av prosjektet.
Scrum til alt og alle formål, (inkludert husarbeidet hjemme) er ikke nødvendig i tråd med det metodikken faktisk ble etablert for å løse.
Scrum brukt i husarbeidet hjemme kunne vært interessant. Denne sprinten skal vi gjøre rent kjøkkenet, og planlegge hvordan vi skal få holdt stuen ren neste måned.
For barnefamilier tror jeg det ikke er egnet, men i enkelte studentkollektiv så burde det vært innført.
Andreas