Agile Toimitusvirta: Toimita aina ajallaan 3 vaiheessa.

Jos useimmilta johtajilta kysytään “psykologisesta turvallisuudesta” tai “visiosta” (lisää tästä: Psykologinen turvallisuus ) ketterissä ohjelmistokehitystiimeissään, he ovat yhtä mieltä siitä, että nämä asiat ovat tärkeitä, mutta… Kun asiakas ilmoittaa kiireellisyydestä tai määräaika lähestyy, kaikki nämä “pehmeämmät” muuttujat tyypillisesti sysätään syrjään. Johtajat ovat pääasiassa kiinnostuneita ketterän tiiminsä ennustettavasti toimivasta ketterästä toimitusvirrasta.

Jos katsot Echometer-blogiamme ( blogiimme ) olet lukenut, tiedät, että sisältömme keskittyy enemmän tiimien ja organisaatioiden “pehmeiden taitojen” parantamiseen. Päätöksentekijät usein aliarvioivat näitä. Mutta eivät Scrum Masterit ja Agile Coachit.

Mitä Scrum Masterit ja Agile Coachit mielestäni puolestaan aliarvioivat, on keskittyminen toimitusvirran parantamiseen - pohjimmiltaan se, mitä johtajat haluavat. Tässä artikkelissa kuvaan yksinkertaisen tekniikan, jolla todennäköisyyttä toimittaa toistuvasti ajallaan ja budjetissa voidaan lisätä merkittävästi.

Ensimmäinen askel suhteessa Agile-toimitusvirtaan

Tarkoitan Agile-tehtävien toimitusvirran seurantaa. Jos teet vain muutaman asian oikein, pystyt toimittamaan paljon ennustettavampia tuloksia. Jopa sykliaikojen hajontakuviot tai Monte Carlo -simulaatiosi projektiarvioiden laskemiseksi saattavat vihdoin osoittaa päteviä ennusteita sen sijaan, että ne olisivat täysin pielessä (lue lisää: 9 Agile Mittarit päätöksentekijöille ).

Ensimmäinen torjuttava oire on se, että on tehtäviä, jotka vievät vain muutaman päivän “aikataulutetusta” “valmistuneeseen”, ja sitten on tehtäviä, jotka vievät yli kuukauden. Tämän torjumiseksi kannattaa varmistaa, että tehtävä sisältää aina pienimmän mahdollisen toimitettavan version halutusta ominaisuudesta. Ilman kelloja ja pillejä, jotka eivät ole välttämättömiä asiakkaan ydinpyynnön kannalta. Periaatteessa MVT, Minimum Viable Task. Tämä ei tarkoita, että se tekee jokaisesta tehtävästä pienen. Mutta sen pitäisi auttaa sinua pääsemään vaiheeseen, jossa tehtäviin kuluu kuukausien sijasta korkeintaan muutama viikko.

Toinen vaihe suhteessa Agile-toimitusvirtaasi: WIP nopeuden sijasta.

Monet Scrum Masterit tai Kanban Coachit uskovat, että nopeuden jne. validia mittausta varten on tärkeää tehtävien tai työkohteiden “oikea mitoitus”, jossa kaikki työkohteet ovat suunnilleen samankokoisia. Vasta sitten tarinapisteet (joita tarvitaan nopeuden mittaamiseen) ovat käyttökelpoisia nopeuden mittaamiseen, koska ne vaikuttavat enemmän verrattavalta aikayksiköltä. 

Tämä on kuitenkin väärin: tehtävien ei tarvitse edes olla samankokoisia. Sitä ei pidä olettaa, koska Story Point -arvioita on vain liian vaikea valvoa. Ainoa asia, jota voit hallita, on se, kuinka monta uutta tehtävää aloitat.

Jotta olisit ennustettavissa, toimi siis näin: Valvo “uusien tehtävien aloittamisen” nopeutta verrattuna “valmistuneiden tehtävien” nopeuteen. Näiden kahden pitäisi olla tasapainossa. Toisin sanoen tehtävien “sisäänmeno”- ja “ulostulonopeuden” pitäisi olla mahdollisimman lähellä toisiaan, ihannetapauksessa jopa samoja.

Esimerkki: Ohjelmistokehitystiimissä on tyypillistä, että heti kun tehtävä on estynyt, aloitetaan uusi työkohde. Tämä johtaa siihen, että monet tehtävät ovat avoinna mutta keskeneräisinä, mikä tekee niiden kaikkien vapauttamisesta paljon monimutkaisempaa. 

Jos sen sijaan varmistat, että jokaista aloitettua tehtävää kohden on myös valmis tehtävä, päivittäisessä kokouksessa on helpompi poistaa muutamien keskeisten tehtävien esteitä. Suorituskykynne on kokonaisuudessaan ennustettavampaa - ja tiimi on tyytyväisempi, koska esimiehenne ja asiakkaanne ovat tyytyväisempiä.

Joitakin “positiivisia oireita” terveestä ketterästä Agile-toimitusvirrasta

Käytännössä tämä johtaisi seuraaviin käyttäytymistapoihin:

• • Emme aloita uusia tehtäviä, kun on vielä paljon asioita kesken. 

• • Keskitymme viimeistelemään aloittamamme ennen kuin aloitamme uusia asioita.

• • Tehtävien ikä ei koskaan ylitä muutamaa viikkoa.

• • Jos ei ole hyvää syytä, työskentelemme aina vanhimman tehtävän parissa.

WIP-rajat (work-in-progress) auttavat myös tässä, vaikka ne eivät useinkaan riitä. Kun tiimi oppii keskittymään tehtävien loppuunsaattamiseen sen sijaan, että se vain aloittaisi uusia tehtäviä, olette parempia kuin useimmat tiimit.

