Linjegym eller nakkesleng

Jeg er ikke blant dem som synes at smidig utvikling alltid er det beste. Jeg tror mer på å velge riktig modell blant flere – å anvende en modell som ikke passer kan ende i katastrofe.

Noen ganger passer ingeniør-tankegangen best: Først spesifisere, siden bygge. I andre tilfeller er "adaptive" metoder bedre – spesifisere litt, bygge litt, finne veien etterhvert. Valget har mye med organisasjonskultur å gjøre. Noen organisasjoner er hierarkiske, de er ofte risikosky, de vil ikke være med på en reise som blir til mens de går. Andre er mer frittflytende, de delegerer mer, tillater sine folk å gripe mulighetene selv om det kan gå feil. De som velger utviklingsmodell må forstå hvilken type organisasjon de har med å gjøre.

To akser

Gartner nærmer seg dette valget uten forutfattede meninger. Tenk deg to akser som skaper et firedelt handlingsrom. Den horisontale aksen er forandringshastigheten. Er virksomheten og forretningsmodellen stabil? Har den vært det lenge? Er det grunn til å tro at tempoet plutselig skulle forandre seg? På venstre ende av denne aksen er de mer statiske, på høyre de mer forandringsutsatte virksomheter der fremtiden er ukjent. Den kan se helt annerledes ut om to år.

Den vertikale aksen har med prosessmodenhet å gjøre. Er organisasjonen vant til å tenke i prosesser og medarbeiderne villige til å følge dem? På den ene enden av denne aksen er virksomheter som enten ikke forstår vitsen med prosesser eller ikke er opptatt av å følge dem. Vi kan godt si at prosessene er implisitte her, de er i hodene på folk. På den andre enden er de som er vant til å beskrive sine prosesser eksplisitt, de forstår fordelene med at folk jobber på forutbestemte måter.

Nå har vi vår firedeling. I nedre venstre hjørnet er de virksomheter som ikke er opptatt av prosesser og lever i en relativt statisk virkelighet. De er ikke særlig glad i å legge innsats i å organisere seg, de tenker på det som byråkrati. På en modenhetstrapp står de på trinn 1, det vil si kaotiske forhold. For dem er modellen "Code-and-Fix". Det går nok bra, sett i gang. Det gjelder å komme raskest mulig til programmeringsfasen, planlegning er snikk-snakk. Prosjektene tar så lang tid som de tar. De ender enten i katastrofe eller i blomsterbuketter til de nøkkelpersoner som klarte å redde prosjektet. "Local heroes" kalles de, og alle føler at uten dem hadde det aldri gått. Modellen virker best hvis det finnes en karismatisk leder som de andre følger.

RAD 1980

Nedre høyre hjørne er for dem som ikke er særlig glade i prosesser, men lever i en foranderlig verden. Gartner kaller firkanten "RAD 1980" som betyr Rapid Application Development slik det ble praktisert på 1980-tallet. En annen forkortelse kunne vært LDPR som står for Leverer Dårlig Programvare Raskt. Det er verre enn Code-and-Fix fordi endringstakten er høy, men programvaren er ikke laget for å tåle det. Kaos er alltid bare noen meter unna.

I øverste venstre hjørne er de som følger eksplisitte prosesser selv om endringstakten ikke er så høy. Her er det CMMI og ISO 12207 som rår. Det er hva vi pleier å kalle Software Engineering: Bygge programvare slik ingeniører skal gjøre, alltid ut fra avtalt spec. Dele opp oppgaven i biter, planlegge, planlegge, planlegge. Ofte jobbes det gjennom iterasjoner. De som gjør jobben er godt kjent med oppgaveområdet. V-modellen, kvalitetssikring – de bruker dem alle. Her passer den utskjelte fossefallsmodellen utmerket.

I øverste høyre hjørne er de organisasjoner som er utsatt for hyppige endringer, men er prosessvante. Her sitter den smidige utviklingsmodellen godt. Hensikten med smidig er nettopp å absorbere på en naturlig måte de endringer i forutsetninger som skjer. Gjøre det som er nyttigst akkurat nå. Bygge i små biter, teste resultatene hele tiden, bevege seg i sikk-sakk mot et bevegelig mål.

Ikke for alle

Smidig er bra, men passer ikke for alle. Tilliten mellom kunde og leverandør må være meget stor (uansett om leverandøren er intern eller ekstern), kunden må være villig til å sette av nøkkelressurser til prosjektet, de som betaler må kunne bevilge penger avhengig av fremdriften og behovene.

Valg av modell må være realistisk, må gå ut fra der organisasjonen er, ikke fra der utviklerne gjerne ville hatt den. Og uansett hvilken modell som blir valgt, er det behov for gode arbeidsprosesser.