Agile Toimitusvirta: Toimita aina ajallaan 3 vaiheessa.

Jos useimmilta johtajilta kysytään “psykologisesta turvallisuudesta” tai “visiosta” (lisää aiheesta: Psykologinen turvallisuus ) ketterissä ohjelmistokehitystiimeissä, he myöntävät, 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 siirretään syrjään. Johtajat ovat enimmäkseen kiinnostuneita ketterän tiiminsä ennustettavasti toimivasta ketterästä toimitusvirrasta.

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

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 ajoissa ja budjetissa voidaan merkittävästi lisätä.

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ä Velocityn jne. validia mittausta varten on tärkeää tehtävien tai työkohteiden “oikea mitoitus”, jossa kaikki työkohteet ovat suunnilleen samankokoisia. Vain silloin Story Pointit (joita tarvitaan Velocityn mittaamiseen) ovat käyttökelpoisia Velocityn 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.

Tee siis näin, jotta sinusta tulee ennustettava: Valvo “uudelleen aloitettujen tehtävien” määrää verrattuna “valmistuneiden tehtävien” määrään. Näiden kahden pitäisi olla tasapainossa. Toisin sanoen tehtävien “sisäänmeno-” ja “ulosmenonopeuden” pitäisi olla mahdollisimman lähellä toisiaan, ihannetapauksessa jopa täsmälleen samat.

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 yksi valmis tehtävä, Daily-kokouksessa on helpompi poistaa muutaman keskittyneen tehtävän esteet. Suorituskykynne on kaiken kaikkiaan ennustettavampaa – ja tiimi on tyytyväisempi, koska esimiehenne ja asiakkaanne ovat tyytyväisempiä.

Joitakin “positiivisia oireita” terveestä ketterästä Agile Delivery -virrasta

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ä parhaiten alkuun? Luomalla tietoisuutta ja “muutosvalmiutta” tiimissä. Parhaassa tapauksessa itsetutkiskelun avulla.

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” -retrospektiivimallimme (lisää aiheesta: 26 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 arvata, terveysselvityksen viimeinen kohta (syyn tarkistaminen) viittaa jo mahdolliseen toimenpiteeseen, johonkin, jota voit kokeilla yhden tai kahden ketterän sprintin ajan nähdäksesi, voisiko se auttaa sinua: Keskeneräisten tehtävien määrän rajoittaminen.

Perustan luominen: Tiimityötä koskevien sopimusten laatiminen

Onko sinulla tunne, että tiimisi ei ole vielä valmis tällaiseen pohdintaan? Tässä tapauksessa sinun tulisi ensin pohtia “hyvää työtä” yleensä ja sitten asettaa joitain perussääntöjä, niin kutsuttuja työskentelysopimuksia. Seuraava työpajamalli voi auttaa sinua tässä. Voit suorittaa sen erityisenä retrospektiivinä projektin alussa tai ylimääräisenä työpajana.

Ensinnäkin sinun tulisi saada käsitys siitä, kuinka yksimielinen tiimisi implisiittisesti tuntee olevansa – katso tätä varten terveysselvityksen kohta. Sitten sinun tulisi tarkistaa tämä käytännössä muutamalla avoimella kysymyksellä. Jokaisen tiimin jäsenen on lopetettava lause (katso lisäkysymyksiä) mahdollisimman monella vastauksella, jotka hänelle tulevat mieleen:

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 tulisi 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ä toimitusvirta

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 hyvin tiivistetty myös “Agile Bites” -podcastissa, jota voin lämpimästi suositella (Podcastiin: Agile Bites). 

Pidä hauskaa tiimisi kehittämisessä!