Voiko kehittäjä olla Scrum Master? 3 etua ja haittaa

Agile-tiimit ovat nykyaikaisen projektikehityksen selkäranka. Kysymys on kuitenkin edelleen: Voiko kehittäjä olla myös tehokas scrum master? Tai päinvastoin: Voiko scrum master olla myös kehittäjä? Jotkut tiiminvetäjät ovat huolissaan näistä pohdinnoista. Tässä artikkelissa yritämme vastata kysymykseen ja tuoda esiin kolme tämän kaksoisroolin etua ja haittaa.

Antaakseni sinulle lyhyen vastauksen jo etukäteen: Ketterässä maailmassa on harvoin selkeitä “kyllä” tai “ei” -vastauksia. Kaksoisrooli Scrum Masterina ja Scrum-kehittäjänä voi olla menestyksekäs, jos henkilö tuntee haasteet ja jongleeraa roolien välillä tietoisesti. Scrum Guide itsessään ei anna suoraa vastausta tähän kysymykseen, eikä se siten kiellä mahdollisuutta, että kehittäjä on Scrum Master tai Scrum Master on kehittäjä. Samalla on oltava selvää, ettei tämä vastaa optimaalista tilaa – lisää tästä alla.

Aloitetaan määrittelemällä lyhyesti, mistä rooleista tässä on kyse.

Sillä Scrumissa roolit ovat erittäin tärkeitä. Tässä mielessä selvennys “Scrum-kehittäjä vs. Scrum Master” on tärkeä: Scrum Master keskittyy prosessien optimointiin ja poistaa esteitä kehitystiimin tieltä. Sitä vastoin Scrum-kehittäjän painopiste on asiakkaiden vaatimusten teknisessä toteutuksessa.

Molemmat roolit täydentävät toisiaan, ja niiden välisten rajojen kunnioittaminen on ratkaisevan tärkeää tasapainon säilyttämiseksi ketterässä tiimissä. Voiko Scrum-kehittäjä siis olla myös Scrum Master tai Scrum Master Developer? Ennen kuin vastaamme tähän, vielä yksi etu näiden kahden roolin yhdistämisestä.

Yksi esimerkki tämän yhdistelmän myönteisestä puolesta on ohjelmistokehittäjän syvä ymmärrys ketterän ympäristön prosesseista. Kehittäjä scrum master voi optimoida kehitysprosesseja paremmin, koska hän on sisäistänyt sekä tiimin tarpeet että ketterät periaatteet. Tämä ymmärrys mahdollistaa Scrum-käytäntöjen ja -arvojen saumattoman integroinnin kehityssykliin.

Edellytyksenä tälle on tietysti se, että kyseisellä ohjelmistokehittäjällä on myös vastaava koulutus tai hän hallitsee Scrum Guiden ja on parhaassa tapauksessa jo kerännyt ulkopuolista coaching-kokemusta. Lisäksi tämä rooli vaatisi paljon aikaa molempien roolien täyttämiseen – se tulee olemaan vaikeaa.

Kääntöpuolena on kuitenkin objektiivisen näkökulman mahdollinen menetys. Kehittäjän scrum master ei ehkä pysty säilyttämään tarvittavaa etäisyyttä koodikatselmusten aikana, jotta hän voisi antaa puolueetonta palautetta. Kaksoistehtävässä on vaarana, että tärkeitä näkökohtia, jotka neutraali scrum master pystyisi paremmin havaitsemaan, jää huomiotta.

Toinen jo mainittu haitta, jolla voi olla vielä suurempi vaikutus: objektiivisesti katsottuna useimmissa ketterissä ohjelmistoprojekteissa ei ole riittävästi aikaa molempien roolien, scrum masterin ja ohjelmistokehittäjän, tehokkaaseen hoitamiseen rinnakkain. Jotkin vastuualueet kärsivät joka tapauksessa. Ja haittoja on vielä enemmän.

Yksi mahdollinen riski, joka kehittäjän scrum masterilla voi olla, on vaara jäädä omaan tekniseen kuplaansa. Koska yhteys kehitystyöhön on tiivis, tiimin sosiaaliset ja ihmissuhdehaasteet saattavat jäädä huomiotta. 

Scrum Masterin rooli edellyttää kuitenkin empaattista ja huomaavaista asennetta tiimin jäsenten yksilöllisiä tarpeita kohtaan. On tärkeää astua tietoisesti ulos teknisestä näkökulmasta ja ottaa huomioon myös inhimilliset näkökohdat. Loppujen lopuksi ketterässä manifestissa korostetaan yhteistyötä ja yksilöä enemmän kuin prosesseja ja työkaluja – muistutus siitä, että koodin taakse katsominen on yhtä tärkeää kuin tekniset näkökohdat.

Voiko Scrum Master olla osa kehitystiimiä vai ei? Yhteenvetona voidaan todeta, että kyllä, se on mahdollista, mutta sitä ei suositella.

"Monet tiimin jäsenet eivät uskalla puhua!"

Ratkaise tämä haaste

"Löydämme liian monta odottamatonta ongelmaa ja vikaa myöhäisessä vaiheessa!"

