Jos useimmilta johtajilta kysytään "psykologisesta turvallisuudesta" tai "visiosta" (lue lisää: Psykologinen turvallisuus) ketteristä ohjelmistokehitystiimeistään, he ovat samaa mieltä siitä, että nämä asiat ovat tärkeitä, mutta... Kun asiakas ilmoittaa kiireestä tai määräaika lähestyy, kaikki nämä "pehmeämmät" muuttujat jäävät yleensä taka-alalle. Johtajat ovat ensisijaisesti huolissaan siitä, että heidän ketterä tiiminsä tuottaa ketterästi toimivan toimituksen ennustettavasti.

Jos katsot Echometer-blogiamme (blogiimme), tiedät, että sisällöllämme on tapana keskittyä tiimien ja organisaatioiden pehmeiden taitojen parantamiseen. Päätöksentekijät aliarvioivat usein näitä taitoja. Mutta eivät Scrum Masterit ja Agile-valmentajat.

Mielestäni Scrum Masterit ja Agile-valmentajat aliarvioivat jälleen kerran keskittymistä toimitusvirran parantamiseen – periaatteessa siihen, mitä johtajat haluavat. Tämänpäiväisessä postauksessa kuvaan yksinkertaisen tekniikan, jolla voit lisätä merkittävästi todennäköisyyttä toimittaa aikataulussa ja budjetissa yhä uudelleen ja uudelleen.

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-valmentajat uskovat, että nopeuden jne. mittaaminen riippuu tehtävien tai työtehtävien "oikeasta mitoituksesta", jossa kaikki työtehtävät ovat suunnilleen samankokoisia. Vasta tällöin tarinapisteet (joita tarvitaan nopeuden mittaamiseen) ovat käyttökelpoisia nopeuden mittaamiseen, koska ne näyttävät enemmän vertailukelpoiselta 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 seuraavat toimet tullaksesi ennakoitavaksi: Seuraa "uusien aloitettujen tehtävien" määrää verrattuna "suoritettujen tehtävien" määrään. Näiden kahden pitäisi olla tasapainossa. Toisin sanoen tehtävien aloitus- ja lopetusasteiden pitäisi olla mahdollisimman lähellä toisiaan, mieluiten jopa 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 aloittamaasi tehtävää kohden on myös suoritettu tehtävä, pystyt paremmin purkamaan muutaman keskittyneen päivittäisen tehtävän. Kokonaissuorituksesi on ennustettavampi – ja tiimisi on tyytyväisempi, koska esimiehesi ja asiakkaasi ovat tyytyväisempiä.

Joitakin terveen ketterän Agile-toimitusvirran "positiivisia oireita".

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ä. Mikä on nyt paras tapa aloittaa käytännössä? Luomalla tiimissä tietoisuutta ja muutosvalmiutta. Parhaassa tapauksessa itsereflektion 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 "ketterän toimituksen" retrospektiivinen mallimme (lue lisää: 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: