Tekst: Darija S. Hauge
Vil du bli innovativ og effektiv? TgM intervjuer noen progressive hoder for å finne ut hvilke innovative prosesser som brukes i design og softwareutvikling. Her kan du lære om prinsipper bak Agile metoder og se på prosjekt med kundens øyne. Eller bli inspirert til å innføre noen deler av metodikken i din arbeidsprosess. Du finner de andre intervjuene her.
Intervju 2:
Johannes Brodwall er Chief Scientist i Exilesoft, Norgeskjent Java-guru og grunnlegger av Smidigkonferansen.
– Hva er Agile?
– Agile (på norsk: smidig) er definert ut fra Agile Manifesto som først ble formulert i 2001. Det handler om å observere og gjøre det som er riktig nå, framfor å følge de planene og løftene man ga for et halvt år, to år eller enda lengre siden. Agile i dag er best benyttet gjennom metoden Scrum.
– Hva er Scrum?
– På begynnelsen av en sprint (arbeidsperiode) samles teamet og produkteier med forretningsansvar og blir enige om hva man skal gjøre disse to ukene. I denne to-ukers perioden møtes man daglig og står gjerne rundt en felles tavle der man har alle oppgavene og koordinerer framdriften. På slutten av to-ukers sprint viser man fram det man har laget, gjerne til noen utenfor prosjektet. I tillegg har man et retrospektiv, der vi ser på arbeidsprosessen, og hvordan den kan forbedres.
– Hvordan priser man en software prosjekt?
– Når det er en fast pris som ligger til grunn for prosjektet, så er det prisen for noe. Og så langt har jeg ikke funnet et prosjekt der oppfattelsen av hva man trengte var lik mellom de som utviklet det, de som bestilte det og de som skulle bruke det. Det betyr at i utgangspunktet, når du har et fastprisprosjekt, så er det ingen som er helt sikker på hva man har blitt enig om. Og ingen som egentlig sikker på om det man har blitt enig om er nyttig. Så man starter ut i oppoverbakke. Det er vanskelig.
Jeg setter mest pris på det er å ha et prosjekt som er basert på en ressurspris i stedet for en fastpris. Det vil si at man betaler for tiden som går med. En forutsigbar måte å gjøre det på er at leverandøren tar betalt per iterasjon. På slutten av en iterasjon så vil jo da kunden se hva som har blitt produsert. Hvis kunden ikke er fornøyd med det som ikke blir produsert i løpet av en iterasjon, så bør man jo da vurdere om det skal medføre oppsigelse av kontrakten eller ikke. Jeg tror at essensielt så kommer man dit med mer kompliserte kontrakter, men med flere krumspring.
– Kan kunden smidig arbeidsmetodikk eller må vi utdanne kunden?
– I mange av disse prosjektene er faktisk kunden litt utdannet på det. Det jeg kan svare på er hva skal man gjøre i en sånn case.
Det som vi forutsetter her er at man har en innsats, en jobb som må gjøres som er så stor at ingen enkeltperson som kan ha oversikt over den. Og da blir det ikke bare “å være Agile og finne veien mens vi går”. Det som for eksempel statens pensjonskasse gjorde i sitt PERFORM prosjekt var å bruke en kontraktsmodell som heter PS2000 som er utviklet av den Norske Dataforeningen. Og de hadde to leverandører som leverte litt av funksjonaliteten hver. Og de leverte da i tre-måneders inkrementer. Slik at leverandørene fikk en kontrakt på de neste tre månedene.
Kunden og leverandøren forhandlet hva som så i den kontrakten og hvis man oppnådde så mye som man hadde forhandlet, så fikk man en bonus som leverandør, hvis man oppnådde mindre, så fikk man en straff som leverandør. Samtidig ble den ytelsen som man hadde i en tre-månedersperiode lagt til grunn for den neste tre-månedersperioden. Slik at man får en realistisk pris i det.
Man hadde de to leverandørene som hadde, la oss si, vennskapelig konkurranse mellom hverandre, så man visste i alle fall at leverandørene ble holdt til en standard.
Det er en modell som kanskje er det beste du kan klare å få til når du er i et prosjekt som investere så mye penger at du egentlig ikke kan ha kontroll på hva som skjer. Det høres ut som en veldig god modell. Men man må ha ganske mye kunnskap som kunde for å gjøre dette. I dette tilfellet hadde kunden mange heltidsansatte og konsulenter som jobbet med kontrakt og samarbeid. Og for å være ærlig, jeg tror det var en dørgende kjedelig jobb. Men jeg har ikke noe bedre alternativ.
– Hvor kan man lære om Agileprosesser og Scrum?
– Stedet å starte med Scrum er egentlig den offisielle Scrum-guiden. Den finnes på Scrum.org og er blant annet oversatt til norsk. Videre er det mange gode bøker. De mest populære nye Smidig bøkene er Kanban av David Anderson og Lean Startup av Eric Ries.
– Har du jobbet med desigere?
– Jeg har jobbet med noen veldig gode interaksjonsdesignere på spesielt et prosjekt jeg gjorde for Statnett. Vi hadde et team med tre designere som understøttet femten utviklere. Før utviklerne startet på en sprint, hadde designerne en workshop sammen med noen brukerrepresentanter og noen utviklingsrepresentanter. Der ble det utviklet skjermbildeskisser som utviklerne kunne ta med seg inn i neste sprint og bruke som grunnlag for jobben. Etter en sprint gjorde de brukertesting: Brukere løste oppgaver i systemet mens designerne og utviklerne passivt observerte. I rommet ved siden av så en utvikler på det hele via en videoskjerm. Utvikleren vil gjerne rope «den er der øverst i høyre hjørne! Bare klikk på knappen! Kom igjen!». For det som ser så åpenbart ut for utvikleren, når han sitter og utvikler, kan være helt usynlig for en bruker.
