Scrum of Scrum - optimaalinen tiimikehitys skaalaamisen perustana.

Mitä yhteistä on tiimikehityksellä ja Scrum of Scrumilla? Ne käsittelevät tiimien kasvua ja optimointia. Periaatteessa ennen kuin skaalaan ketteriä menetelmiä, tiimiä pitäisi kehittää optimaalisesti. Voit selvittää, milloin tiimi on optimaalisesti kehitetty täällä tai meidän Blogiartikkeli.  

Mikä on Scrum of Scrum?

Scrum of Scrum on tapa skaalata Scrumia useisiin tiimeihin ja tarvittaessa koulutuksiin. Muita menetelmiä ovat esimerkiksi SAFe, LeSS tai Nexus.

Scrum of Scrums onnistuu erityisesti silloin, kun kaikki Scrum-tiimin jäsenet pyrkivät yhteiseen tavoitteeseen, luottavat ja kunnioittavat toisiaan ja toimivat yhdessä. Tämä edellyttää tiimin kehittämistä etukäteen.

Tuomio 

“Tarpeeksi pieni pysyäksemme ketteränä ja tarpeeksi suuri saadaksemme tärkeät tehtävät tehtyä sprintissä” 

saatat tietää. Milloin on oikea aika kasvattaa yritystoimintaa? Mikä on optimaalinen tiimin koko ja mitä sinun on otettava huomioon tiimiä kehittäessäsi? Onko tähän olemassa tiimin kehittämissuositus?

Ensin tarina Scrum of Scrumsista

Jeff Sutherland ja Ken Schwaber etsivät menetelmää, joka mahdollistaisi ketterän työskentelyn useiden tiimien kanssa. Tärkeää oli, että kaikki eivät työskentele itsekseen, vaan että kaikki työskentelevät koordinoidusti yhdessä. Se oli virstanpylväs ketterässä kehityksessä. Jeff Sutherland kirjoitti tästä myös kirjan. “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”joka ilmestyi vuonna 2001. 

Scrum of Scrums ja ketterien menetelmien skaalautuvuus ovat sittemmin yleistyneet yhä enemmän. Voidaan kuitenkin sanoa, että COVID-19-pandemia on antanut suurimman sysäyksen ketterälle kehitykselle – ainakin sovelluksille muilla aloilla kuin ohjelmistokehityksessä. Periaatteessa ketteriä menetelmiä voidaan aina soveltaa, kun vaatimukset ja teknologiat ovat monimutkaisia. The Stacey Matrix ja Cynefin-kehys auttaa sinua luokittelemaan ne. Osoitteessa Scrum@Scale-opas löydät kaikki tiedot skaalautumisesta.

Vinkkinä mainittakoon, että skaala kannattaa laajentaa vasta sitten, kun yksittäinen tiimisi toimii hyvin yhteen ja on toimiva. Jos sinulla on jo ongelmia Scrumin kanssa yksittäisen tiimin tasolla, sinun ei kannata skaalata. Tiimin kehittämissuositukseni täällä: Kehitä ensin tiimiä ja puutu sen ongelmiin ennen kuin aloitat skaalaamisen.

Muuten, lyhyt huomautus ketterän transformaation yhteydessä: Haluatko varmistaa, että priorisoitte tällä hetkellä oikeita asioita ketterässä muutoksessanne? 

Tee sitten kypsyysastetarkistuksemme ketterälle transformaatiollenne – kestää vain 3 minuuttia. Saat jopa vertailuarvon, joka perustuu yli kolmeensataan muuhun osallistujaan. Katso painike 🙂

Scrum of Scrumin tarkoitus

Scrum of Scrum on Scrumin ensimmäinen looginen laajennus, kun siirrytään tiimin ketteryydestä koko yrityksen ketteryyteen. Skaalautumisen ratkaiseva edellytys on oikea tiimin kokoonpano. Seuraaviin kysymyksiin olisi vastattava: 

• Kuka työskentelee missäkin asemassa tiimissä?
• Kuka työskentelee kenen kanssa?
• Ketkä sopivat erityisen hyvin yhteen?
• Kenellä on mikä rooli?

Olemme havainneet, että roolien selkeys on erittäin tärkeää. Muuten: Jos haluat tietää, mitä vipuja voit käyttää innovaation luomiseksi tiimissä, tutustu tähän. Video an. Joukkueet tarvitsevat myös aina riittävästi aikaa ja tilaa kehittyäkseen. Täältä voit lukea myös Tuckmanin Tiimin kehittämisen vaihemalli tutustua toisiinsa: 

1. Muodostaminen (saapumis- ja selvitysvaihe),
2. Storming (riita- ja argumenttivaihe)
3. Norming (Sääntely- ja valmisteluvaihe)
4. Suorittaminen (työ- ja suoritusvaihe).

