Scrum som innovasjonsmotor

Mange tror at Scrum dreier seg om daglige, stående møter, klistre post-it lapper på veggen, produktkøer og sprinter. Man gjør de foreskrevne aktivitetene, og lar det bli med det. Noen velger å se det som en ren prosjektstyringsmodell. Det er forbausende hvor mange som har et slikt overforenklet syn på hva Scrum egentlig dreier seg om. Dette er et forsøk på å forklare kjernen i Scrum.

Bakgrunn – The New New Product Development Game

Når Dr. Jeff Sutherland i 1993 var på utkikk etter “best practice” innen programvareutvikling dumpet han borti artikkelen The New New product development game i Harvard Business Review fra 1986. Dette dreier seg ikke i særlig grad om programvare, men snarere om produktutvikling og innovasjon generelt. Artikkelen er mest kjent for å ta til orde for at “stafettløpet” der ulike spesialister jobber hver for seg og sender informasjon til hverandre må forkastes til fordel for tette team, omtrent som man gjør i en Scrum i Rugby. Her diskuterer to de Japanske forskerne Hirotaka Takeuchi og Ikujiro Nonaka (disse kalles nå “The Godfathers of Scrum”) hvordan datidens beste innovatører opererte.
Artikkelen baserer seg på studier i firmaer som Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, Hewlett-Packard og IBM. I artikkelen belyser de hvordan helt konkrete, banebrytende produkter kom til live gjennom at en tverrfaglig gruppe mennesker ble plassert sammen, fikk en veldig utfordrende målsetning, store fullmakter og budsjetter og ellers hva de måtte behøve tilrettelagt. Vi vet jo for eksempel at IBM PC ble unnfanget i en lagerbygning i Boca Raton, langt unna andre av IBMs fasiliteter av en tverrfaglig ingeniørgruppe med store fullmakter og liten ekstern styring.

Fellestrekkene de fant kategoriseres slik:
1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

1. Built-in instability

Det handler om å kaste seg ut på dypt vann. Toppledelsen tar strategiske beslutninger om en ny satsning og setter sammen et kompetent team som får store fullmakter og en tidsfrist. Men de stiller få eller ingen krav til løsning, kun krav til egenskaper som skal gi dem et betydelig konkurransefortrinn. Ingen vet på forhånd hva dette vil ende opp i.

2. Self-organizing project teams

Prosjektteamet blir hensatt i en tilstand som tilsvarer et oppstartsselskap; man ønsker å gjenskape gründerånden selv om man er en del av et veletablert, stort selskap. Da må gruppen få en stor grad av autonomitet, hvilket innebærer at de ser lite til moderselskapet mens det står på. Det er ingen tvil om at de har tillit – de blir ikke spurt om timerapportering, kun oppnåelse av delmål som gruppen selv setter seg. De legger en mer eller mindre detaljert plan som stadig revideres. Medlemmene av gruppen har stor bredde av spesialisering og vil typisk bestå av ulike ingeniører, salgsfolk, fagspesialister osv. Det studien er veldig klar på er at disse menneskene med svært ulik bakgrunn begynner å lære av hverandre.

3. Overlapping development phases

Når fasene går etter hverandre (stafettløpet) blir det vanskeligere å samarbeide og å utveksle tverrfaglig kunnskap. Og det blir bortimot umulig å integrere og validere delresultater underveis. Når de støter på hindringer og flaskehalser blir det tydelig at hele teamet må jobbe sammen for å løse opp i disse. Derfor er det maktpåliggende at man evner å blande de fasene som lar seg blande i et produktutviklingsløp.

4. “Multilearning”

Et slikt tverrfaglig team må også ha direkte kontakt med omverdenen eller “markedet” om man vil. Det er maktpåliggende å teste ut konsepter på markedet og det er like viktig å fange opp endringer. Teamet som helhet kan nå respondere raskt på ny lærdom og endrede markedsbetingelser. Alle i teamet blir nå bevisste på markedsmessige forhold og dette vil også prege den læringen som foregår. Det vil alltid være ulike nivåer av læring. Det fundamentale nivået dreier seg om å foredle den ekspertisen du allerede har. Andre nivåer kan omhandle samarbeidsformer, markedsforståelse, andre tilstøtende ingeniørfagfelt osv.

5. Subtle control

Ledelsen behøver selvsagt å kunne følge med på progresjonen, men dette må gjøres uten byråkrati og uten å hindre spontanitet og kreativitet. Enkelt sagt får ledelsen kontroll ved å skape gjennomsiktighet. I artikkelen tar forfatterne til orde for 7 prinsipper:
1. Sørge for at gruppedynamikken er ivaretatt og at teamet fungerer godt,
2. skape åpenhet og nærhet,
3. sørge for at ingeniørene får møte kunden og brukerne,
4. evaluere gruppen framfor individer,
5. ha fokus på rytmen teamet jobber i, i de ulike fasene,
6. tolerere og forvente feil – “ingen feil, ingen innovasjon”,
7. oppfordre leverandørene til å selvorganisere og å jobbe tett med teamet.

6. Organizational transfer of learning

Forfatterne nevner her flere eksempler på hvordan store selskaper forsøker å institusjonalisere sine suksesshistorier ved å lage prosedyrer og standardisere metoder. Dette punktet må vel kunne sies å være det svakeste – historien viser at det er uhyre vanskelig å finne gode modeller for slik kunnskapsoverføring på tvers.

