5 smidige prinsipper for å bli best

Spørsmål: Hva skiller de beste fra de middelmådige?

Smidig produktutvikling er ikke basert på en veldefinert prosess som vi følger slavisk.  Nei, smidig er tvert imot basert på tilpasningsdyktighet og kontinuerlig forbedring. Den prosessen vi følger i dag er ikke nødvendigvis den beste i morgen. Hovedtanken er kontinuerlig å samle erfaring, lytte til markedet og å gjøre små endringer i måten vi løser problemer på. I Scrum kaller vi det gjerne  “inspect and adapt”; Prosessen er i kontinuerlig utvikling.

Hva er det i Scrum som hjelper oss til kontinuerlig tilpasning og forbedring? SuksessHer vil mange med Scrum-opplæring svare Retrospectiver! Dette er ikke feil, men det er langt flere mekanismer som stimulerer til dette i Scrum. Og tro meg, det å gjennomføre retrospectiver “etter boka” fører ikke nødvendigvis til denne utviklingen.

Her følger 5 prinsipper man kan velge å følge om man virkelig ønsker å hele tiden forbedre seg:

  1. Jobben gjøres i ansvarlige, tverrfaglige team
  2. Ta Scrum Master rollen på alvor
  3. Jobb i korte iterasjoner med hyppige leveranser
  4. Sørg for tett samarbeid mellom produkteier og utviklingsteamet
  5. Gjennomfør helhjertede Retrospectiver

I denne rekkefølgen. Retrospectiver kommer nederst på denne listen…

Ansvarlige, tverrfaglige team

Det er ingen tvil i Scrum – de som gjør jobben må få myndighet til å beslutte hvordan jobben skal gjøres – selvsagt innenfor gitte, tydelige rammer. Alt er basert på et grunnleggende positivt menneskesyn (theory Y) nemlig at folk er grunnleggende konstruktive og motiverte – gitt at de får tillit. Folk ønsker å gjøre en god jobb – å bidra til en større helhet.

Jobben gjøres i selvorganiserende team, hvilket innebærer at vi må våge å stole på at teamene løser problemene slik de selv finner best. Teamene må selvsagt ha all den nødvendige kunnskapen og ferdighetene som skal til for å utvikle gode løsninger. Når vi legger til at disse teamene får jobbe tett på markedet/kunden og stadig er i dialog med disse, vil vi kunne ende opp med team som har et fantastisk eierskap til jobben og som vil være genuint interessert i å gjøre en bedre og bedre jobb. Når dette prinsippet er på plass, vil veldig mye løse seg!

Scrum Master rollen

Et selvorganisert team skal ikke styres, men samtidig vet vi at det kan være svært krevende å få en gruppe med mennesker til å danne et velfungerende team med et brennende, kollektivt eierskap til jobben sin. Derfor trenger vi Scrum Master-rollen som er en person som jobber tett på teamet, men ikke er en del av teamet. En god Scrum Master er en menneskekjenner som vet noe om gruppedynamikk og teambygging, er en tilrettelegger og fasilitator, kan noe om coaching, og vet når det er riktig å utfordre Status Quo. Det er vanskelig å være en god Scrum Master om du befinner deg midt i teamet – og er en integrert del av prosessen. Du må faktisk ha en viss avstand for å gjøre gode observasjoner og evne å sette fingern på ting som kan forbedres. (Les gjerne mer om coaching av Scrum team her: )

Ofte vil teamet finne hindringer i organisasjonen de er en del av. Dette kan være i ledelsen, i andre avdelinger eller hos eksterne interessenter, altså steder som er utenfor teamets myndighet. Da er det helt vesentlig at Scrum Master tar med seg disse hindringene og snakker med de det gjelder og forsøker analysere ende-til-ende prosessene med tanke på å fjerne hindringer. Gjør gjerne dette i tverrfaglige workshops, eller inviter dem med i retrospectiver. Gode Scrum Mastere våger å utfordre!

Hyppige leveranser

Jeg har jobbet med faget prosessforbedring siden tidlig 90-tall, og den desidert største hindringen for å oppnå kontinuerlig forbedring var alltid mangel på feedback. Vi fikk kunnskap om hvor god jobb vi hadde gjort på et alt for sent tidspunkt, og dessuten var feedbacken ofte knyttet til en diger leveranse som gjorde det nær umulig å trekke noen konklusjoner. Årsak og virkning ble utvisket og vi var henvist til gjetning når vi skulle forbedre oss. Alt dette blir ekstremt mye bedre når vi klarte å dele opp leveransen i småbiter, levere ofte og få rask feedback. Dette er for meg så innlysende og grunnleggende at jeg kan glemme å presisere det når jeg holder kurs eller coacher.

