Rutinepreget evaluering
Å evaluere seg selv er selvsagt viktig også i andre prosesser enn Scrum. Det å stadig forbedre seg, for å kunne jobbe mer effektivt, levere bedre kvalitet og trives bedre som team, er en nøkkelfaktor for suksess i de fleste prosjekter. Dessverre kan retrospektivmøter etterhvert bli rutinepregede; En aktivitet man gjør iterasjon etter iterasjon, uten egentlig å få fram de tingene som betyr noe, eller tenke nytt om temaer som går igjen gang etter gang. Da kan det ofte hjelpe å bryte opp mønstrene og gjøre noe nytt, for å skape variasjon og nytt engasjement rundt retrospektivet.

Her er et referat fra et retrospektiv jeg nylig hadde sammen med teamet jeg er Scrum Master på. Kanskje kan disse øvelsene inspirere deg til å skape ny glød neste gang du skal delta på et retrospektiv.

Første øvelse: Tidslinja
Først tegnet vi opp ei tidslinje som illustrerte de tre ukene som iterasjonen hadde vart. Det var ei rett linje med helgene og andre fridager markert. På denne linja tegnet vi inn viktige hendelser. For eksempel måtte vi i slutten av første uke endre løsningsbeskrivelsen på flere av oppgavene på iterasjonskøen, fordi de var basert på en forutsetning som viste seg å være feil. I uke to måtte vi gjøre noen uplanlagte feilrettinger på en tidligere leveranse, og i uke tre fikk vi et nytt medlem på teamet.

Dette er noen eksempler på ting som kan tegnes inn på tidslinja. Det er ingen regler for hva som er riktig eller feil å tegne inn. Stort og smått kan tas med. Poenget med denne øvelsen er rett og slett å friske opp hukommelsen til teamet. Vi hjelper hverandre med å huske hva vi skal evaluere.

Andre øvelse: Happygraf
Under tidslinja fikk så hvert teammedlem anledning til å tegne sin Happygraf. En Happygraf er en kurve som viser hvor fornøyd/glad eller misfornøyd vedkommende har vært i løpet av iterasjonen. Jo høyere kurve, jo mer fornøyd er du. Skalaen bestemmer dere selv. Dette er en morsom måte å uttrykke hvordan du har hatt det de siste tre ukene. Og det gir en fin innfallsvinkel til å kommunisere om følelser, uten å bruke ord.

Tredje øvelse: Stikkordslotto
I den siste øvelsen fikk hvert teammedlem utdelt grønne og røde lapper. På de grønne lappene skrev vi ting som hadde fungert godt i iterasjonen, ting vi ville fortsette med å gjøre. På de røde lappene skrev vi forbedringspunkter, ønsker om endring. Her brukte vi stikkordsform, slik at vi bare skrev et ord eller et uttrykk på hver lapp. Setninger var forbudt.

Deretter samlet vi inn alle lappene og blandet dem sammen. De grønne lappene i en haug, og de røde i en annen. Så trakk vi etter tur en og en lapp fra en bunke, og leste stikkordet på den høyt. (Fikk vi en av våre egne lapper la vi den tilbake og trakk en ny.) Den som trakk en lapp måtte prøve å tolke hva stikkordet betydde. Da kunne hun gjerne bruke sine egne erfaringer fra iterasjonen til å forklare hva vedkommende hadde ment, og hva hun selv ville legge i ordet.

Etter at hun hadde sagt hva hun tenkte stikkordet betydde, skulle den som hadde skrevet lappen forklare hva han egentlig hadde ment. På denne måten fikk vi minst to forskjellige vinklinger på samme tema, og svært ofte gode diskusjoner som følge av det. En av oss hadde samtidig rolle som sekretær, og førte et referat av hva som ble sagt.

Tiltak og ambisjoner
Sammen fikk disse tre øvelsene fram flere lærdommer fra de siste ukene. Vi diskuterte flere vinklinger enn vi tidligere har gjort på samme tema, og gravde dypere i noen enkeltsaker. Til sammen brukte vi ca to timer på øvelsene. Vi kombinerte det med lunch, og hadde kjøpt inn mat.

I begynnelsen av den påfølgende iterasjonen tok vi en gjennomgang av referatet fra retrospektivet. Vi valgte ut de tre viktigste punktene hvor vi ønsket å sette oss konkrete mål for forbedring. Vi ble enige om tiltak og ambisjoner for hvilke resultater vi ønsket å oppnå. Denne gjennomgangen brukte vi ca en time på.

