Valeketteryys, kuokka ja Jussi

Vuonna 2008 olin onnistunut myymään ketterää portfolionhallintaa tarkastelevan tutkimusprojektimme “täysjäsenyyden” noin 70 hengen kasvavaan ohjelmistopalveluja tarjoavaan yritykseen. Tutkimusprojektimme nimissä minun oli tarkoitus kehittää heidän projektisalkun hallintaansa. Oikeasti he olivat lähteneet mukaan siksi, että olimme sopineet, että samalla saadaan avullani ajettua sisään kelvollinen työkalu työtuntien kirjaamiseen.

Siinä samalla kun neuvoin tuntikirjausten tekemistä ja töiden mallintamista Agilefantiin huomasin, että ne organisaation entiteetit, joita he kutsuivat Tiimeiksi olivat itse asiassa osaamisalueittain järjestettyjä porukoita – tai “resurssipuuleja”.

Näistä porukoista sitten vedettiin kasaan projekteihin kulloinkin tarvitut kaverit. Tämä puolestaan johti siihen, että jossakin teknologiassa edistyneimmät, kuten Saara (nimi muutettu), osallistuivat useaan projektiin kerrallaan.

Aloinkin siksi hivuttamaan myös ajatusta siitä, että nämä heidän “tiiminsä” eivät muuten olekaan tiimejä. Mitäs jos pyrittäisiinkin muodostamaan ihan oikeita tiimejä? Lähdettäisiin systemaattisesti levittämään osaamista niillä alueilla, joissa yksittäiset osaajat muodostuvat pullonkaulaksi.

Kyseisen yrityksen johdon mielestä eri tiimien ekspertit ovat kuitenkin niin pitkälle spesialisoituneet omassa osaamisessaan, että tehokkuuden nimissä kannattaa toimia kuten on toimittu ennenkin.

Kokemuksista oppineena päätin koota teille, rakkaat valeketteryytysten suota raivaavat lukijat, kasan valikoituja linkkejä. Näiden avulla pystytte toisaalta levittämään tietoisuutta siitä, miksi komponenttitiimit johtavat monenlaisiin epäoptimaalisiin organisaatiorakenteisiin ja hidastavat läpimenoaikoja, mutta toisaalta myös tietoa siitä, millaisiin kompromisseihin kannattaa suostua, jos komponentti- tai osastokohtaista organisaatiorakennetta ei ainakaan heti pysty purkamaan.

Kuivata suo...

Ketteryyden ja transformaatioiden yhteydessä puhutaan usein “kulttuurista” ja “mindsetista”. Todellisuudessa ketteryyden tärkeimmät – ja haastavimmat – kulmakivet ovat organisaation rakenteissa.

Tärkeimmät näistä rakenteista ovat kokemukseni mukaan poikkifunktionaaliset täysiaikaiset tekijätiimit – tai pikemminkin niiden puute – sekä vuosibudjetoinnin muuttaminen inkrementaaliseksi. Jos nämä saadaan aikaiseksi, loput yksityiskohdat aika pitkälle loksahtavat paikoilleen itsestään.

Tiimien tulisi myös olla verrattain pysyviä, ja niiden tulisi olla osaamiseltaan sellaisia, että ne pystyvät viemään läpi työnsä määrittelystä tuotantoon asti. Tämä ei suinkaan tarkoita, että jokaisen tiimiläisen tulisi osata tehdä kaikkea. Spesialistejakin tarvitaan, mutta heidän työnsä tekee mahdolliseksi se, että tiimissä on moniosaajia.

Ahmad Fahmyn artikkelissa The Rise of the Team on muutama käytännön esimerkki, miten tiimit saadaan muodostettua asiakasarvon ympärille.

...tai hanki kahluusaappaat

Harmillisen usein hyppy täysiaikaisiin tiimeihin tai etenkin osastojaon/komponenttivastuiden purkamiseen tuntuu "liian suurelta muutokselta”. Tämän vuoksi komponenttitiimit ovat useimmissa organisaatioissa vielä arkipäivää. Osa-aikainen tiimi taas on ryhmä, joka periaatteessa sisältää kaiken tarvittavan osaamisen asiakasarvoa lisäävän työn tuottamiseen (esim. featureiden A ja B edistäminen ja tuotantoonvienti), mutta heillä on muitakin merkittäviä tehtäviä. Tällainenkin organisaatiorakenne on pikemminkin sääntö kuin poikkeus.

Useimmat organisaatiot ovat kasvaneet matriisirakenteeseen, ja matriisiorganisaatioiden fundamentaali ominaisuus on maksimoida resurssien käyttöaste. Kaikella on tietysti puolensa, mutta resurssien käyttöasteen maksimointi on ristiriidassa niiden periaatteiden kanssa, joihin ketteryys perustuu.

Koska komponenttitiimit ja/tai osa-aikaiset tiimit ovat kovin yleisiä, olen aiheeseen liittyvien kirjoitusten ja ajatusten pohjalta koonnut muutaman nyrkkisäännön, joiden puitteissa toimimalla voidaan epäoptimaalisten tiimirakenteiden aiheuttamia haittoja lieventää.

