Scrumin ja tikettirumban yhdistäminen

Monelle Scrum-tiimille on varmasti tuttua, että kehityksen alla olevaan projektiin ei aina voida keskittyä sataprosenttisesti. Tiimille voi esimerkiksi kuulua jo toimitettujen sovellusten ylläpitovastuu.

Tällöin tiimin on kyettävä ujuttamaan varsinaisen projektin rinnalle virheenkorjaukset ja muutospyynnöt, joita usein käsitellään tikettimuodossa. Valitettavasti voi käydä niin, että eletään kahden prosessin ristivedossa – uusi kehitystyö noudattaa Scrumia ja tikettikorjaukset taas jotain ihan muuta prosessia. Olisiko tikettien pyörittelyä mahdollista ujuttaa mukaan Scrum-projektiin?

Yksi Scrumin parhaista puolista on kommunikaation edistäminen. Tiimi, Scrum Master ja Product Owner pääsevät samalle aaltopituudelle, kun sprintin tavoitteet puretaan auki sprintin aloituspalaverissa. Tiimin sisäistä kommunikaatiota taas palvelevat tarinoiden taskittaminen, pariohjelmointi ja jokapäiväiset pystärit. Lopuksi vielä varmistetaan demossa, että olivatko kaikki oikeasti ymmärtäneet asian samalla tavalla. Olisi enemmän kuin suotavaa saada myös virheenkorjaukset ja muutospyynnöt kulkemaan saman kommunikaatiota painottavan prosessin kautta.

PÄÄLLEKKÄISET PROSESSIT

Etenkin suuremmissa organisaatioissa Scrumin käyttöönotto voi olla kankeaa. Työ saattaa myös jokseenkin jäädä puoliväliin: tiimi toimii omassa kuplassaan Scrum-mallilla, mutta koko muu yritys noudattaa edelleen aiemmin käytössä olleita toimintamalleja. Tilanne olisi ihanteellinen, jos kaikki osapuolet tiedostaisivat mitä Scrum on, ja olisivat sitoutuneet noudattamaan yhteisiä pelisääntöjä. Nämä säännöt voisi kirjata ylös ja asettaa näkyvälle paikalle allekirjoitusten kera.

Ruohonjuuritasolta, Scrum-tiimistä käsin, voi käytännössä olla hyvin hankalaa vaikuttaa koko yrityksen laajuisiin prosesseihin. Omaan toimintaansa Scrum-tiimi sen sijaan voi vaikuttaa - esimerkiksi pitämällä kiinni pariohjelmoinnista.

Prosessien yhtenäistämisessä voisi myös auttaa kaikkien töiden kirjaaminen samaan paikkaan. Tarinat, virheraportit ja muutospyynnöt voitaisiin kaikki kirjata esimerkiksi tiketteinä samaan järjestelmään. Tämä yhtenäistäisi niiden käsittelyä heti alusta lähtien. Lisäksi Scrum-tiimin työtilanteen hahmottaminen olisi tiimin ulkopuolisille tahoille helpompaa, kun kaikki työtehtävät lisätietoineen olisivat nähtävillä samasta paikasta.

KUKA ON VASTUUSSA?

Isoissa järjestelmissä vaikeuksia saattaa aiheuttaa Product Ownerin rooli: virheenkorjaustikettejä voi tulla useilta eri vastuuhenkilöiltä, joten projektin PO:lla ei välttämättä ole valtuuksia eikä tietämystä edistää näiden tikettien käsittelyä. Voiko yhdellä projektilla olla monta Product Owneria? Vaikka tämä onnistuisikin, kaikkien Product Ownereiden saaminen samanaikaisesti samaan tilaan sprintin aloituspalaveria varten voi osoittautua ylivoimaiseksi.

Tarvittaisiin uusi välikerros: ”Middleware Product Owner,” MPO, kaaosta hallitseva koordinaattori. MPO toimisi projektin varsinaisena PO:na ja olisi sovellusvastaavien yhteyshenkilö. Jos sovellusvastaava haluaa jonkin virheenkorjauksen tiimille työn alle, hän ilmoittaa tästä MPO:lle. MPO siirtää työn tiimin backlogille. Hän myös huolehtii sovellusvastaavien avustamana, että uusi tarina tulee priorisoitua oikein.

TULIPALOT

Eteen voi tulla tilanteita, joihin pitää reagoida välittömästi. Näin voi käydä esimerkiksi silloin, kun asiakas kirjaa tuotantokäytössä olevasta sovelluksesta kiireellisen virhetiketin. Tällaisissa tilanteissa ei ole mitenkään mahdollista lykätä virheenkorjausta seuraavaan sprinttiin, vaan tiketti on otettava käsittelyyn saman tien, kesken sprintin.

Tulipaloja ei voi estää, mutta ne voidaan sammuttaa hallitusti. Sprintin käytettävissä olevasta työmäärästä voi varata osan kiireellisille töille. Näin ollen tiimille jää pelivaraa, eivätkä yllättäen ilmaantuvat lisätyöt edesauta koko sprintin epäonnistumista. Katso tähän liittyen Danielin blogikirjoitus “How Scrum teams can respond quickly to production issues”.

TISKIN ALTA TULEVAT TYÖT

Varsinkin pidemmän työuran tehneistä henkilöistä saattaa ajan kuluessa kehkeytyä korvaamattomia oman alueensa asiantuntijoita. Ongelmana tässä on se, että vastuu kohdistuu yksittäiselle henkilölle, ei tiimille. Tämä estää tehokkaasti tiedon leviämistä tiimin sisällä. Asiantuntija hukkuu hänelle henkilökohtaisesti osoitettuihin töihin, koska hän on ainoa, joka tietää asiasta mitään. Tämä taas johtaa siihen, ettei kyseisellä henkilöllä ole aikaa osallistua muiden tiiminjäsenten tekemisiin, joten hänen erikoistumisensa tietylle alueelle jatkuu entisestään.

Kaikkien sprintin aikana tehtävien töiden tulisi kulkea sama reitti, ennen kuin työt päätyvät toteutettavaksi. Näin ollen tehtävät osoitettaisiin koko tiimille, eikä niitä korvamerkittäisi yksittäisille henkilöille. Tietyn alueen asiantuntijan toki kannattaa olla toteutuksessa mukana, mutta tietämystä voisi tehokkaasti jakaa esimerkiksi pariohjelmoinnin avulla.

YHTEENVETO

Projektiryhmän kaikkien töiden ottaminen mukaan sprintiin ja niiden käsittely Scrumin ohjesääntöjen mukaisesti tasapainottaisi, tehostaisi ja selkiyttäisi työskentelyä. Tiimin työtilanteen seuraaminen olisi tällöin helpompaa myös projektiryhmän ulkopuolisille henkilöille. Prosessien yhdenmukaistamiseen liittyy kuitenkin paljon haasteita. Vaikka Scrum-tiimi voi itsenäisesti sopia tiimin sisäisistä työskentelytavoista, kokonaisvaltaiseen muutokseen tarvitaan lisäksi myös tiimin ulkopuolisten tahojen sitoutumista ja työpanosta.