Dine erfaringer
Hvilke erfaringer har du med retrospektiver? Har du opplevd noe som har fungert spesielt godt, eller har du tips til øvelser som er morsomme og gir gode resultater?

Jeg har vært så heldig å være på et prosjekt med en produkteier som har sørget for at vår innsats har blitt brukt til å effektivt skape verdi for brukerne av systemet. Jeg vil trekke fram mine observasjoner om hvordan produkteieren på dette prosjektet brukte produktkøen, hvordan han skapte dialog med brukerne og hvordan han kommuniserte effektivt med utviklerne.

Produktkøen

Produktkøen er produkteiers fremste verktøy for å styre prosjektet dit han ønsker. Det viktigste med produktkøen er derfor at den er representert i et verktøy produkteieren er komfortabel med å bruke. Vår produkteier brukte Excel, noe som fungerte godt for dette prosjektet. Hver brukerhistorie var en rad i et regneark. Når vi skulle endre prioritet, kunne vi dra og slippe en brukerhistorie til riktig sted. (Dette er et lurt knep å lære i Excel).

Etter hver iterasjon gikk jeg som Scrum master og produkteieren gjennom alt som var levert i iterasjonen. Vi markerte i produktkøen hva som var levert og hva som ikke var levert. I iterasjon 4, 5 og 6 skjedde noe merkelig. Iterasjon 4 hadde vi planlagt 7 brukerhistorie-poeng, men leverte 4. I iterasjon 5 hadde vi planlagt 7 og leverte 7. I iterasjon 6 hadde vi planlagt 7 og leverte 10. Det som skjedde var et en stor brukerhistorie var nesten ferdig på slutten av iterasjon 4. En ny stor brukerhistorie var nesten ferdig på slutten av iterasjon 5, og denne brukerhistorien fikk vi endelig levert i iterasjon 6. Produkteier insisterte på at en brukerhistorie var enten ikke ferdig (0%) eller helt ferdig (100%). Dette gjorde at det aldri var noen skjønnsvurdering om hva vi hadde levert.

I prosjektet vårt skulle vi erstatte et eksisterende system. Produkteieren var veldig bevisst på å prioritere et sammenhengende sett med brukerhistorier som gjorde at brukerne kunne benytte de leveransene vi ble ferdig med i løpet av prosjektet. Det var to viktige vurderinger som produkteier tok: For det første må brukerne kunne utføre en arbeidsoppgave i den nye systemet, og ikke måtte hoppe mellom det nye og det gamle. For det andre må leveransene inneholde funksjonalitet som er interessant for brukerne.

Personer og samspill

Men produktkøen er den minst viktige delen av produkteiers jobb. Det smidige manifestet sier det selv: “Vi verdsetter personer og samspill over prosesser og verktøy.” Det er to viktige grupper som produkteieren må forholde seg til: Brukerne og utviklerne.

Involvere brukere

Før prosjektet startet, hadde produkteieren involvert brukerne i prosjektet. Mange brukere var blitt spurt om hva de mente var viktig med det nye systemet og noen brukere var valgt ut til en fokusgruppe. De to mest involverte brukerne deltok hele veien i prosjektet. Produkteieren identifiserte to brukere som de andre brukerne respekterte faglig, som forsto dagens system godt, som hadde meninger om hvordan ting burde være, og som ikke var redd for å si disse meningene.

Så snart vi hadde et produkt som kunne vises fram, satt vi dette i drift i demoversjon som brukerne kunne teste ut. Det viste seg å være vanskelig å få brukerne til å prioritere å teste det nye systemet. Det hjalp litt når produkteieren ga dem en oppgave de skulle utføre med det nye systemet (hjemmelekse). Det hjalp veldig når brukerne kunne bruke det nye systemet mot produksjonsdata som en del av jobbe sin.

Ekspertbrukerne deltok på alle demoer. Ettersom en av de bodde i Rogaland og en i Hedmark, var det vanskelig for dem å reise til Oslo for hver eneste to-ukers iterasjon. De første iterasjonene var de alltid til stede, men etter dette kjørte vi kun demo annen hver iterasjon. Etter et halvt år i prosjektet forsøkte vi også å kjøre noen demoer med screen sharing (go-to-meeting, tror jeg) og telefonkonferanse. Det fungerte ok, men vi fikk mye nyttigere feedback når vi møttes ansikt til ansikt. Ekspertbrukerne hjalp oss å bli flinkere og validerte arbeidet vårt når et var bra.

