Scrumilla ketterämmin viestinnän projekteissa?

15.05.2014

Katariina Ahonen

Välillä kannattaa kurottaa muille aloille ja selvittää mitä sieltä voisi oppia. Tällä kertaa katse kääntyy – ohhoh! – ohjelmistokehitykseen.

Koska projektinhallinnalliset jutut saavat sukat pyörimään jaloissani, innostuin selvittämään, mitä uusia ajatuksia nykyisin kovasti vallalla oleva ketterä ohjelmistokehitys ja erityisesti Scrum voisivat antaa viestinnälle.  Scrumin perusideana on jakaa ohjelmistokehitys pienempiin paloihin, sprintteihin, sen sijaan, että tehtäisiin koko homma kerralla valmiiksi esimerkiksi vuoden projektissa. Scrumista tuntuisi irtoavan yksi jos toinenkin oppi viestinnän puolelle – tässä parhaita:

1. Olivatko nämä varmasti ne oikeat käytännöt?
Retroissa (retrospective meeting) mietitään, mikä edellisessä sprintissä sujui ja mitä pitäisi tehdä jatkossa toisin. Niin itsestään selvää ja silti se jää niin usein tekemättä.

2. Palavereita useammin ja jaarittelut pois!
Pelkkä ajatus siitä, että palavereita pitäisi olla vielä lisää, voi aiheuttaa kauhua. Daily scrum on päivittäinen pikapalaveri jossa katsotaan mitä kukin teki eilen, mitä tekee tänään ja mitä esteitä on tämän päivän töille. Viestinnässä vastaavan toteuttaminen vaatisi aika laajan ja intensiivisen projektin, mutta voisi kyllä toimia. Opittavaa olisi ainakin sellaisissa projekteissa, joissa palaverit venyvät lörpöttelyssä, sinne kuulumattomien asioiden puimisessa ja myöhästymisten takia. Enhän minä koskaan…

3. Kuka varmistaa, että projekti toimii kuten pitäisi?
Hienon tittelin lisäksi Scrum Masterilla on ihan oikeita hommiakin. Hän poistaa työtä haittaavia esteitä ja varmistaa, että kaikki ryhmään kuuluvat ymmärtävät ja myös käyttävät Scrumia. Yhtä lailla viestinnän projekteissa jonkun pitäisi välillä katsoa, työskentelevätkö kaikki projektissa sovitulla tavalla ja onko ylipäätään selvää, mitkä käytännöt ovat missäkin projektissa käytössä.

4. Kuka tekee päätökset?
Oletko joskus ollut mukana viestinnän projektissa, jossa on joko monta päätöksentekijää tai kenelläkään ei tunnu olevan sitä kuuluisaa viimeistä sanaa? Jep! Product Owner vastaa kehitysjonosta eli käytännössä siitä, mitä kehitetään. Hän voi, ja varmaan kannattaakin, kuunnella ennen päätöksiään muita tahoja, mutta viimeisen päätöksen hän tekee aina itse. Hän vastaa paitsi tuottavuudesta, myös siitä, että tiimi kehittää sprinteissä lopullisen päämäärän kannalta tärkeitä asioita.

5. Mitä me nyt oikeastaan teemme?
Tämän haluaisin käyttööni heti! Product Backlog on nimittäin lista kaikesta, mitä lopullisessa tuotteessa voidaan tarvita. Listaa täydennetään koko ajan. Viestinnän projektissa tämä voisi olla lista kaikista mahdollisista ideoiduista toimenpiteistä, joita vaikkapa jonkin asian julkistuksen eteen voisi tehdä. Sitten Product Owner valitsisi niistä aina keskeisimmät, joita seuraavina viikkoina toteutetaan. Tadaa!

Minä ainakin olisin valmis kokeilemaan viestintäprojektin vetämistä Scrumin opein – uskaltaisitko sinä tarttua haasteeseen?

 


Kuva: Enrique Fernández (Creative Commons)

Tilaa Kaiku Helsingin uutiskirje:

TILAA