Et godt team lager funksjonalitet som oppleves verdifullt i hvert inkrement. På den måten får vi alltid verdifull feedback og læring mens vi utvikler produktet.

Det tette samarbeidet mellom produkteier og utviklingsteamet

Scrum er basert på empirisk prosesskontroll og designet for å forhindre sub-optimalisering. Derfor er selve definisjonen av rollene i Scrum veldig tydelig: Scrum Teamet består av 3 og bare 3 roller: Produkteier, Utviklingsteamet og Scrum Master. Det er helt vesentlig at hele Scrum Teamet har en “vi-følelse” og aktivt bygge ned den tradisjonelle kløften mellom forretningssiden og IT-siden. Produkteier må virkelig representere forretningssiden – og ikke bare være en slags stedfortreder.

I gode Scrum team har produkteier jevnlig kontakt med utviklingsteamet (gjerne i forb med daglige scrummøter), de jobber jevnlig (ukentlig fungerer som regel godt) sammen med Product Backlogen der elementer estimeres, bearbeides og stykkes opp i mindre biter. Hver gang større produktikrementer planlegges, vil produkteier kommunisere visjonen til utviklingsteamet og jobbe sammen med dem i workshops for å utarbeide de nødvendige elementene (gjerne i form av User Stories).

Så, når denne kollektive vi-følelsen er på plass vil også utviklingsteamet fatte interesse for de virkelige, forretningsmessige problemstillingene man står overfor når de forsøker å finne bedre egnede metoder og teknikker. Jeg ser desverre svært sjelden at dette tette samarbeidet er på plass. Svært ofte er situasjonen motsatt: Produkteier er oppgitt over at utviklingsteamet ikke holder det de lover, utviklingsteamet skylder på at produkteier ikke var tydelig nok når han beskrev eller fortalte dem hva de skulle lage. Og sist men ikke minst: Retrospectivene blir innadvendte og forbedringene man diskuterer er ikke fundamentert i virkelige problemer. Det blir synsing og akademiske diskusjoner om hvilke teknikker som er best. Jeg kaller dette gjerne systematisk sub-optimalisering.

Retrospectiver

Så, til slutt, er det selve retrospective-møtet. Et vellykket retrospective er ikke i særlig grad avhengig av den prosessen som følges. Eller av de brainstormingsteknikkene man bruker. (Ikke noe feil med boka Agile Retrospectives av Diana Larsen og Ester Derby, men å følge denne prosessen er ikke nok!) Vellykketheten avhenger at punkt 1-4 over! Mangler ett av disse prinsippene vil retroen få begrenset nytteverdi.

Om teamet for eksempel mangler ansvarsfølelsen og eierkapet vil også disse møtene ganske snart ende opp i et kjedelig mønster. Et pliktløp. Og ting stagnerer.

Om de ikke har rett Scrum Master som brenner for sin del av jobben, våger å utfordre autoriteter og som evner å coache som en “servant leader”, vil også interessen for retrospectivene stagnere. Det er lite motiverende å oppleve at de finner hindringer, vedtar å forsøke å rette på disse, men ingen ting skjer…

Alt for få Scrum team leverer hvert produktinkrement. Dette kan vi ofte se på engasjementet i retrospectivene. Om alle vet at det som ble demonstrert på Sprint reviewet på langt nær var ferdig og skal igjennom vidreutvikling og debugging senere, har vi lite håndfast å snakke om på møtet. I team som leverer annenhver uke derimot, vil retrospectivene ta en helt annen form og vil ofte dreie seg om hvordan siste leveranse ble mottatt i markedet. Eller hvorfor en kritisk feil ikke ble detektert av kodereviewet.

Om produkteier ikke er interessert eller ikke en gang er invitert til retrospectivene vil møtene raskt gli over i en introvert, teknisk diskusjon som ikke er forankret i forretningsmessige forhold. Forandring er ikke nødvendigvis forbedring! Forbedring må resultere i en positiv effekt for hele organisasjonen.

 

Svaret på spørsmålet i innledningen blir da: De beste utfordrer kontinuerlig Status Quo gjennom å ta alle de 5 punktene på alvor!

Posted on January 2, 2013 at 4:14 pm by gamsjo · Permalink
In: ansvar, ledelse, Scrum, systems thinking, Teamarbeid · Tagged with: , , , , , ,

Leave a Reply