Kuuntele tämän artikkelin ääniversio

Työskenteletpä pienessä yrityksessä tai uuden tuotteen parissa suuressa yrityksessä, olet todennäköisesti tulossa siihen pisteeseen, kun sinulla on liikaa ihmisiä yhdessä joukkueessa. Merkkien tunnistaminen varhaisessa vaiheessa säästää sinua pääsemästä joukkueen tehottomimpaan vaiheeseen.

Jokainen tuote on erilainen, samoin heidän kanssaan työskentelevät tiimit. Tiimin jakaminen edellyttää siis myös sinun tekevän joitakin olosuhteita vastaavia päätöksiä. Joitakin huomioitavia asioita ovat:

• Kuinka säilyttää taitotiedon eheys, kun joukkuetoverit eivät enää toimi yhdessä
• Pitäisikö sinun jakaa toiminnot (esim. Käyttöliittymä ja taustaryhmät)?
• Pitäisikö uusilla joukkueilla olla erilliset backlogit?
• Pitäisikö tuotehallintaryhmän kasvaa vastaavasti?

Milloin sinun pitäisi aloittaa toisen joukkueen luominen?

Ilmeisin osoitus alkaa ajatella tiimin jakamista tai uuden joukkueen lisäämistä on, kun budjettisi kasvaa. Tämä voi tapahtua uudella käynnistyskierroksella tai tuotteesi uusilla tavoitteilla yrityksessä. Jos budjetin lisäys on niin merkittävä, että joukkueesi kasvaa 3x tai enemmän, ei ole mitään syytä, että joudut jakamaan nykyisen joukkueesi jakamaan taitotietoa. Päätöksistä ei kuitenkaan tule niin selkeitä, kun budjetin lisäys on asteittaista ja lopulta lisätään muutama uusi henkilö luetteloon. Jos sanot esimerkiksi, että aiot kasvattaa joukkueesi 7: stä 11: een, vaatiiko tämä jakoa? Ketterä mainostaa pieniä joukkueita, mutta myös yksilöitä ja vuorovaikutusta prosessien ja työkalujen suhteen. Kahden tai useamman tiimin omistaminen luo väistämättä enemmän prosesseja voidakseen toimia synkronoidusti.

Mitä asiantuntijat sanovat?

Amazonin perustaja Jeff Bezos on käyttänyt kahden pizzan sääntö sekä kokouksiin että ryhmille. Tämä tarkoittaa, että jokaisella pitäisi olla vain niin monta ihmistä kuin kaksi pizzaa voi syödä lounaan aikana.

Scrum-opas ehdottaa, että sinulla olisi 3-9 joukkueen jäsentä, jotka tosiasiallisesti toteuttavat sprinttilauskannan. Tämä tarkoittaa, että et sisältäisi tuotteen omistajaa tai scrum masteria, ellei kumpikaan heistä toteuta sprint-tilauskantaa.

Näillä numeroilla näyttää olevan järkeä, mutta sen takana on myös matematiikkaa. Jos ajattelet joukkuetta, jokainen henkilö on kuin solmu ja he yhdistävät yhteyden muihin solmuihin. Nämä ovat joukkuetovereiden välisiä ihmissuhteita. He voivat olla ystävällisiä, kilpailukykyisiä, säälittäviä tai huolehtivia. Riippumatta kahden ihmisen välisestä suhteesta, se on silti linkki, joka vaatii jokaiselta henkistä kapasiteettia. Joukkueen kasvaessa näiden linkkien määrä ei kasva lineaarisesti. Solmujen välisten linkkien kaava on (n (n-1) / 2 ). Tässä on linkkien kasvukaavio:

Kaavio havainnollistaa matemaattisesti selvästi, miksi joukkueet toimivat tehokkaimmin, kun ne eivät ole liian suuria. Jos otamme Scrum Guide -operaation ehdottamat 3–9 tiimin jäsentä, päädytään 3–36 linkkiin. Jos kasvaisimme 15 ihmiseen, meillä olisi yli 100 linkkiä. Joukkue voi toimia tehokkaasti vain, jos heidän tehtävänsä on määritelty hyvin tarkasti ja harvoin päällekkäin tai jos on epävirallisia alaryhmiä. Kumpikaan asia ei ole toivottava, kun työskentelet ketterien periaatteiden pohjalta.

