Jakso 4: kesälomailua vai työssä ahertamista?

Neljäs jakso. Neljännet suunnittelupäivät. Kesäloma häämötti jo nurkan takana, kun juhannusta edeltävällä viikolla kokoonnuimme Arcanumiin. Aava-auditorio, Luoma-tila ja ympäröivät pientilat tarjosivat toistaiseksi parhaat puitteet näille suunnittelupäiville – tilaa oli sopivasti, huoneet lähellä toisiaan ja sohvat ja säkkituolit vapauttivat mukavasti tunnelmaa.

Suunnittelupäivien väliin oli viime kerran toiveiden johdosta sijoitettu yksi tyhjä päivä, eli kokoonnuimme yhteen maanantaina ja keskiviikkona. Tiistaina osa porukoista tarkensi suunnitelmia, osa taas käytti ajan juoksevien asioiden hoitamiseen. Etukäteen mietitytti, katkaisisiko välipäivä suunnitteluun keskittymisen, mutta sehän toimi vallan mainiosti! Välipäivän aikana oli syntynyt oivalluksia, toimittajat oli keretty saada kiinni ja toisaalta sähköpostilaatikot tasattua ensimmäisen päivän jäljiltä. Päivien päätteeksi keskusteltiin, miten jatketaan ja valtaosa toivoi jatkamista tällä mallilla, eli näin jatketaan nyt ainakin seuraavalla kerralla.

Jälkimmäiseen päivään toi lisäjännitystä Arcanumilla aamutuimaan pidetty sähkökatkoharjoitus. Saimme tästä tiedon vasta viime tipassa, mutta sen verran aikaisin kuitenkin, että kerkesimme myöhäistää aloitusaikaa tunnilla. Tuli todettua myös käytännössä, että kyllä vaan sähkökatkon jälkeen ottaa aikansa, että tietotekniset laitteet saadaan jälleen nostettua ylös. Kiitos osallistujille kärsivällisyydestä ja avusta teknisten haasteiden keskellä! Tällä kertaa suunnittelussa nousi aiempaa vähemmän esille business ownereiden ratkaistavia haasteita. Edelleen ongelmana on tekemisen kasaantuminen tietyille käsipareille ja porukoille. DOT:n myötä tämä tekemisen kasaantuminen ja sen aiheuttavat asiat on saatu näkyviksi, mutta tällä kertaa konkretisoitui se, että ei DOT itsessään ongelmaa ratkaise, vaan meidän itsemme se on tehtävä. Alkavassa jaksossa kokeillaankin nyt esimerkiksi palvelualustat ja -järjestelmät -toiminnossa sitä, että käsitellään tähän porukkaan liittyvät kehityskokonaisuudet ensin toiminnon asiantuntijoiden kesken. Tarkoitus on saada jo siinä vaiheessa tunnistettua ne kehityskokonaisuudet, joiden välillä on tehtävä valintoja eli joiden kaikkien tekemiseen käsiparit eivät riitä. Ja vasta sitten viedään kehityskokonaisuudet priorisoitavaksi digipalveluiden johtoryhmässä. Toivottavasti näin saisimme vähitellen tekemisen määrää kohtuullistettua.

Suunnittelupäivissä palattiin jälleen miettimään sitä, että priorisointi tosiasiassa tapahtuu feature-tasolla. Kehityskokonaisuudet/epicit ovat hyödyllisiä siinä, että asioita saadaan niputettua ja priorisoitavien asioiden määrä pidettyä hallittavana, esittelykelpoisena, mutta silloinkin taustalla vaikuttavat featuret. Kuluneen jakson aikana kokeiltiin WSJF-priorisointimallia ja sekin avasi silmät sille, että tehtäviä kannattaisi palastella pienempiin kokonaisuuksiin eikä koittaa ahmia elefanttia kokonaisena. Itse muuten pidin kovasti tuosta mallista, lähinnä siksi, että sen myötä syntyi hyvää keskustelua ja paljon selkeämpiä perusteluja sille, miksi jonkun asian täytyy olla prioriteettilistan kärjessä. Ymmärsin esimerkiksi vasta niiden keskustelujen myötä, että eräskin vaatimattomalta kuulostava raportti on aivan keskeinen, koska yliopiston rahoitus riippuu siitä…

Tälläkin kertaa suunnitelmat saatiin tehtyä ja aikataulu tuntui jopa sen verran väljältä, että ehdotettiin, voitaisiinko suunnittelupäivät jatkossa pitää yksipäiväisinä tai aloittaa päivät selvästi myöhemmin. Koska kyseessä tällä kertaa oli kuitenkin kesälomajakson suunnittelu, ei nyt ainakaan vielä seuraavalla kerralla lähdetä typistämään suunnitteluaikaa – voi olla, että syksyllä olisimme muuten samassa tilanteessa kuin mistä DOT:n alkuaikojen jälkeen pyristelimme eroon. Suunnittelupäivissä hyvää on juuri se, että niissä on aikaa istahtaa kiireettömästi alas miettimään ja ideoimaan tulevaa. Ja kun tekemistä ei ole liikaa, kerkeää myös kysellä kasvotusten vihdoin siltä harvoin näkemältään työkaverilta mielessä kuukausia muhineet kysymykset. Itsekin tuli siirrettyä lennossa MPASS-ymmärrystäni IdM-väelle, kun nyt vihdoin oli sille hyvä hetki – kuukausien “sitten kun on hyvä hetki”-ajattelun jälkeen.

Ja tällainen lista suunnittelupäivissä saatiin aikaiseksi. Tämäkin lista konkretisoi sitä, kuinka käytäntö pyörii featureiden ympärillä – jos nämä liikennevalot olisi kirjattu epiceittäin, paljon arvokasta tietoa jäisi saamatta. Jätin muuten tuohon tarkoituksella näkyviin myös pois jätetyt tehtävät. Niissä tyypillisesti on todettu, että käsiparit eivät riitä tekemiseen tai on muita syitä, joista johtuen on todettu, että tekeminen voidaan jättää myöhempään. Tällaisenaan tämä lista on taatusti hankala hahmottaa sellaiselle, joka ei näiden asioiden parissa työskentele ja osaan näistä olikin kirjattu tavoiteltuja hyötyjä (jotka jätin pois, jotta taulukko mahtuisi paremmin tähän…). Jatketaan kehittymistä.

✅ uskotaan, että tehtävä toteutuu; ⚡ toteutumiseen liittyy epävarmuuksia (esim. toimittaja, resurssipula); ⛔ ei toteudu

Jakson 4 kehityskokonaisuudet