Jos käytät Agile-toimitusvirtaa oikein

Selkeiden odotusten luominen: Näin et voi silti hallita sitä, kestääkö jokin tehtävä kaksi vai kolme päivää. Mutta ainakin varmistat, että tiimisi ei työskentele niin monen tehtävän parissa, että 2-3 päivän tehtävät vievät lopulta kuukauden.

Kuinka paljon parempi tiimisi olisi, jos tietäisit, että periaatteessa kaikki toimitusvelvoitteet täytettäisiin muutamassa viikossa? Tämä edellyttää tietenkin, että toteutat kaikki edellä mainitut asiat: MVT:n asettaminen, tiukka WIP-raja ja sitoumus olla aloittamatta tehtäviä uudelleen ennen kuin toinen tehtävä on saatu valmiiksi.

Vaihe 3: Aloita Agile-toimitusvirran parantaminen.

Teoriassa tiedät, mitä tehdä. Miten sitten päästä käytännössä alkuun? Luomalla tietoisuutta ja “muutosvalmiutta” tiimissä. Parhaassa tapauksessa itsereflektion kautta.

Sinun on oltava avoin näiden lukujen suhteen ja tarkistettava ne säännöllisesti, jotta näet, onko aloitettujen ja suoritettujen tehtävien suhde tasapainossa. Jälkikäteen tarkastellessasi voisit mennä hieman syvemmälle ja pohtia, miksi luvut eivät olleet tasapainossa edellisellä jaksolla. 

Voin suositella mainitsemieni käyttäytymismallien käsittelyä ketterän retrospektiivityökalumme Echometer:n avulla retrospektiivissänne (lue lisää: 7 Takautuvat työkalut vertailussa ). Voisit jopa sisällyttää tämän osaksi työsopimuksiasi tai säännöllisiä Health Check-keskusteluja tietoisuuden lisäämiseksi esittämällä kysymyksiä säännöllisesti.

Seuraavat kysymykset ovat “agile Delivery” -retrospektiomallimme (lisää tästä: 22 hauskaa mallia ketteriin retrospektiiveihin ). Aloitamme muutamalla Health Check-väittämällä ja kysymme ryhmältä, ovatko he yleensä samaa vai eri mieltä. Sen jälkeen esitetään muutama avoin kysymys:

Agile Toimitus takautuvasti

Health Check Tuotteet

Milloin työskentelytapamme on johtanut epäoptimaaliseen työnkulkuun? (esim. epäselvät, epäasianmukaiset tai noudattamatta jätetyt ohjeet).

Kuten voit kuvitella, terveystarkastuksen viimeinen kohta (syyn tarkistaminen) jo viittaa mahdolliseen toimenpiteeseen, johonkin, jota voit kokeilla yhden tai kahden ketterän sprintin ajan nähdäksesi, voisiko se auttaa teitä: Tehtävien määrän rajoittaminen tilassa “Työ on meneillään”.

Perustan luominen: Tiimityötä koskevien sopimusten laatiminen

Onko sinusta, että tiimisi ei ole vielä valmis tällaiseen pohdintaan? Siinä tapauksessa sinun pitäisi ensin pohtia “hyvää työtä” yleisesti ja sitten laatia joitain perussääntöjä, niin kutsuttuja työskentelysopimuksia eli Working Agreements. Seuraava työpajamalli voi auttaa sinua tässä. Voit suorittaa sen erityisenä retrospektiovormina projektin alussa tai ylimääräisenä työpajana.

Ensinnäkin sinun pitäisi saada käsitys siitä, kuinka yksimielinen tiimisi on implisiittisesti - katso tätä varten terveystarkastuksen kohta. Sitten sinun pitäisi tarkistaa tämä käytännössä muutamilla avoimilla kysymyksillä. Jokaisen tiimin jäsenen on täytettävä lause (katso muita kysymyksiä) mahdollisimman monella mieleen tulevalla vastauksella:

Joukkueen sitoumukset Jälkikäteen

Health Check Tuotteet

Ristiriitojen käsittely: “Jos huomaan, että tiimissämme syntyy ristiriita, niin …”.

Kun olet kerännyt vastaukset, sinun pitäisi tietysti yrittää löytää malleja ja sopia konkreettisista sopimuksista siitä, miten haluat työskennellä yhdessä tulevaisuudessa - ainakin väliaikaisesti kokeiluna.

Mielenkiintoinen, luova vaihtoehto

Jos nämä retrospektiivimenetelmät tuntuvat teistä liian “kuivilta”, on olemassa toinen retrospektiivimenetelmä, joka keskittyy tiimisi tuotoksen laadun pohtimiseen ( Fun 54 Retrospektiiviset menetelmät löytyvät täältä. ): Kolme pientä porsasta” - retrospektiivi. Se on yksinkertainen vaihtoehto, jonka avulla voit alkaa pohtia ja parantaa suoritustasi. Se perustuu satuun kolmesta pikku possusta, jotka rakensivat taloja eri materiaaleista.

Johtopäätös – Ketterä toimitusprosessi

Aloititpa sitten miten tahansa, tärkeintä on, että aloitat alun perin. Joukkueet, jotka pitävät aktiivisesti silmällä Agile-toimitusvirtaansa, ovat parempia joukkueita.

Muuten, monet täältä löytämistäsi ideoista on myös hyvin tiivistetty podcastissa “Agile Bites”, jota voin lämpimästi suositella (Podcastiin: Agile Bites). 

Pidä hauskaa tiimisi kehittämisessä!