Ratkaise tämä haaste

"Miksi minulta kestää joskus tunteja valmistella yksinkertainen retrospektiivi?"

Ratkaise tämä haaste

Jos teillä ei todellakaan ole muuta mahdollisuutta kuin täyttää Scrum Master -rooli “osa-aikaisella” ohjelmistokehittäjällä, työkalumme Echometer voi auttaa teitä suuresti – se on kehitetty muun muassa tätä haastetta varten: Yksinkertaisen työkalumme avulla “osa-aikaisista” Scrum Mastereista tulee aikatehokkaasti ammattimaisia tiimivalmentajia.

Echometer on digitaalinen työkalu, joka auttaa ketterien tiimien johtajia ketterissä retrospektiiveissä ja tiimin Health Check:ssä. Olipa kyseessä etä-, hybridi- tai paikan päällä tapahtuva tiimivalmennus: se tekee tiimivalmennuksesta mitattavissa olevaa ja tekee siten työstäsi ammattimaisempaa ja säästää samalla paljon työtä. Katso lisätietoja verkkosivuiltamme: www.echometerapp.com.

Jos teillä ei todellakaan ole muuta vaihtoehtoa kuin muuttaa ohjelmistokehittäjä osa-aikaiseksi Scrum Masteriksi, kokeilkaa vähintään Echometeriä maksimoidaksenne onnistumisen todennäköisyyden.

Christian Heidemeyer, psykologi & Scrum Master

Voiko Scrum Master olla osa kehitystiimiä? Kaksoisrooli “kehittäjä-Scrum Master” avaa mahdollisuuksia synergioille, mutta vaatii selkeitä roolimäärityksiä mahdollisten haittojen välttämiseksi. Ketterä Scrum Master, jolla on kehittäjätausta, voi rakentaa sillan tekniikan ja tiimityön välille, edellyttäen että hän navigoi taitavasti molempien roolien välillä. Ja juuri tästä tulee käytännössä erittäin vaikeaa, joten sitä yleensä ottaen ei suositella. Jos muuta keinoa ei ole, anna Echometerin kaltaisten työkalujen auttaa.

Siksi vielä kerran huomautus: Jos haluat kokeilla, miltä tuntuu kehittää tiimiäsi työkalullamme: Voit aloittaa ketterän retrospektiivin, tässä tapauksessa “Keep, Stop, Start” -työpajan, seuraavasta linkistä ilman kirjautumista. 

Vaihtoehtoisesti voit myös yksinkertaisesti lähettää verkkosivumme eteenpäin asiasta vastaaville kollegoille: www.echometerapp.com.

Miten

Pidä Stop Start Retro: Näin retro etenee

1. Satunnainen jäänmurtaja (2–5 minuuttia)

   Echometer tarjoaa satunnaisten sisäänkirjautumiskysymysten luojan.

2. Avoimien toimenpiteiden tarkastelu (2–5 minuuttia)

   Ennen kuin aloitat uusia aiheita, sinun tulisi keskustella menneiden retrospektiivien toimenpiteiden tuloksista tehokkuuden tarkistamiseksi. Echometer listaa automaattisesti kaikki avoimet toimenpiteet menneistä retrospektiiveistä.

3. Retro-aiheiden käsittely

   Käytä seuraavia avoimia kysymyksiä tärkeimpien havaintojesi keräämiseen. Ensin jokainen itsenäisesti. Echometer mahdollistaa retrotaulun jokaisen sarakkeen paljastamisen erikseen, jotta palautetta voidaan sitten esitellä ja ryhmitellä.

   • Jatka: Mitä meidän pitäisi säilyttää?
   • Stop: Mihin meidän pitäisi lopettaa?
   • Aloitus: Mitä meidän pitäisi aloittaa?

4. Yleiskysymys (suositus)

   Jotta muillakin aiheilla olisi paikkansa:

   • Mistä muusta haluaisit puhua retrospektiivissä?

5. Priorisointi / Äänestys (5 minuuttia)

   Echometerin retrotaululla voit helposti priorisoida palautteen äänestyksellä. Äänestys on luonnollisesti anonyymi.

6. Toimenpiteiden määrittely (10-20 minuuttia)

   Palautteeseen voidaan luoda linkitetty toimenpide plus-symbolin avulla. Etkö ole vielä varma, mikä toimenpide olisi oikea? Avaa sitten plus-symbolin kautta aiheeseen liittyvä Whiteboard, jossa voit ideoida perussyitä ja mahdollisia toimenpiteitä.

7. Uloskirjautuminen / Lopetus (5 minuuttia)

   Echometerin avulla voit kerätä anonyymiä palautetta tiimiltä siitä, kuinka hyödyllinen retro oli. Tästä syntyy ROTI-pistemäärä ("Return On Time Invested"), jota voit seurata ajan mittaan.

Pidä Stop Start Retro

Jatka: Mitä meidän pitäisi säilyttää?

Stop: Mihin meidän pitäisi lopettaa?

Aloitus: Mitä meidän pitäisi aloittaa?

Avaa tämä retro nyt Sopeudu...