Lähde: Tuckmanin vaihemalli tiimin kehitykselle

Tavoitteena on koordinoida pienempiä, ketteriä ja itsenäisiä tiimejä, jotka keskittyvät täysin asiakkaiden tarpeisiin ja toiveisiin. Asiakaskeskeisyyden aihe voi olla täällä Haluaisin myös tarkastella sitä yksityiskohtaisemmin. Siksi sinun pitäisi aina mennä Asiakasmatka asiakkaasi. Ole vain asiakkaasi ja aloita näkökulman muutos. Käytännössä asiakkaiden on valitettavasti vielä melko usein sopeuduttava yhteistyöyrityksen prosesseihin. Erityisesti viranomaisissa, mutta myös joissakin suuremmissa yrityksissä tai konserneissa. Se ei kuitenkaan ole Scrumin idea. 

Dominic Price kirjoittaa “Näiden viiden harhaluulon purkaminen tekee sinusta innovatiivisemman.” viisi harhaluuloa, joista sinun pitäisi päästä eroon, jotta voisit olla innovatiivisempi.

1. “Kasvu” ei ole sama kuin “skaalautuminen”.
2. “Transformaatio” ei ole sama kuin “evoluutio”.
3. “Häiritsevä” ei ole sama kuin “häiriintynyt”. 
4. “Osallistumisaika” ei ole sama kuin “aloite”. 
5. “Tuotokset” eivät ole yhtä kuin “tulokset”.

Yhteenvetona tämä tarkoittaa, että tehokkuus on hyvä, mutta tehokkuus on parempi. Kiinnitä aina huomiota tehokkuuteen.

Kokemuksesta voimme sanoa: mitä useampi ihminen työskentelee saman ongelman parissa, sitä vaikeampaa on päästä ratkaisuun. Etenkin, jos he ovat monialaisia, itsenäisiä tiimin jäseniä. Suuremmiksi kasvavien tiimien ratkaisu on kuitenkin skaalautuminen. . Scrum-opas tarjoaa perustan tiimeille ja yrityksille, jotka tarvitsevat tukea tällä alalla. Scrumin skaalautuminen yksittäisten tiimien ulkopuolelle edellyttää kuitenkin erilaista lähestymistapaa. Scrum of Scrum -tekniikka (SoS-teknologia).

 

Lähde: RFC-ammattilaiset

 

Viestintä on ketterässä maailmassa kaiken a ja o, ja se on avain menestykseen. Viestintäkanavat voivat nopeasti kärsiä, mitä suurempi tiimi on. Tieto saapuu väärin tai ei ollenkaan. Ennemmin tai myöhemmin tämä vaikuttaa myös luottamukseen tiimiä kohtaan, läheisyys puuttuu ja yhteisen tavoitteen tavoittelu muuttuu haastavammaksi.

Tavoitteena on kehittää tiimiä siten, että kaikki esteet poistetaan (Scrum Master) ja se on vuonna Virtaus toimii. Teoriassa “täydellinen tiimi”, jonka suorituskyky olisi optimaalinen Hackmanin ja Vidmarin tutkimus 4,6 henkilöä. Liian pienet ryhmät eivät välttämättä riitä ongelman ratkaisemiseen. Liian suurissa tiimeissä puolestaan kärsivät henkilökohtaiset suhteet ja ketteryys suhteessa asiakkaan toimintakykyyn ja etuihin.

Joissakin tapauksissa se edellyttää tiimin jakamista. Mutta varo, tässä on otettava huomioon joitakin asioita. Puututte jo vakiintuneeseen järjestelmään. Tiimien välinen osaaminen on jaettava tasapainoisesti, toimivia rajapintoja on määriteltävä uudelleen ja tehtäviä jaettava tai määriteltävä uudelleen. Odottamattomat riippuvuudet ja uudet pullonkaulat voivat viivästyttää koko prosessia. Tässäkin tapauksessa on tärkeää kommunikoida avoimesti ja antaa tiimille aikaa ja tilaa. Kärsivällisyys ja sopeutuminen oikeissa paikoissa on myös erittäin tärkeää.

Scrum-of-Scrums -tekniikka edellyttää koordinointia, kun muodostetaan useita tiimejä. Seuraavassa kaaviossa esitetään yksi mahdollisuus:

Lähde: Atlassian

Pääasiallinen tuoteomistaja: Pääasiallinen tuoteomistaja on vastuussa tuotteen yleisestä visiosta. Hän priorisoi tuotteen backlogin ja toimii rajapintana ja suukappaleena asiakkaalle.

Scrum of Scrums -mestari: Hän edistää jatkuvasti Scrum of Scrumsin tehokkuutta. Hän keskittyy muille tiimeille näkyviin edistysaskeliin ja esteisiin, antaa tiimille valtuudet ja tukee heitä tehtäviensä suorittamisessa. Hän myös Palveleva johtaja kutsutaan.

