Smidig modell har sine svakheter

Ti år etter den revolusjonære "The Agile Manifesto" er smidig blitt mainstream og moden.

Over halvparten av Gartners kundebase bruker modellen til et eller annet. Smidig har brakt med seg gode metoder, det jeg liker best er historiefortelling og konsekvent timeboxing. Modellen er dønn iterativ og bygger på hyppige, raske leveranser.

Brukerne er med

En grunnforutsetning for smidig utvikling er at brukerne er tett involvert. Manifestet sier det klart: "Business people and developers must work together daily throughout the project". Brukerne er permanente medlemmer i utviklingsteamet, ikke bare deltakere på møter (hvis de har tid).

En tommelfingerregel sier at mellom 10 og 25 prosent i teamet skal være fra brukersiden. Brukerne forteller, diskuterer, kommenterer og vurderer. Tett samarbeid mellom utviklere og brukere har bestandig vært en drøm, men først med smidig er det blitt en realitet.

En annen styrke er at endringer underveis ikke lenger er hår i suppa. I motsetning til hva vi trodde før kan krav aldri "fryses". "Agiliteten", det vil si forandringsdyktigheten, blir høyere med smidig. Manifestet sier: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage". Så sant som det er sagt.

Svakheter

Hvor ligger så svakhetene? En av dem er at det ikke blir inngått en presis avtale mellom kunde og leverandør om hva som skal leveres når. Det finnes et kart, ja visst, et målområde, en retning, men traseen og endepunktet blir bestemt underveis av teamet selv. Kriteriet er: Hva som gir mest nytte? Dette kan være greit nok for bedriftsintern utvikling, men vanskeligere å leve med i kommersielle forhold. Det krever høyt utviklet tillit mellom partene, begge må være overbevist om at den andre vil ens beste. Tilbudskonkurranser blir vanskelig å avgjøre.

En annen svakhet er forbundet med at utviklingsprosjekter per definisjon skal ta slutt. Akseptanseprøven er bestått, prosjektgruppen skal avvikles og resultatene overleveres til drift og videre forvaltning. Uansett hvilken utviklingsmodell som blir valgt er dette et kritisk punkt.

I Gartners oppfatning er smidig ikke så mye en prosjektmodell, heller en modell for produktutvikling. Det vil si at det samme produktteamet er ansvarlig både for utvikling og videreutvikling. De jobber på og leverer stadig nye funksjoner i en evig strøm. Utviklingen tar ikke slutt så lenge produktet lever. I og med at smidig legger liten vekt på å produsere dokumentasjon, er det en nødvendig forutsetning å beholde den samme gjengen.

Upresist definert

Utvikling skal finansieres, men det er vanskelig å avgjøre hvor mye penger som skal settes av til arbeid der verken sluttresultatet eller veien frem er presist definert. I praksis blir det bevilget en stor slump med penger først og eventuelt mindre summer etter hvert, ofte med mye skrik og skrål. Tenker man på modellen som produktutvikling, er det helt naturlig å finansiere arbeidet på løpende basis.

Kulturelt sett er det stor forskjell mellom fossefalls- og smidig modell. Fossefall er prosjektleder-drevet, smidig er teamdrevet. Utviklere som gjennom mange år har vent seg til klassisk fossefall der det som er spesifisert skal leveres, har ofte problemer med å trives med den utfordrende stil og grenseløse transparens som Scrum baserer seg på. Alle ser alt. Det skal gå fort. Kulturforandringer tar tid, de foregår gradvis. Det er ikke nok å beslutte at "nå gutter og jenter skal vi gå over til Scrum", og så er alt bare smil og bakkenbarter.

Utvikling foregår mellom to ekstremer. Den ene enden kaller Gartner "opportunistisk", det vil si små applikasjoner med få brukere og relativt lave krav til kvalitet, som ikke skal leve så lenge. Den andre enden kalles "systematisk", det vil si tunge, skalérbare applikasjoner med langt liv og høye krav til servicenivå. Smidig kan ha noe for seg i begge ekstremer, men er mest brukt for de mer opportunistiske behov. For at en organisasjon skal få virkelig suksess med smidigmodellen i systematiske, virksomhetskritiske situasjoner, kreves det gode planer og forberedende modellering, akkurat som i fossefallsprosjekter. Mener jeg, ihvertfall.

Å bevege seg til smidig dreier seg først og fremst om kultur og tilvenning. Det vil si hårete saker. Smidig er i vinden, men fossefall er ikke død.