Merkit siitä, että joukkue on tulossa liian isoksi

Päivittäinen Scrum

Joskus kutsutaan päivittäiseksi standupiksi, päivittäinen seuranta on koko joukkueen kokoontuminen keskustelemaan sprintin edistymisestä ja esteistä. Scrum Guide ehdottaa, että nämä ajoitetaan 15 minuuttiin, ja se on hyvä lakmuskoe joukkueen koolle. Jos alat huomata, että joukkueesi ylittää 15 minuutin pylvään, se voi osoittaa yhden kahdesta asiasta:

• Päivittäiset selvitykset eivät ole tehokkaita. Ihmiset menevät liian moniin yksityiskohtiin. Tai ei ole selkeää puhujärjestystä, ja joukkuetovereiden puhuminen vie aikaa. Ehkä tuotteen omistaja tai scrum master käyttää päivittäistä scrumia mahdollisuutena tarjota erilaisia ​​päivityksiä, jotka eivät liity sprinttiin.
• Joukkue on liian iso. Jos päivittäiset seurannat ovat tehokkaita, mutta ylität vielä 15 minuuttia, sinulla saattaa olla yksinkertaisesti liian paljon ihmisiä joukkueessa. Sinun tulisi myös alkaa huomata, että ihmiset menettävät kiinnostuksensa, koska tietyn tiedon määrä on rajoitettu. Jos liian monta ihmistä toimittaa päivityksiä, on vaikea seurata kaikkien etenemistä ja ymmärtää tiimin tila . Tämä saa ihmiset kääntymään sisäänpäin ja pohtimaan vain edistymistään sen sijaan, että etsimään mahdollisuuksia auttaa muita.

Hoito ja sprintin suunnittelu

Sekä hoito että sprintin suunnittelu ovat aktiviteetteja, jotka liittyvät käyttäjien tarinoiden hajottamiseen ja niiden toimitusajan tai koon arvioimiseen. Vaikka useampi ihminen voi auttaa tiimiä tekemään parempia päätöksiä, liian suuri määrä ihmisiä saattaa ajaa joukkueen umpikujaan. Aina on olemassa erilaisia ​​tapoja suorittaa sama tehtävä, ja argumenttien määrä kummallakin puolella kasvaa ihmisten määrän kanssa ryhmässä.

Kuten päivittäisessä seurannassa, älä sekoita tehotonta suunnittelutilaisuutta liian suuren joukkueen kanssa. Viime kädessä scrum-mestarin tehtävä on tehdä scrum-seremonioista tehokkaita ja vaikuttavia.

Retrospektiivinen

Takautuvasti tiimin jäsenet voivat ratkaista kaikki argumentit tai ristiriidat ja keksiä tapoja parantaa työprosessiaan. Retrospektiivit opettavat meille kompromissitaidetta, koska se saa meidät etsimään yhteistä kantaa eri osapuolten välillä. Joukkue on yhtä voimakas kuin sen jäsenet ovat valmiita tekemään kompromisseja erimielisyydestään.

Kuten sprintin suunnittelussa, liian monet tiimin jäsenet luovat liikaa linkkejä, jotka kaikki ovat mahdollisia ristiriitoja. Aloita huomaaminen, jos löydät vähemmän ja vähemmän yhteistä kieltä retrospektiivien aikana. Se voi olla merkki siitä, että joukkue on liian iso ja hyötyisi jakautumisesta.

Kuinka jakaa joukkue

Joukkueen jakaminen on naamaltaan suhteellisen helppo tehtävä. Jaa ryhmän jäsenet kahteen ryhmään, varmista, että jokaisella on samanlaiset kokeneet ihmiset, ja määritä uusien joukkueiden tavoitteet. Harkittavaa on kuitenkin muutama asia, joilla voi olla suuri vaikutus uusien joukkueiden tulevaan menestykseen.

Joukkueen moraali

