Tiimityön neljä tasoa tekoälyn aikakaudella
Tekoäly nopeuttaa ohjelmistokehitystä, mutta ei automaattisesti tiimityötä, jos oppiminen ja päätöksenteko laahaavat perässä.
Tekoälyn aikakaudella tiimityön tuottavuus riippuu kolmen eri nopeuden yhteispelistä: tekoälyn toteutusnopeudesta, tiimin oppimisnopeudesta ja organisaation päätöksentekonopeudesta. Jos näitä ei synkronoida keskenään, koodia voi syntyä enemmän kuin koskaan, mutta asiakasarvo ja liiketoiminnan tulokset voivat jäädä kauas odotuksista.
Tiimin oppimisnopeus tarkoittaa käytännössä inspect–adapt-syklin nopeutta: kuinka nopeasti tiimi havaitsee, oppii ja korjaa suuntaansa. Organisaation päätöksentekonopeus taas näkyy esimerkiksi siinä, voiko tuoteomistaja tehdä päätöksiä itsenäisesti vai vaatiiko eteneminen ylempää hyväksyntää.
Tästä kirjoitin tuoteomistajan näkökulmasta. Nyt katse kääntyy tiimiin.
Tiimi on joukko ihmisiä, joilla on yhteinen tavoite, jotka ovat työssään riippuvaisia toisistaan ja jotka kantavat yhdessä vastuun lopputuloksesta. Käytännössä moni “tiimi” on kuitenkin joukko asiantuntijoita, joilla voi olla yhteinen organisaatiokaavio, mutta erilliset työt ja tavoitteet.
Bruce Tuckmanin klassinen malli – Forming, Storming, Norming, Performing, Adjourning – kuvaa tiimin kehityksen tyypillisiä vaiheita. Malli ei kuitenkaan kerro kovin käytännöllisesti, millä tasolla tiimi juuri nyt toimii tai miten se voisi kehittyä korkeammalle tasolle. Tarvitaan yksinkertaisempi mittari sille, miten työtä oikeasti jaetaan ja tehdään.
Professional Scrum Master -koulutusteni havaintojen pohjalta olen jäsentänyt mallin, jota kutsun nimellä Tiimityön neljä tasoa. Malli auttaa tunnistamaan, millä tasolla tiimi nyt toimii ja mitä sen pitäisi seuraavaksi oppia, jos se haluaa hyödyntää tekoälyn potentiaalia koko tiimin tasolla eikä vain yksilöinä. Tasot eivät sulje toisiaan pois, vaan kuvaavat mikä tiimin yhteistyössä painottuu. Esimerkiksi yhteinen tavoite on välttämätön myös korkeammilla tasolla.
Tiimityön neljä tasoa
1. Yhteinen tavoite
Ensimmäinen kysymys on yksinkertainen: työskenteleekö koko tiimi päivittäin kohti samaa tavoitetta?
Yhteinen tavoite ei ole “tehdä rahaa” tai “tehdään sprintin kaikki työt”. Ne ovat liian epämääräisiä ohjaamaan arjen päätöksiä. Aito yhteinen tavoite, kuten hyvä Sprint Goal, auttaa tiimiä päättämään, mitä tehdään seuraavaksi, missä järjestyksessä ja kenen kanssa.
Tässä kulkee myös työryhmän ja tiimin raja. Työryhmä tekee töitä rinnakkain. Tiimi tekee töitä yhdessä kohti yhteistä lopputulosta. Jos yhteinen tavoite ei oikeasti ohjaa tekemistä, kyse ei vielä ole aidosta tiimistä.
2. Henkilökohtaiset työt
Monessa tiimissä työtä jaetaan henkilökohtaisesti ja työn eräkoko on suuri. Esimerkiksi ohjelmistotiimissä yksi asiantuntija ottaa yhden käyttäjätarinan, toinen toisen ja kolmas päättää korjata hankalan bugin. Tämä vaikuttaa tehokkaalta ja tuntuu monesta täysin normaalilta.
Ongelma näkyy sprintin lopussa. Ensimmäinen työ on 80 prosenttia valmis, toinen 90 prosenttia ja kolmas odottaa vielä testausta. Kaikki ovat olleet kiireisiä, mutta mitään oikeasti valmista ei voida toimittaa käyttäjille.
Kun työn omistajuus on henkilökohtaista, läpimenoaika hidastuu. Jokaisella on oma tonttinsa. Toisen keskeneräiseen työhön ei mielellään kosketa. Tiimi optimoi yksilöiden käyttöastetta, vaikka sen pitäisi optimoida valmiin työn eli arvon virtausta.
Melkein valmis ei ole valmis, vaan se on kesken. Stop starting – start finishing!
3. Jaetut tehtävät
Kolmas taso alkaa siitä, että tiimi ymmärtää eron työn ja tehtävän välillä.
Työ eli Product Backlog Item, kuten ohjelmiston toiminto, käyttäjätarina tai korjaus, kertoo mitä tehdään ja miksi. Tehtävät eli taskit tai subtaskit kertovat, miten se tehdään käytännössä. Kun yksi toiminnallisuus pilkotaan pieniksi, konkreettisiksi tehtäviksi, useampi ihminen voi edistää samaa kokonaisuutta ilman, että työ hajoaa sekavaksi sähläykseksi.
Kolmannella tasolla tiimi lakkaa puhumasta “Matin storystä”. Tilalle tulevat tiimin yhdessä omistamat tehtävät, joiden kautta tiimi toteuttaa mieluiten yhden toiminnallisuuden eli PBI:n kerrallaan. Pienelle toiminnolle ei toki aina kannata kirjoittaa erillisiä tehtäviä, eikä tehtäviä yleensä kannata työmääräarvioida. Tehtävät ovat yksinkertaisia muistilappuja yhteistyön tueksi, jolloin asiantuntijoiden on helppo lisätä, poistaa ja muokata niitä milloin tahansa sprinttitaululla eli Sprint Backlogissa.
Tämä ei tarkoita, että kaikkien pitäisi osata tehdä kaikkea. Riittää, että tiimissä on tarvittava osaaminen ja halu auttaa toisia. Mitä pienempi, näkyvämpi ja jaettavampi tehtävä on, sitä helpompi siihen on yhdessä tarttua ja tarvittaessa oppia uutta.
4. Yhteinen tehtävä
Korkein taso on se, että tiimi työskentelee saman tehtävän parissa yhtä aikaa.
Käytännössä tämä tarkoittaa Mob Programmingin pohjalta syntyneitä tekoälyavusteisia tiimityön muotoja, kuten Joe Justicen MobAI:ta ja Marko Taipaleen CollabAI:ta. Tunnen Mob Programmingin uranuurtajan Woody Zuillin sekä Joe Justicen ja Marko Taipaleen, joiden mallit ovat mielestäni käytännössä identtiset: yksi yhteinen tehtävä, yksi yhteinen fokus, jatkuva keskustelu, muutama pysyvä tai kiertävä rooli, välitön palaute, yhteinen validointi ja vastuu lopputuloksesta sekä tekoäly aktiivisena apurina.
Tämä kuulostaa monen korvaan tehottomalta, koska olemme tottuneet pitämään rinnakkaista yksintyöskentelyä tehokkuuden merkkinä. Tekoälyn aikakaudella varsinainen pullonkaula ei kuitenkaan useinkaan ole enää koodin kirjoittaminen. Usein todelliset pullonkaulat ovat nyt nämä:
- Mikä käyttäjien ongelma kannattaa ratkaista nyt?
- Mikä tekoälyn ehdottama ratkaisu on oikeasti hyvä?
- Mitä uskalletaan viedä versionhallintaan ja julkaista?
- Mitä opittiin ja mitä muutetaan seuraavaksi?
Näitä ei ratkaista parhaiten omissa siiloissa, vaan koko tiimin keskustelulla.
Mitä tämä tarkoittaa käytännössä?
Jos tiimi työskentelee edelleen niin, että jokainen nappaa “oman työn” eli PBI:n ja katoaa sen kanssa koneelleen, tekoäly ei todennäköisesti nosta tiimin suorituskykyä ja käyttäjien tyytyväisyyttä niin paljon kuin toivotaan. Se kyllä nopeuttaa yksittäisiä asiantuntijoita, mutta voi kasvattaa keskeneräisen työn määrää entisestään, jos oppiminen tai päätöksenteko jumittavat.
Korkeamman tason tiimi toimii toisin. Se omistaa työn yhdessä, pilkkoo sen näkyvästi, tarttuu keskeneräiseen yhdessä ja siirtää fokuksen käyttöasteesta läpimenoaikaan. Kaikkein pisimmälle kehittyneet tiimit menevät vielä pidemmälle: ne oppivat, päättävät ja ratkovat tärkeimpiä ongelmia yhdessä, usein samanaikaisesti ja tekoälyn tukemana.
Tekoälyn aikakaudella tärkein kysymys ei enää ole, kuka kirjoitti koodin. Tärkeämpää on, kuinka nopeasti tiimi pystyy yhdessä ymmärtämään ongelman, tekemään päätöksiä, validoimaan ratkaisun ja toimittamaan käyttäjille jotain oikeasti hyödyllistä.