Kommuniserer med programmere

For å ha framdrift, var prosjektet avhengig av at produkteier og utviklere møtes hver dag. Produkteier deltok på standup-møtene hver morgen. Etter standup-møtene hadde han satt av opp til en time der en utvikler kan vise fram ny funksjonalitet og få tilbakemeldinger, der produkteier kan gi tilbakemeldinger til en utvikler på funksjonalitet han testet i går og der produkteier kan forklare detaljene rundt nye brukerhistorier.

Når produkteieren forklarte brukerhistorier, var han flink til å være konkret. Dette er alfa og omega når en produkteier snakker med utviklere. Forskjellen på å vise fram en skjermbildeskisse og å forsøke å beskrive et abstrakt behov er gigantisk. Forskjellen på å fortelle et eksempel og å forklare en abstrakt arbeidsprosess er enorm. Ved å bruke eksempler til å forklare brukerhistorier var produkteiers forklaringer gode for utviklerne.

Til slutt var produkteieren vår rask til å bestemme seg. Dersom det var et uklart valg, fikk vi ofte en avgjørelse der og da. Når produkteier måtte sjekke med andre, tok det en eller to dager før han kunne gi oss en beslutning. Noen ganger fant han senere ut at han måtte ombestemme seg. Da utførte vi ganske enkelt den endelig løsningen i en senere iterasjon. Det er mye mer effektivt å utvikle noe som er en rimelig hypotese, få tilbakemelding og så utvikle det riktige, enn det er å vente på en beslutning.

For å lykkes som produkteier, må du kunne bruke produktkøen effektivt, du må involvere brukerne dine gjennom hele prosjektet og du må kommunisere med utviklerne hver dag. Da vil du ha et vellykket Scrum-prosjekt!

Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Lean kommer fra en asiatisk kultur, der det kollektive og prosessen i seg selv er det sentrale. Lean er laget for å strømlinjeforme en spesiell måte å løse en kjent oppgave på. Agile på sin side kommer fra USA, der individet fremheves over alt annet (“Individuals and interactions over processes and tools”). Agile er først og fremst en effektiv måte å jobbe på når vi ikke kjenner veldig godt til omfanget og innholdet i oppgaven, og er nødt til å finne veien samtidig som vi går den.

I et foredrag på Scandinavian Agile Conference 2009 presenterte Jim Coplien disse 9 punktene der Lean og Agile er motstykker:

En gjennomgang av disse punktene kan være tema for et senere innlegg. Det jeg vil presentere denne gangen, er to praktiske øvelser som illustrerer noen av forskjellene og styrkene ved Lean og Agile. Øvelsene tar ca 5 minutter hver.

Øvelse 1: Agile

Finn en gruppe på ca 10-15 personer, og la de stå i et åpent område som de kan bevege seg rundt i. Hver person skal tenke på to andre personer i gruppa. Når alle har valgt ut sine to personer (uten å avsløre til noen hvem de har valgt), så er oppgaven som følger: Hver og en person skal nå plassere seg slik i rommet at han eller hun har nøyaktig like stor avstand til de to personene vedkommende tenkte på.

Før de får begynne å løse oppgaven, så er dette et morsomt spørsmål å stille til eventuelle prosjektledere i rommet: Hvis man skulle benytte klassisk prosjektledelse til å lede gruppa i denne øvelsen, hvordan skulle man gå frem da? Hvilke planer og retningslinjer kunne man lage som ville hjelpe dem fram til et raskt og godt resultat? De fleste vil snart komme fram til den konklusjonen at det er en ganske vanskelig (kompleks) oppgave.

Om vi benytter Scrum som eksempel på en smidig måte å løse dette på, hva ville en god Scrum master eller coach da si? Bare gjør det! Vi lar gruppa være selvorganiserende, og lar hvert enkelt individ ta ansvar for å på en selvstendig måte løse sin del av oppgaven, men i tett samarbeid med de andre i gruppa. Resultatet vil bli at etter en kort tid med tilsynelatende kaotiske og uorganiserte bevegelser, vil alle ha funnet likevektspunktene sine som til sammen løser oppgaven. Et resultat som ville være svært mye mer krevende å oppnå med en sentralt styrt prosess.

Øvelse 2: Lean