Luultavasti yksi tärkeimmistä mielessä pidettävistä asioista on joukkueen moraali. Päivän lopussa tiimissä olevien ihmisten on työskenneltävä uudessa kokoonpanossa. Jos joukkue on kypsä ketterien periaatteiden suhteen, heidän pitäisi pystyä jakamaan itse. Tämä on halutuin tulos, koska tiimin jäsenet tietävät parhaiten sisäiset suhteensa - kuka toimii parhaiten kenen kanssa ja kuka voisi hyötyä erillisissä tiimeissä olemisesta.

Monitoimiset joukkueet

Scrum edistää monitoimiryhmiä 'kaikilla taidoilla tiiminä, joka on välttämätöntä tuotteen lisäyksen luomiseksi'. Tämä pätee, kun skaalataan kahteen tai useampaan joukkueeseen. Monille kehittäjille, etenkin jos he ovat uusia ketterille, on luonnollinen taipumus ajatella teknisten linjojen rinnalla. Esimerkiksi joukkueet haluavat usein jakautua taustaryhmiksi. Tämä saattaa olla järkevää joissakin harvoissa tilanteissa, mutta a tuotepäällikkö , sinun tulisi neuvoa sitä suurimman osan ajasta. Etuosaajia täynnä oleva tiimi ei kykene toimittamaan tuotekohtaista lisäystä itse ja alkaa luonnollisesti ajatella enemmän teknistä kapasiteettia, mikä yhdistää heidät. Sen sijaan heidän tulisi keskittyä asiakkaaseen ja tarpeiden tyydyttämiseen.

Toinen mielenkiintoinen näkökohta on ei-kehitystehtävät ryhmässä. Eri tilanteissa joukkueeseen voi kuulua suunnittelija, yritysanalyytikko tai laadunvalvonta-asiantuntija. Kun olet jakanut joukkueen, varsinkin jos et palkkaa liikaa uusia ihmisiä, syntyy ongelma siitä, mitä tehdä näille rooleille. Pitäisikö heidän jakaa aikansa joukkueiden kesken? Pitäisikö sinun palkata uusia ihmisiä, jotka olisivat omistautuneet vain yhdelle joukkueelle? Pitäisikö heidän työskennellä kehitystiimien kanssa vai kuulua tuotetiimiin?

Tätä varten ei todellakaan ole hyviä yksittäisiä neuvoja, koska jokainen tuote on niin erilainen. Nämä päätökset tehdään parhaiten yhdessä tiimin kanssa pitäen mielessä, että joudut ehkä korjaamaan matkan varrella.

Pitäisikö joukkueilla olla erilliset lokit?

Jos joukkue on jaettu, on luonnollista, onko heidän työskenneltävä saman tilauskannan parissa vai onko heillä erillisiä. Voimme katsoa Skaalattu ketterä kehys opastusta varten.

[sähköposti suojattu]

[sähköposti suojattu] on Scrum-oppaan luojan metodologia. [sähköposti suojattu] ei ole kovin määräävä eikä siinä hahmotella nimenomaisesti, miten tuoterokoja käsitellään. Se panee kuitenkin merkille kaksi asiaa:

• Tiimitasoinen prosessi on sama kuin Scrum-oppaassa.
• Tuotteen omistajat muodostavat tuotteen omistajatiimin, jossa he muodostavat yhden yhtenäisen tilauskannan. Tämä tehdään päällekkäisen työn välttämiseksi ja näkyvyyden lisäämiseksi yrityksessä. Samaan aikaan joukkueilla on erilliset lokit, jotka syöttävät tuotteita yhtenäistetystä lokista.

Joten pohjimmiltaan, [sähköposti suojattu] kuvata uusia joukkueita omilla tuottajaorganisaatioillaan ja backlogeillaan. Se vain lisää joitain lisärakenteita työryhmien välisen työn koordinoimiseksi. [sähköposti suojattu] toimii parhaiten useiden, kymmenien tai satojen joukkueiden kanssa, mutta se voi tarjota arvokkaita oivalluksia, vaikka olisitkin kahden tiimin kanssa.

Suuri mittakaava (LeSS)