Tiimin jäsenet nimeävät yhden henkilön, joka osallistuu Scrum of Scrums -kokoukseen Scrum-tiimin puolesta. Riippuen siitä, mihin projektissa keskitytään, tiimi voi aina nimetä eri edustajan. Pääsääntöisesti nimetään henkilö, joka on lähinnä aihetta. Jos painopiste on käyttäjäkokemuksessa, tulisi lähettää edustaja, joka tuntee sen. Jos painopiste on testauksessa, edustajan tulisi tulla testauksen alueelta. Joissakin tapauksissa, jos SOS-tiimistä tulee liian pieni, voi olla suositeltavaa, että kokoukseen osallistuu kaksi edustajaa tiimiä kohden. Usein Scrum Master on tällöin tiimin nimeämän henkilön mukana. Jos Scrum of Scrum -palaverien työskentelyä koordinoidaan ylemmän tason palaverissa, sitä kutsutaan Scrum of Scrum -palaveriksi.

Taajuus ja aikataulu** Scrum of Scrum -kokousten

Tiimi määrittää Scrum of Scrum -palavereiden tiheyden. Yksinkertaisuuden vuoksi pitäydymme Scrum of Scrum -palaverin ohjeissa, jotka pidetään päivittäin ja kestävät yleensä enintään 15 minuuttia..

Ryhmien koosta ja lukumäärästä riippuen nämä kokoukset ovat kuitenkin usein pidempiä ja niitä ei pidetä yhtä usein. Esimerkiksi 2-3 kertaa viikossa. Toisin kuin päivittäisessä palaverissa, Scrum of Scrum -palaverissa esiin tulevat ongelmat ratkaistaan suoraan, jos mahdollista, tai ainakin niihin puututaan. Tässä palaverissa esiin tulevat ongelmat ovat hyvin merkittäviä ongelmia, ja ne voivat nopeasti vaikuttaa yli 100 henkilöön.

Kokouksen esityslista

Lähde: Unsplash

Hyvä esityslista Scrum of Scrums -palaverissa on esityslista Päivittäiset Scrumit hyvin samankaltainen. Koska Scrum of Scrum -palaveria ei käytännössä pidetä joka päivä ja koska jokainen henkilö edustaa koko tiimiään palaverissa, kysymyksiin vastataan hieman eri tavalla:

• Mitä tiimisi on saavuttanut sen jälkeen, kun näimme viimeksi?
• Mitä tiimisi on tehnyt seuraavaan kokoukseen mennessä?
• Onko olemassa esteitä, jotka vaikeuttavat ryhmän työtä?
• Voisiko jokin, mitä joukkueesi tekee, haitata toisen joukkueen toimintaa?

Viimeinen kysymys koskee pitkälti prosessia ja sen mahdollista vaikutusta muihin joukkueisiin. Tämän kysymyksen käsittely voi olla erittäin hyödyllistä. Siinä pohditaan useita skenaarioita etukäteen sujuvan yhteistyön luomiseksi. Tässä siiloajattelu käytännössä murretaan. Vastaus viimeiseen kysymykseen on erityisen tärkeä, koska on ehdottoman tärkeää, että edustajat välittävät tulokset omille tiimeilleen.

Kysymyksiin vastaamisen lisäksi kokouksessa on myös aikaa ja tilaa keskustella ja käsitellä aiemmin esiin tulleita kysymyksiä, ongelmia tai haasteita. Kokouksessa dokumentoidaan edistyminen ja luodaan yhteinen näkemys. Ratkaisut ja toimet kirjataan, jotta niitä voidaan seurata.

Jotta kokouksessa pysyttäisiin asiallisella ja neutraalilla tasolla, keskusteluissa ei mainita nimiä. Aiheiden pituus on myös selkeästi erotettu aiheiden tärkeydestä. Tavoitteena on luoda objektiivinen näkemys metatasolta, mutta silti vaihtaa näkökulmia.

Päätelmä

Scrum of Scrum on siis hyvä tapa skaalautua, jos käytät jo Scrumia ja haluat siirtyä kohti yrityksen ketteryyttä. Jos haluat lisätietoja Scrum Master Performance Evaluation -arvioinnista, tutustu myös osoitteeseen tämä artikkeli an.

Scrum of Scrums ja SAFe – kaksi erilaista konseptia

Scrum of Scrum, SAFe ja LeSS ovat kaikki erilaisia ketterän skaalautumisen kehyksiä, ja niissä on erilaisia lähestymistapoja johtajuuden toteuttamiseen ja etenemissuunnitelman laatimiseen. Jos haluat oppia lisää muista konsepteista, suosittelen lukemaan blogikirjoituksemme aiheesta SAFe ja LeSS lukea.