Hva så med Lean, hvordan kan det illustreres ved hjelp av en øvelse? Her trenger vi litt færre personer, ca 10 er fint. Gi en tilfeldig person i gruppa en gjenstand han kan holde i handa (ei tom flaske er et godt alternativ), og presenter dem for følgende utfordring: Gjenstanden skal nå sendes fra person til person i alfabetisk rekkefølge basert på fornavn. Det skal skje så raskt som mulig, og de vil bli tatt tiden på!

Ved første forsøk vil gruppa bruke litt tid på dette. De må fortelle navnene sine for å finne riktig rekkefølge. De vil typisk bruke et halvt til to minutter på å bestemme rekkefølgen og sende gjenstanden rundt. Fortell dem resultatet, og spør så om de kan gjøre det igjen, raskere. Det vil de naturlig nok klare, etter som de nå bedre kjenner navnene til hverandre.

Etter å ha fortalt dem tiden for forsøk nummer to, la dem forsøke en gang til, og be dem tenke på måten de står plassert på. De vil oppdage at det å stå på rekke eller i en sirkel, i alfabetisk rekkefølge, vil gjøre det enklest mulig å sende gjenstanden fra person til person. Vi eliminerer waste!

Hvor raskt er det mulig å klare det? Om de står i en tett sirkel, og hver enkelt så vidt berører gjenstanden før nestemann gjør det, kan de klare øvelsen på under et sekund. Det vil være en ganske dramatisk forbedring fra det første forsøket! Det viser hvor effektiv Lean kan være på denne typen oppgaver.

Oppsummering

Lean og Agile er laget for å løse forskjellige typer oppgaver. De kommer fra forskjellig bakgrunn, og selv om de virker like, så skiller de seg vidt fra hverandre på noen sentrale områder. Øvelsene over demonstrerer noen av de spesielle styrkene til de to prosessene. Disse styrkene er det viktig å huske på når man skal velge tilnærming til et prosjekt eller andre arbeidsoppgaver som krever en god prosess.

Hvilke erfaringer har du som leser gjort deg med Lean og Agile? Har du opplevd oppgaver eller prosjekter der de har passet spesielt godt eller spesielt dårlig?

Dette tema var belyst på årets itSMF-konferanse som ble avholdt på Gardermoen 3-4 mars. ”Dei leikar ikkje saman – enno!” het presentasjonen til Bjørnar Tessem fra Universitetet i Bergen. Denne presentasjonen setter fokus på at det er samhandlingen mellom utvikling og drift som er mangelfull. Man er usikker på å la andre ”komme inn på sitt domene”, både fra utvikler- og driftsmiljøene. Hva skyldes denne usikkerheten? Er det frykt for å miste makt og innflytelse? Eller får man skylapper av sine egne ”good practice frameworks” enten de heter ITIL, CoBIT, Scrum, smidig eller noe annet? Dersom man får en for streng tolking av sitt eget rammeverk, så mister man den pragmatiske tilnærmingen.

Det er ingen tvil om at slike rammeverk bidrar til forbedring innen for sine respektive områder, men de kan også bidra til å stenge ute andre fornuftige innspill. Resultatet kan bli en religionskrig, der kundene og brukerne er de som må lide for den mangelfulle samhandlingen.

Utvikling og drift må i større grad ha følelsen av et felles ansvar for at tjenestene de utvikler og drifter vil tjene det formål de er tiltenkt på en måte som er effektivt for både brukerne og leverandørene.

Ken argumenterer for at det er Jeff Sutherland og ham selv som har definisjonsretten på hva Scrum er. Folk som bruker versjonen som lå hos Scrum Alliance, jobber derfor ut fra materiale som ikke er riktig, i følge Ken. Jeg tror ikke at Ken og Jeff med rette kan hevde at det er dem som har definisjonsretten og alle andre må bare godta det. Scrum er sjenket til verden, og verden hører på de stemmene de vil høre på.

Samtidig ser jeg behov for å definere hva som er Scrum, slik at ikke alt mulig rart kan kalles “Scrum” (men akkurat dét ser ut til å være en håpløs kamp…) Scrum Alliance ser ut til å ville høre på Ken og Jeff, for de har fjernet sin gamle versjon. Et positivt poeng å ta med seg er uansett at Ken mener Scrum ikke er statisk, men må utvikle seg.