Älä pidennä sprinttejä vaan skaalaa seremonioiden kestoja

Ei ole epätavallista, että etenkin alkuvaiheessa esim. Scrumin sisältämien seremonioiden (sprinttisuunnittelu, dailyt, retro, demo) koetaan vievän liikaa aikaa itse tekemiseltä. Tämä johtuu siitä, että malliin kuuluvien toistuvien tapahtumien lisäksi tiimiläisten muihin vastuisiin liittyvät kokous- ym. raportointikäytännöt eivät ole poistuneet mihinkään.

Tällaisessa tilanteessa voi tiimillä olla kiusaus pidentää sprinttejä ja/tai jaksoja, jotta mallin seremoniat toistuisivat harvemmin ja aikaa jäisi enemmän itse tekemiselle. Jaksojen tai sprinttien pidentäminen ei kuitenkaan oikeasti auta, vaan pikemminkin pahentaa tilannetta, koska takaisinkytkentä harvenee.

Keskeinen periaate on pitää sprintit kalenterikestoltaan samanpituisina (tässä tapauksessa 2 viikkoa), mutta skaalata toistuvien tapahtumien ajallisia kestoja lyhyemmiksi vastaamaan tiimin todellista allokaatiota yhteiseen tekemiseen. Esimerkiksi täysiaikaisen tiimin kahden viikon sprinttirytmissä suositus demon, retron ja seuraavan sprintin suunnittelun kestolle on neljä tuntia.

Jos päätät vähentää seremonioita, säilytä ainakin retrospektiivi

Mitä tahansa perutkin valitsemasi mallin (esim. Scrum) seremonioista, älä peru retrospektiivejä.

Retrospektiivit ovat se kaikkein tärkein seremonia ! Jos et usko, lue edellä olevat linkit ja tutkiskele asiaa sydämessäsi.

On myös paljon helpompi kasvattaa ketteryyttä vähän kerrassaan tiimin oman oivaltamisen, toisin sanoen hyvin fasilitoitujen retrospektiivien kautta, kuin pakottaa “teoreettista ideaalitilanteeseen perustuvaa” viitekehystä ulkoa päin.

Varmista, että tiimilläsi on alkuvaiheessa fasilitaattori

Erityisesti alkuvaiheessa seremonioiden skaalaaminen lyhyemmäksi voi olla vaikeaa, koska uuden opettelu vie oman aikansa. Hanki joku, jolla on kokemusta, osallistumaan sprinttisuunnittelujen, dailyjen, retrojen ja demojen vetämiseen.

Varaudu myös henkisesti siihen, että fasilitaattorista huolimatta näihin tapahtumiin tulee alkuvaiheessa kulumaan rutkasti "suositusta enemmän" aikaa.

Sovi tiimille koordinaattori ja tee kalenterivaraukset yhteiselle tekemiselle

Kannattaa sopia tietyistä päivistä ja/tai ajankohdista, jolloin keskitytään yhteiseen tekemiseen.

Mikäli tiimissä on useampi kuin yksi jäsen, tiimin tulisi myös sopia keskuudestaan koordinaattori, jonka vastuulla on hoitaa käytännön järjestelyjä, kuten

• kalenterivarausten tekeminen tiimin yhteisille tapaamisille (sprintin suunnittelut, demot ja retrot, sekä dailyt)

• tapaamisten puheenjohtajana toimiminen

• fasilitaattorin hankkiminen!

Scrum Master -roolihan on hengeltään näihin kaikkiin – mukaan lukien fasilitointiin – enemmän kuin sopiva. Kokemukseni mukaan Scrum Master -termin käyttäminen silloin, kun tekeminen ei ole Scrumia, tuottaa kuitenkin enemmän harmia kuin iloa.

Pysyvien tiimien tapauksessa suositeltavaa on valita koordinaattoriksi joku tiimistä, ei fasilitaattoria tai spesialistia (jotka saattavat vaihtua sprintistä toiseen) tai tuoteomistajaa (jolla on liikaa tekemistä jo valmiiksi).

Tässä tapauksessa kannattanee valita henkilöitä, joiden todennäköisesti voidaan ajatella aina olevan eri tiimeissä.

Älä luovu pitkäikäisten poikkifunktionaalisten tiimien unelmasta

Jos pysyt sitkeänä, eikä sinua siirretä sellaisiin tehtäviin, joista on vaikeampi tökkiä vallitsevia organisaatiorakenteita, käy ennemmin tai myöhemmin niin, että johto vaihtuu sellaiseksi joka ymmärtää näiden asioiden merkityksen ja ryhtyy toimiin. Voi myös käydä niin, että tiimit retrospektiivien kautta oivaltavat itse muodostua järkevämmin. Sitä odotellessa, muista että oppiminen ja vanhasta pois oppiminen vievät oman aikansa. Pidä pää kylmänä ja vahvista uskoasi kuuntelemalla parhaita ketteryydestä kertovia esityksiä YouTubesta.