Vähemmän edistää mielenkiintoista lähestymistapaa tuotekannassa. LeSS: ssä tuotteen omistaja työskentelee kahdesta kahdeksaan ryhmään. Saattaa tuntua mahdottomalta, että yksi tuottajaorganisaatio työskentelee niin monien joukkueiden kanssa. LeSS: n filosofia on se, että tuottajaorganisaatio toimii abstraktilla tasolla ja siirtää tuoteviraston tuotteiden viimeistelyvastuut tiimeille. Tällöin rajat ylittävien kehitystiimien tulisi sisältää myös tietoa liiketoiminta-alueista voidakseen toimittaa tuotekohtaisen lisäyksen. LeSS: ssä on vain yksi viivästys.

Kuinka pysyä ajan tasalla

Tuotepäällikölle useat tiimit tarkoittavat enemmän työtä edistymisen seuraamiseksi ja kyselyihin vastaamiseksi.

Priorisoi kokouksia

Jos olit läsnä yhden tiimin päivittäisissä keskusteluissa, tämän tapan jatkaminen on todennäköisesti tuottamatonta. Harkitse päivittäisiä keskusteluja mahdollisuutena päästä mukaan saadaksesi pulssi tiimeistä ja muistuta heitä siitä, että olet käytettävissä keskusteluihin.

Läsnäolosi sprintin suunnitteluistunnoissa riippuu joukkueiden kypsyydestä. Jos joukkueissa on paljon tuoreita kasvoja tai he eivät ole työskennelleet Agilen kanssa pitkään aikaan, sinun on opastettava puoleltasi. Vaikka olisitkin luottavainen antaessasi tiimin suunnitella ilman läsnäoloa, varmista, että sinulla on mahdollisuus palata sisään tai keskustella tiimin kanssa suunnittelun aikana, jos kysyttävää ilmenee.

Sprint-arvostelujen on oltava ensisijainen prioriteettisi, ja kaikkiin niihin tulisi osallistua. Sprint-arvostelut ovat mahdollisuus saada omakohtaista palautetta kaikilta nykyisiltä sidosryhmiltä ja tiimiltä itseltään. Se on aika, jolloin oletukset vahvistetaan, eikä sitä pidä hukata.

Aktivoi enemmän Scrum Mastersin kanssa

Vaikka saatat vähentää sitoutumistasi joihinkin scrum-seremonioihin, sinun tulisi kaksinkertaistaa kumppanuutesi scrum-mestarin kanssa. Joukkueen jakautumisen jälkeen saattaa olla enemmän kuin yksi, jolloin sinun on tehtävä tiivistä yhteistyötä kaikkien kanssa.

Varmista, että voit luottaa heihin antamaan rehellisen kuvan joukkueen edistymisestä ja sprinttien aikana esiin tulevista ongelmista. Nämä suhteet antavat sinun pysyä ajan tasalla ilman tarvetta osallistua kaikkiin scrum-seremonioihin.

Esittele Scrum of Scrums

Joskus kutsutaan meta scrumiksi, scrum of scrums on uusi seremonia, joka esitellään tyypillisesti scrum-prosessien mittakaavassa. Se on kopio päivittäisestä rytmistä korkeammalla tasolla. Jokainen tiimi nimittää suurlähettilään, joka kokoontuu päivittäin keskustelujen keskustelussa keskustelemaan edistymisestä ja esteistä. Tätä seremonia käytetään myös korostamaan joukkueiden välisiä teknisiä kysymyksiä, jotka saattavat tarvita ratkaisua.

Harkitse tuotetiimin laajentamista

Jos scrum-asetuksesi edellyttää, että tuotepäällikkö on aktiivisesti yhteydessä tiimiin, harkitse lisää ihmisiä tuotepuolelle. On olemassa muutama tapa lähestyä tätä.

Junior-tuotepäälliköt. Yksi tapa on ottaa itsellesi strategisempi rooli ja lisätä nuorempia tuotepäälliköitä käsittelemään joitain päivittäisiä töitä. He voivat suorittaa joitain tehtäviä, kuten laadunvarmistus (QA), kirjoittaa spesifikaatioita käyttäjäkertomuksiin tai luoda korkean tason mallikuvia uusille ominaisuuksille.