Den oppdaterte Scrum Guiden på www.scrum.org inneholder noen overraskelser. Den største, for meg, er at Ken og Jeff har fjernet alt snakk om “visjon”. Tidligere var visjonen omtalt som grunnlaget for Produktkøen, men nå er det ikke mer visjon igjen. Jeg er kritisk til om dette er et steg i riktig retning. Det største videreutviklingspotensialet for smidig systemutvikling ligger i å gi mer støtte og verktøy til Produkteier i å finne og definere verdi – typisk visjon og annet arbeid som skjer i forkant av utviklingen. Jeff og Ken går motsatt vei og viser med det at de ønsker at Scrum skal fortsette å være en utviklersentrert metodikk. Synd for både dem og Scrum.

Jeg liker godt innledningen, hvor Jeff og Ken sier at Scrum har tre bein. I tillegg til (faktisk foran) de velkjente inspeksjon og tilpasning kommer nå synlighet (“transparency”).

Seremonier har endret navn til tidsbokser og det er nå seks av dem: Release Planning Meeting, Sprint Planning Meeting, Sprint, Daily Scrum,  Sprint Review og Sprint Retrospective. Jeg liker godt at Release Planning Meeting har kommet inn. Noen savner kanskje demoen? Den ligger inne i Sprint Review, men det er lagt vekk på at demoen bare er en del av Sprint Review – mesteparten av møtet går til diskusjon om det som er laget og veien videre.

Scrum Guiden er obligatorisk lesning for alle som er opptatt av smidig systemutvikling. Og så kan vi debattere videre hva som er “riktig” Scrum…

Denne postingen er oppdatert etter at flere personer med rette hevdet at jeg ikke hadde et helt klart bilde av hva den gamle scrum guiden inneholdt (takk!). Inni dette er det sikkert en lekse angående det å stole for mye på hukommelsen.

De aller fleste artikler, temanummer osv. om smidige metodikker har så langt framstilt smidige metodikker på en svært rosenrød måte. Smidig systemutvikling er uten tvil et stort skritt framover i forhold til tradisjonell systemutviklingsmetodikk. Imidlertid er smidig utvikling i sin nåværende form ikke endestasjonen. Vi kan – og må – bli enda bedre.

Det finnes reelle utfordringer ved bruk av smidige metodikker, og det må vi også tørre å diskutere. Dét er viktig for at smidig utvikling skal bli en suksess, leve opp til sitt potensiale og ikke bare bli nok en hype på historiens gravplass. Her vil jeg nevne tre av de utfordringene jeg er opptatt av om dagen.

Levere verdi

Den første utfordringen gjelder å levere verdi. Smidige metodikk har som prinsipp å levere verdi tidlig og hyppig, og det mest verdifulle først. Dette gir bedre cashflow og ROI, og er et flott prinsipp.

I praksis leverer imidlertid smidige prosjekter funksjonalitet, ikke verdi. Stort sett aner vi ikke hvor mye verdi funksjonaliteten har for organisasjonen, eller om det kanskje ville vært mer lønnsomt å ikke utvikle en gitt funksjonalitet. Vi bare overlater til Produkteieren (kunden) å prioritere funksjonaliteten, og så håper vi at det fører til at vi leverer høyest verdi først og at ROI blir så høy som mulig. Kanskje det stemmer, kanskje ikke – det vet vi ikke, vi bare tror.

Vi trenger altså bedre måter å måle verdi på.

Styre mot mål

Den andre utfordringen er at smidige prosjekter fortsatt i for stor grad styrer mot kundens krav, ikke mot kundens mål. Den etter hvert velkjente Produktkøen (Product Backlog) fra Scrum er et eksempel på dette. Vi beskriver krav som brukerhistorier, legger dem inn i Produktkøen, og deretter følger vi framdrift i forhold til ferdigstillelse av kravene. Vi er åpne for å endre på kravene og omprioritere, mye mer enn på tradisjonelle prosjekter, og det bidrar absolutt til bedre resultater for prosjektet.

Imidlertid er det måloppnåelse som er viktig, ikke kravoppnåelse. Kravene er bare et sett med hypoteser for hvordan man kan nå målene. Vi trenger altså mer fokus på å definere mål og styre mot måloppnåelse. Det bør nevnes at EVO, utviklet av Norges egen Tom Gilb, er et velprøvd alternativ med fokus på måloppnåelse.

Mer støtte til Produkteieren

Den tredje utfordringen er at mye av det som er mest krevende, særlig i Scrum-prosjekter blir dyttet over på Produkteieren, dvs kunden. Og dette er samtidig ting som i stor grad avgjør om et prosjekt blir en suksess eller ikke, så som god forankring i organisasjonen, god balanse mellom ulike interessehavere, riktig prioritering av hva som blir med og hva som ikke blir med, osv. Allikevel sier vi ikke så mye om hvordan Produkteieren skal klare disse tingene. Produkteieren er ofte meget kompetent på sitt fagområde – men det fagområdet er vanligvis ikke prosjektstyring.

Så mens utviklingsteamet jobber lykkelig i vei, beskyttet fra forstyrrelser fra omverdenen, må Produkteieren prioritere ønsker, forankre beslutninger, forhandle enighet, drive internpolitikk – samtidig som hun skal bistå utviklingsteamet med alle ønskelige avklaringer.

Vi har gjort store framskritt på arbeidsmåten til utviklingsteamet, der jobber vi på en mye mer solid måte enn før. Nå må vi løfte blikket fra design-, utviklings- og testjobben. Vi må fokusere mer på Produkteieren og organisasjonen rundt, og gi reell støtte til Produkteierens viktige rolle.

Ta erfaring på alvor

Vi trenger altså bedre måter å måle verdi på, mer fokus på mål og måloppnåelse, og bedre støtte til Produkteieren og organisasjonen rundt. Men dette er kun tre utfordringer som jeg synes er viktige, andre vil være mer opptatt av andre utfordringer – ut fra deres situasjon og erfaring. Hovedpoenget er at vi nå begynner å diskutere disse reelle utfordringene som folk møter i praksis.

Så langt har dyktige folks konkrete utfordringer ofte blitt besvart med varianter over temaet “Men dere gjør det ikke riktig”. Slike svar hjelper ikke. Og skal smidig systemutvikling bli en suksess, må det være hjelp å få også når man sliter. Og like viktig: Hvis vi avfeier de utfordringene folk opplever, hindrer vi oss selv i å utvikle og forbedre den smidige metodikken, fordi vi ikke tar tilbakemeldingene fra praktisk bruk på alvor.

Som en av entusiastene som har jobbet for å spre smidig utvikling i en årrekke, gleder jeg meg over at smidig systemutvikling etter hvert har blitt godkjent og omfavnet i Norge. Markedsføringen har virket, nå må vi slutte å evangelisere og heller ta fatt på utfordringene.

Smidig systemutvikling i sin nåværende form er et stort steg videre, men ikke endestasjonen. Vi må fortsette å forbedre oss, basert på tilbakemeldinger.

Dét er den smidige kjernen i all sin enkelhet.

Dette innlegget er hovedsaklig basert på en artikkel jeg hadde i Computerworld i april 2009.

For noen uker siden hadde jeg en interessant erfaring på prosjektet mitt. Jeg og produkteieren fra kunden satt oss ned og så hva vi hadde produsert de siste to ukene – fire “brukerhistorier” som beskrev hva applikasjonen skal gjøre. Hver hadde en estimert relativ kostnad. Meg: “Ett poeng, tre poeng, to poeng, ett poeng, det blir syv poeng totalt.” Kunden: “Ok. Og denne iterasjonen kostet 140.000 kroner. Det blir 20.000 per poeng, ikke sant.” Jeg: “Høres riktig ut. Så denne oppgaven (peker på en brukerhistorie) kostet seksti tusen. Oi, det var dyrt.” Kunden: “Oi. Ja, det var dyrt.” Stillhet. Litt ukomfortabel latter.

Dersom du blir helt ferdig med ting under veis i prosjektet og du holder greie på hva du gjør, blir plutselig prisen på arbeidet veldig tydelig. Både for kunde og leverandør kan dette være et skummelt øyeblikk, for utviklingsprosjekter er alltid dyrere i praksis enn det føles ut som de burde være i teorien.

En ærlig leverandør vil ikke love å levere billigere enn man har vist å levere så langt. En ærlig kunde vil vite at det blir dyrt uansett leverandør og at informasjonen om kostnaden har en verdi i seg selv.

Men både den som skal svare til sin kunde og den som skal svare til sin styringsgruppe kan få hjertet litt i halsen første gang man faktisk får erfaringstall på hva prosjektet koster. Man føler seg litt naken. Men det er befriende også. For da kan man ha en dialog som er basert på fakta i og ikke bare følelser.