Hvordan lykkes med innovasjon?

De beste er fullstendig klar over at innovasjon er en kompleks og ikke-forutsigbar aktivitet, så detaljert planlegging og styring er fåfengt. Det er nødvendig å ha et bevisst forhold til kompleksitet. Enkle oppgaver kan planlegges og styres, komplekse oppgaver krever tverrfaglig teamarbeid og stor frihetsgrad. Sutherland og Schwaber har brukt HBR artikkelen A Leader’s Framework for Decision Making av David J. Snowden and Mary E. Boone som pedagogisk grunnlag for Scrum og bruk av selv-organiserte team i IT-prosjekter. Konseptet selvstyrte team ingen fiks ide man kan velge bort. Dette er core Scrum.

En annen helt sentral faktor er å sette kunden i førersetet. De beste innovatørene gir seg ikke før de er trygge på at de forstår behovet til brukerne – enten disse er eksisterende eller framtidige kunder. Og så må vi la ingeniørene møte brukerne. Ofte. Gjør som Steven Denning beskriver i boka The Leader´s guide to Radical Management: The only goal should be to delight the customer.

Scrum er et enkelt og fleksibelt rammeverk, og følg gjerne “mekanikken” i Scrum til punkt og prikke. Men det er ikke det som til syvende og sist vil avgjøre om du lykkes. Det Jeff Sutherland gjorde – senere med hjelp av Ken Schwaber – var å utarbeide et rammeverk for å skape innovasjon på en effektiv og repeterbar måte. Ideene fra The New New Product Development Game lever videre i Scrum og artikkelen bør leses av alle som virkelig ønsker å lykkes med Scrum.

Posted on February 26, 2012 at 5:58 pm by gamsjo · Permalink
In: forretningssiden, kompleksitet, Scrum · Tagged with: , , ,

3 Responses

Subscribe to comments via RSS

  1. Written by Eirik M
    on 27/02/2012 at 11:16 am
    Reply · Permalink

    Hei Geir!

    Flott at du skriver om en av mine favorittartikler 🙂

    Men les den gjerne igjen og se hvor mye scrum (liten ‘s’!) nevnes. Det de snakker om er rugby, og “rugby approach”.

    I et land som Norge hvor rugby er en ukjent sport er nok ikke dette det viktigste, men det skader vel ikke å være litt mer korrekt. Scrum er ikke noe mer enn å starte spillet etter stopp; litt som når to spillere står rygg-mot-rygg og dommeren kaster ballen mellom dem i andre ballspill. Det som beskrives i artikkelen er resten av spillet, altså det som skjer når scrum’en er over. (ref. The Sport of Rugby)

    Begrepet Scrum i utvikling kommer rett nok fra scrum i rugby, men om man skal sammeligne idéene i Scrum med rugby bilr det for snevert å kun se på det som skjer i scrum’en. Det er selvet spillet som er interessant.

    Hvordan utviklingsrammeverket endte opp med navnet Scrum tror jeg er litt tilfeldig. Spekulasjoner fra min side sier at det egner seg bedre i markedsføring.

    Hilsen fra en utviklier og rugbyspiller.

    • Written by gamsjo
      on 27/02/2012 at 12:03 pm
      Reply · Permalink

      Takk for kommentar Eirik,
      jeg tror jeg har ordene mine i behold – det er et kapittel kalt MOVING THE SCRUM DOWNFIELD…

      Jeg synes bildet av en scrum der alle på samme lag forener kreftene mot et felles mål er et ganske godt bilde på et Scrum-team. Men dynamikken mangler selvsagt:)

      Men du har et godt poeng – personlig har jeg aldri overvært en eneste rugby-kamp..

  2. Written by Eirik M
    on 27/02/2012 at 1:23 pm
    Reply · Permalink

    Scrum er en del av spillet som er velregulert og ordnet. (Pussig nok er det my juks der også.) Resten av spillet er kaotisk, i hvert fall for dem som ikke kjenner spillet så godt. Det er den delen, altså hvordan laget respondere til forandring i situasjonen, som ikke blir like godt forstått om man ikke kjenner til rugby.

    Man kan selvsagt lese denne artikkelen og få utbytte uten å kjenne til rugby. Samme for gjennomføring av Scrum. Men kjennskap til rugby vil tilføre noe til forståelsen som jeg tror forsvinner om man ikke har kjennskap.

    Du kan jo prøve selv. Du hadde sikkert noen tanker i hodet da du leste denne setningen: “Instead, a holistic or ‘rugby’ approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today’s competitive requirements.” Prøv å få sett en rugbykamp og se om du fortsatt tenker det samme. Hvordan beveger laget seg som en enhet? (Hint: Man kaster ikke ball til hverandre i en scrum.)

    Eller sagt på en annen måte: Det man ikke kjenner til blir ofte oversett. Ville egentlig bare påpeke at denne delen finnes. Scrum består forøvrig av 8 spillere fra hvert lag; et lag består av 15 spillere. Om du har sett et nærbilde av en scrum har du mest sannsannsynlig sett 8 + 1 fra hvert lag, og 6 spillere har vært utenfor bildet. Disse spillerene har også en rolle i spillet.

Subscribe to comments via RSS

Leave a Reply