Lapper
>

Hvorfor skulle vi jobbe smidig igjen? Noen refleksjoner fra Smidig-konferansen

Anita Jenbergsen 
7. nov. 2012

Tanken om å jobbe smidig og bruke scrum som metode kom «snikende» inn i et prosjekt jeg deltok i for 6 år siden. Jeg ble fortalt at ved å jobbe smidig vil vi skape større gevinster.

Gevinsten ville komme i form av at:

1)      Kunden vil få en bedre løsning enn forventet

2)      Kunden vil få løsningen raskere levert

3)      Kunden vil kunne bruke mindre penger på prosjektutviklingen.

Smidig er en metode som vi har kjent, brukt og diskutert i noen år. Vi har fått mulighet til å gjøre oss noen erfaringer med hvordan det er å jobbe i smidige prosjekter. Det viser seg det fortsatt er en del utfordringer knyttet til det å jobbe smidig, skal vi tro etter lyntalene på årets smidigkonferanse, Smidig2012.

2012-11-05-10.38.14

Her er noen av temaene som var oppe til diskusjon/presentert i lyntaler:

  • Hvordan skal vi få tid til å designe i sprintene?
  • Hvordan få designere, strategikere ogutviklere til å ha det samme bildet av hva som skal lages?
  • Hvordan skal vi få tid til å teste?
  • Hva er en ferdig leveranse?
  • Hvordan bruke mindre tid på planlegging?
  • Hvorfor bruke så mye tid på å spørre brukeren?
  • Hvorfor bruke story points, eller hvordan bruke dem?
  • Hvorfor bruke så innmari mye tid på å estimere når man bare kan begynne å jobbe?

Konferansen har i tillegg til lyntaler, Open Space. En arena som drives av deltagerne og hvor den som ønsker det løfter et emne opp til diskusjon. Det ble mange, gode og lange diskusjoner. Likevel er temaene rundt smidig og scrum metodikken ganske lik med hva vi har snakket en del om i de siste  6 årene. Hvorfor har vi ikke kommet lenger?

Når smidig og scrum kom, utfordret metoden/prosessen oss i måten vi var vandt med å jobbe på. Metoden kom ikke bare med en verktøykasse med et sett av teknikker, som stand-up, scrumboard, planningmeetings og retrosective for å nevne noen, men den omveltet oss i hvordan vi skal jobbe sammen som team, krav til oppdeling av kravspesifikasjonen eller rettere sagt inn med user storyes, krav til raskere leveringer, og ikke minst krav til involvering fra kunden i form av å være fysisk tilstede under prosjektutviklingen.

Min erfaring er at hvert prosjekt etterstreber å jobbe positivt og effektivt sammen, og vi bruker retrospective til å bli bedre. Jeg er stort sett på utviklingsprosjekter av en ny nettside eller et fagsystem, og «alle» sier at design må ligge en sprint foran for å gi mat til utviklerne og holde maskineriet i gang. Vi vet at designere og utviklere må jobbe sammen for å få optimale resultater, og vi vet at ingenting er ferdig før det er testet.

Teorien predikerer om at stabile team skaper god dynamikk og raskere resultater. Men hverdagen, som konsulent, er at det hele tiden er nye kunder, prosjekter og team. Alle nye prosjektkollegaer kjenner smidig og har jobbet med scrum før, men min erfaring er at når teorien omgjøres til praksis gjør vi rett og slett ting forskjellig. Forventning om hvordan vi skal jobbe sammen, ha overleveringer, ha planmøter, ha stand-ups  og hva som er en user story er forskjellig fra prosjekt til prosjekt. Dermed tar det gjerne et par - tre sprinter, kanskje flere også, før teamet er oppe og kjøre på et effektivt nivå.

Er det derfor vi fortsatt snakker om hvordan vi skal bli bedre til å jobbe sammen?

Jeg savner mer dialog og deling rundt et spesielt tema

Jeg savner mer fokus og diskusjon rundt et tema og det er våre erfaringer knyttet til selve gevinstrealiseringen. Dette var heller ikke det store fokusområdet på årets konferanse (men med forbehold av at jeg desverre gikk glipp av en del lyntaler på tirsdag), og med unntak av et par lyntaler på mandag og speakers note på tirsdag av Lukas Fittl, "Validating a Lean Startup through Innovation Accounting". Hva er våre erfaringer knyttet til selve gevinstrealiseringen?

1)      Effekten av prosjektet. Når produktet er ferdig, hva har vi oppnådd da?

Har vi oppnådd ønsket effekt og hvordan har denne effekten igjen påvirket forretningen? Effekter kan måles. Når skal vi begynne med det?

2)      Resultatet. Sluttproduktet.

I vår iver etter å levere hver eneste prioriterte userstory så er fokuset på hva som er forventet resultat av denne storyen. Men når skal vi løfte øynene opp og se hvordan resultatet av denne sprinten er et skritt videre mot målet vi skal levere. Har vi i denne sprinten klart å komme nærmere målet? Har vi tatt tak i nye muligheter vi ikke tidligere har sett? Har krav falt fra for nye løsninger /behov som har kommet til?

3)      Iterativ utvikling for raskere og målrettet levering

Vanligvis skjer forløpet på denne måten; jeg designer en user story, den sendes til utvikler etter godkjenning av kunde, implementeres og ferdig. Men hva skal til for å gå tilbake og korrigere leveransen? Er det fordi kunden ikke er fornøyd med resultatet? Og hvem er da skyld i det? Hvem skal betale om det ikke er som forventet? Jeg savner mer fokus på hvordan vi skal jobbe frem «MonaLisa bildet», ha mulighet til iterativ utvikling.  Se tidligere blogg-innlegg som viser bildet jeg snakker om https://utbrudd.bouvet.no/2011/02/17/iterativ-utvikling-er-en-utfordring-i-scrum/

Hvilke erfaringer har du? Jeg er lutter øre og har veldig lyst til å få i gang en dialog på hvordan vi kan begynne å synliggjøre gevinstrealiseringen og effekten av våre prosjekter og leveranser?  

Temaer