Huono kiire kuriin ohjelmistokehityksessä

Ohjelmiston kehitystiimillä on aina akuutti aika- ja resurssipula. Pahimmillaan kiire nostaa kierroksia, luo kitkaa tiimin sisällä tai jopa luo olosuhteet väärille päätöksille ja tulehtuneelle ilmapiirille.

Syitä tähän on monia eikä ongelman ratkaisemiseen ole hopealuotia, vaan kokoelma erilaisia käytäntöjä joilla helpottaa tilannetta.

Ideaalitapauksessa ongelmat olisi ratkaistavissa antamalla tiimin käyttöön joko enemmän aikaa tai enemmän resursseja (eli tekeviä käsiä), mutta valitettavan usein kumpikaan vaihtoehto ei ole realistinen taloudellisista syistä. Lisäksi uusien osaajien tuominen projektiin monesti hidastaa kehitystä, koska tarvitaan asianmukainen opastus ja perehdytys.

Tiimin koon kasvattaminen yli tarpeen voi johtaa tilanteeseen, jossa tilanteen rauhoituttua tekijöille ei riitä mielekästä työtä. Kasvanut tiimin koko helposti johtaa myös kasvaneeseen hallintoon ja vastuiden sekamelskaan, jolloin haluttu lopputulos ei ole ideaali.

Mistä kiire ohjelmistokehityksessä syntyy?

Kiireen tuntua on kahdenlaista:

Hyvä kiire, jossa on tekemisen meininkiä – tällöin tehdään kovaa ja ajetaan kohti yhteistä päämäärää. Stressiä on, mutta myös onnistumisen tunnetta ja sopivasti palkintoa saavutetuista päämääristä.

Huono kiire, jossa stressitasot ja mielipaha nostaa rumaa päätään. Huono kiire johtuu huonosta johtamisesta, poukkoilevasta ja alati muuttuvista tavoitteista ja välinpitämättömyyden tunteesta.

Yhtenä yleisenä syytä kiireen tuntuun on prioriteettien muuttuminen – yleensä ylemmän tahon päätöksellä. Kesken kehityksen pitääkin saada tulille jokin toinen feature tai tärkeä bugikorjaus. Tämä johtuu joko:

Tuoteomistajuuden heikkoudesta: ei ole olemassa selkeää tuoteomistajaa tai tuoteomistaja on liiaksi sidosryhmien vietävissä.

Liian pitkistä kehityssykleistä: jos kehitystä tehdään viikon sykleissä, kaikki luultavasti ymmärtävät että sille seuraavalle tärkeälle kehityskohteelle olisi tilaa kenties jo seuraavalla viikolla. Sitä pitemmät syklit taas aiheuttavat närää ja tarvetta ohittelulle.

Huonosta varautumisesta: erityisesti bugikorjausten ollessa kyseessä kehittäjän “lainaaminen” bugikorjauksiin käytännössä pysäyttää kehityksen hetkeksi. Tähän auttaa pysyvän ns. korjaustiimin perustaminen, johon voidaan allokoida yksi kehittäjä viikoksi kerrallaan.

Puutteellisesta roolituksesta: tämä liittyy osittain edeltävään kohtaan, mutta bugiraportin tai ongelman ilmaantuessa pahimmillaan koko kehitystiimi pudottaa työrukkaset ja alkaa tutkia ongelman lähdettä. Parempi tapa on sopia, kuka ottaa vastuun kiireellisen ongelman selvittelystä – koko kehitystiimin ei välttämättä edes tarvitse tietää ongelmasta.

Miten kiire ja sen juurisyyt puretaan?

Oma suositukseni on kysyä suoraan tiimiltä, sekä virallisesti että epävirallisesti palautetta ja kehitysehdotuksia. Virallisesti osana retrospektejä, epävirallisesti kahvikeskusteluissa, 1-on-1 keskusteluissa ja lopulta anonyyminä palautteena. Kaikki kanavat palautteen antamiseen kannattaa olla käytössä.

Johtamista on lopulta helppo muuttaa, mutta siihen kannattaa myös osallistaa koko tiimi. Palautteen käsittely ja ideointi toimintatapojen muutokseen ovat hyvä lisä esimerkiksi tiimipäivien ohjelmaan. Tiimi on se, joka ensimmäisenä kärsii kiireestä, heitä kannattaa kuunnella ja osallistaa.