Liiketoiminta-analyytikot. Toinen tapa on saada yksi tai useampi yritysanalyytikko työskentelemään tiimeissä tai niiden rinnalla. Tuotepäällikkö voi työskennellä yritysanalyytikoiden kanssa tunnistaakseen tuoteoletukset ja antaa sitten analyytikoiden löytää tapoja vahvistaa ne joko tutkimuksen tai uusien ominaisuuksien avulla.

Johtopäätös

Kun joukkueesi kasvaa, olet todennäköisesti alkanut huomata joitain merkkejä siitä, että se on tulossa liian suureksi, erityisesti:

• Päivittäinen kouristus. Jos ylität 15 minuutin ajanjakson päivittäisissä pommituksissa ja huomaat, että ihmiset alkavat menettää kiinnostuksensa.
• Sprintin suunnittelu. Jos päätät umpikujaan sprinttisuunnittelun aikana yhä useammin.
• Retrospektiivinen. Jos alat huomata, että kompromissien tekeminen on vaikeampi takautuvasti.

Kaikki nämä viittaavat siihen, että sinun on ehkä jaettava joukkue. Tiimin jakaminen on näennäisesti helppo tehtävä, mutta sillä on myös pysyviä seurauksia, ja jokaisella tuotepäälliköllä on muutama asia, joka on otettava huomioon tehdessään:

• Joukkueen moraali. Ihannetapauksessa sinun pitäisi antaa tiimin päättää, kuinka he haluavat jakautua, jotta romutettujen hyvien työsuhteiden määrä olisi mahdollisimman pieni.
• Monitoimiryhmät. Joukkueilla tulisi olla kaikki tarvittavat taidot tuotteen lisäyksen luomiseen.
• Tuotteiden viivästyminen. Päätä, onko joukkueillasi erillinen vai yksi yhtenäinen tilaus.

Kahden tai useamman joukkueen seuraaminen edellyttää priorisointia. Tehokkaan tuotepäällikön tulisi suunnitella, kuinka he pysyvät ajan tasalla uusien tiimien kanssa:

• Priorisoi kokoukset. Ajattele, mitkä ketterät seremoniat ovat aikasi arvoisia ja mitkä voidaan jättää huomiotta.
• Ota yhteyttä scrum-mestareihin. Käytä scrum-mastereita tiimisi välityspalvelimina ja kerää heiltä tietoja.
• Laajenna tuotetiimi. Lisää ihmisiä työskentelemään kanssasi ja auta joko päivittäisissä toistuvissa tehtävissä tai suorita käyttäjätutkimuksia ja markkina-analyyseja.

Hyödyntämällä näitä ehdotuksia sinun pitäisi pystyä jakamaan puhdas tiimi. Jos joukkueesi kasvaa jatkuvasti ja lisäät lisää joukkueita tulevaisuudessa, sinun tulisi lukea siitä Skaalattu ketterä kehys , joka tarjoaa rakenteen ja prosessiehdotukset ketterälle mittakaavassa.

Perustietojen ymmärtäminen

Kuinka monta kehittäjää on scrum-tiimissä?

Scrum-oppaan mukaan kehitystiimin tulisi olla kolmesta yhdeksään ihmistä ja hänellä tulisi olla kaikki tarvittavat taidot tuotteiden lisäysten toimittamiseen. Kehittäjien määrä määräytyy yleensä tuotteen tarpeiden mukaan, ja se on yleensä 2-5 kehittäjää scrum-tiimissä.

Ketkä ovat scrum-tiimin jäseniä?

Scrum-tiimi on rajat ylittävä ja siihen kuuluu kaikki ihmiset, joita tarvitaan tuotteen lisäyksen toimittamiseen. Useimmilla scrum-tiimeillä on omistautunut tuotteen omistaja ja scrum master. Loput tiimistä voivat sisältää kehittäjiä, suunnittelijoita, testaajia tai analyytikkoja.

Mikä on hyvä scrum-tiimi?

Hyvä scrum-tiimi on monitoiminen, ja sillä on kaikki tarvittavat taidot tuotteen lisäyksen luomiseen. Sen tulisi sisältää kehittäjät, suunnittelijat, testaajat, analyytikot jne.

Mikä on suositeltu koko scrum-tiimille?

Scrum Guide suosittelee, että yhdestä joukkueesta kuuluu kolme tai yhdeksän tiimin jäsentä.