Prosjekter kommer og går, Scrum teamet består

Prosjektet har en del egenskaper som ikke alltid er formålstjenlig. Ta for eksempel det at et prosjekt per definisjon utføres av en midlertidig organisasjon som jobber mot en sluttermin. Jeg har tidligere diskutert at dette lett kan føre til sub-optimalisering ved at prosjektteamet fokuserer for mye på det kortsiktige behovet å tilfredsstille tidsplanen, mens de mer langsiktige egenskapene (vedlikeholdbarhet, struktur osv) ved produktet ofres. Mange organisasjoner starter og stopper små og store prosjekter hele tiden. Dette fører til stress og unødvendige belastninger. Noen mellomledere bruker minst halve tiden sin på å “legge ressurskabalen” der man hele tiden forsøker å benytte de beste ekspertene på de rette prosjektene. Dette fører til mye avbrytelser og dårlig kontinuitet i arbeidet (task switching) samt store problemer å forstå hva som egentlig skjer i organisasjonen.

Hvorfor ikke gjøre dette helt annerledes? Hvorfor ikke si at alt arbeidet utføres av permanente Scrum team? Så kan vi bare sluse arbeid inn til teamets Product Backlog via Product Owner.

I figuren ser vi hvordan rød, blå og gul prosjektleder har hvert sitt omfang i hvert sitt prosjekt. Det kan hende alle prosjektene skal inn i samme fysiske produkt – det er ofte slik i organisasjoner med egenutviklet programvare. Uansett, hvis vi setter opp en permanent Scrum-organisasjon som vi forer med arbeid via prosjekter vi starter sammen med kundene så slipper vi denne sub-optimalisering. Dette teamet og denne produkteieren vil ha interesse av at produktet ikke skal forvitre og gradvis få mer teknisk gjeld. De vil over lang tid sammen få muligheten til å etablere helt bevisste metoder og verktøy som fører til høy kvalitet også under overflaten.
Dette Scrum teamet må selvsagt være tverrfaglig og ha domenekunnskap til å håndtere flere ulike prosjekter i parallell slik figuren viser. Produkteier må selvsagt ha det siste ordet når det gjelder prioritering og rekkefølgen problemene skal løses i.

Posted on July 22, 2011 at 12:05 pm by gamsjo · Permalink
In: ledelse, prosjektledelse, Scrum · Tagged with: , ,

6 Responses

Subscribe to comments via RSS

  1. Written by Espen
    on 27/07/2011 at 12:49 pm
    Reply · Permalink

    Vi i FINN.no har gjort det du sier siden i fjor høst. Det vi gjør i tillegg til det du skisserer er at hos oss så består ikke et team bare av de som utvikler, men også inkulderer selgere. Vi har kryssfunksjonelle team som er underlagt et marked og på den måten unngår vi det du snakker om.
    Hvis et marked ønsker å gjøre en satsning på noe (eller prosjekt som du kaller det) så gjør de det med sitte team, uten noe behov for å hente folk fra en pool av mennesker.

  2. Written by gamsjo
    on 27/07/2011 at 2:38 pm
    Reply · Permalink

    Vet det, Espen. FINN har vel egentlig holdt på sånn i flere år – men så er vel dette det mest modne smidig-selskapet i landet for tiden(?) Veldig “modent” å inkludere selgerne – tipper det blir gode synergieffekter å hente ut samtidig som du forhindrer sub-optimalisering. Må være givende å ha retrospectiver i en slik tverrfaglighet!

  3. Written by Espen
    on 29/07/2011 at 7:45 am
    Reply · Permalink

    Største utfordringen er når de individuelle teamene også bidrar inn i noe som er felles. Avveiningene mellom lokale optimaliseringer vs det å sørge for at helheten samtidig fungerer er den store utfordringen med denne typen organisering. Hvis teamene ikke er helt uavhengige av hverandre i det de gjør så oppstår denne spenningen og den er en utfordring du møter hver dag. Hva gjør du om noe viktig må gjøres på tvers, men som likevel ikke er viktig nok til at noen team vil prioritere å gjøre det?
    Jeg har lest at Facebook setter igang ulike initiativer ved å la teammedlemmer søke seg til å være med på en satsning/prosjekt som varer i noen måneder. Hva andre gjør vet jeg ikke. Vi har forsøkt å løse det ved å ha noen team som faktisk jobber med det som er felles.

  4. Written by gamsjo
    on 29/07/2011 at 6:40 pm
    Reply · Permalink

    Løsningen ligger selvsagt i retrospectivene. Enkelte slike bør gjøres “i plenum” om det er mye avhegnigheter mellom teamene. Hvis det er enighet om at dette er et vesentlig problem for firmaet så finnes det løsninger.
    Her kommer noen forslag:
    * En “chief product owner” med noe teknisk innsikt for å sikre at integrasjon og arkitektur får den nødvendige prioritet.
    * Noen øremerker kapasitet (20 %?) på “felles ting”.
    * Noen har “communities” som går på tvers av teamene der arkitekter og systemtesteksperter har møteplasser (noen kaller det virtuelle team) for å sikre helheten.
    * Product Owner teams der tekniske (og gjerne andre) eksperter former et team rundt PO slik at helheten blir ivaretatt. Typisk arkitektur, systemtest, Ux, DB osv..

  5. Written by Espen
    on 24/08/2011 at 11:38 am
    Reply · Permalink

    Vi gjør faktsk alle de tingene du nevner, hvilket kanskje kan være en av grunnene til at vi ikke helt får det til 🙂
    Å sette av kapasitet til felles ting føler jeg er omtrent samme som Google sin 20% time. Dette er noe som burde være unødvendig.
    Virtuelle team fungerer bra i tilfeller hvor det virkelig brenner og alle er enig i at noe må gjøres. De fungerer ikke like bra når det er rengjøring og oppryddings type oppgaver. Da får du ikke noen push på å få prioritert mennesker/tid.
    Tekniske team fungerer ganske bra. Utfordringen da blir mer av en teritorial art. Hvem eier hva og har ansvaret for hva. Kan alle endre kode eller er det bare noen få? Kan et teksnik team endre noe som “tilhører” andre team.

    Vanskelige saker dette og løsningen slik jeg ser det er å forsøke skille ting ut i små enheter som er selvstendige. Fjerne avhengighetene og dermed unngå problemet med ting som er felles.

  6. Written by gamsjo
    on 24/08/2011 at 3:13 pm
    Reply · Permalink

    Hmmm, kan det hende at slike utfordringer er en del av gamet og at det viktigste er at dere er bevisste på det? Diskuterer dere problemene tverrfaglig? Hvor stort er egentlig problemet for businessen?

    Det å forsøke å lage uavhengige selvstendige enheter høres besnærende ut. Løst koblede funksjonelle enheter er jo måten å få til fleksibilitet, skalerbarhet og uavhengighet. Mener Amazone forteller at de gjorde en stor arkitekturjobb for noen år tilbake nettopp for at de ulike satsningsområdene kunne vokse og utvikle seg maksimalt uavhengige av resten. Løst koblede moduler som er en-til-en med organisasjonen.
    Men er det realistisk i FINN? Det er jo investert mye i felles plattform…

Subscribe to comments via RSS

Leave a Reply