Scrumin seremoniat: 8 vinkkiä hyvään Scrum Demoon

Scrum Demo – Miksi se on niin tärkeää
Scrum sprintin lopussa tulisi näyttää, mitä sprintissä on saatu aikaiseksi. Tälle on useita syitä:
Yleisin virhe – kaikki yhdessä seremoniamuhennoksessa
Meidän tiimivalmentajien työssä yksi kovin kivulias hetki on se, kun menee auttamaan jotain tiimiä ja sitten kyselee, miten heillä tehdään Scrumin seremonioista ne sprintin loppuun asettuvat seremoniat, Sprint review, Demo ja Retrospective. Kipu rinnassa tulee silloin, kun kuulee tähän vastauksena “että juu meillä, ei oikeastaan tehdä varsinaisesti demoja ollenkaan, ja Review on itse asiassa yhdistetty seuraavan sprintin planning -kokoukseen”. Tässä vaiheessa jo pääsee huokaus ja vähän kirpaisee. Toiveikas valmentaja kysyy silti “no entäs se retro?”. “Juu se retro pidetään siinä samassa kokouksessa, jos on tarvetta”.
Jos valmentaja ei tässä kohtaa saa sydänkohtausta, niin sitten voidaankin aloittaa tiimin toiminnan kehittäminen!
Miksi yleensä on hyvä idea pitää seremoniat erillisinä?
Mennään ihan kohta itse demo-osuuteen, mutta käytetään hetki aikaa sen miettimiseen, miksi kannattaa harkita näiden kokousten pitämistä enemmän erillään.
Sprint planningista ja Retrospektiveistä onkin jo meidän seremoniablogisarjassa omat erilliset blogit. Miksi näitä kokouksia ei kannata pitää yhdessä kokouksessa? Tässäpä pääsyyt:
- Jokaisella sprintin seremonialla on oma selkeä tavoitteensa. Jos seremoniat sekoittaa keskenään, niin niistä ei saa niiden tuomaa lisäarvoa.
- Retrospektiveen kannattaa panostaa – hyvä retrospektive ottaa tunnin aikaa ja pidetään ajankohtana, jolloin tiimi on energinen. Usein tämä ajankohta löytyy muualta kuin sprintin lopusta. Retron tavoitteena on tiimin suorituskyvyn nostaminen. Jos retro yhdistetään sprintin loppupalavereihin, voi melkein taata sen, että muut asiat syövät retromiettimisen ajan. Tiimi junnaa sitten paikallaan.
Esimerkkiaikataulu Sprintin loppuun
Esimerkkiaikataulu sprintin loppuun voisi olla näin:
- sprintti loppuu keskiviikkona
- keskiviikkona kello 13:00 – 13:30 Demo
- keskiviikkona kello 14:00 -15:00 Sprint review
- torstaina kello 9:30 – 11:00 Sprint planning
- tiistaina seuraavalla viikolla kello 13:00 – 14:00 Retrospective
Miten toimia, jos tiimejä on enemmän kuin yksi?
Jos tuotetta on kehittämässä useita tiimejä, niin kannattaa harkita sellaista vaihtoehtoa, että Demo olisi yhteinen tilaisuus kaikille tiimeille. Tämä toimii yleensä hyvin, jos tiimejä on muutama, mutta jos tiimejä on enemmän, demosessiosta saattaa näin tehtynä tulla liian kömpelö ja pitkä. Tällöin voi harkita sitä, että lähettää toisen tiimin demosessioihin edustajan, nauhoittaa videolle demoja ja jakaa niitä intranetin kautta, tai sitten pidetään tiimidemojen lisäksi yhteinen “demohetki”. Sprintin katselmointia (sprint review) ei kannata kuitenkaan yhdistää tiimien kesken, vaan se kannattaa aina pitää tiimin sisäisenä asiana.
Millainen on hyvä Scrum Demo?
Itse demosessioonkin on syytä kiinnittää huomiota. Demosession olisi hyvä olla tiivis tietopaketti muille (ja myös tiimiläisille) siitä, mitä sprintissä saatiin valmiiksi. Hyvä demo olisi kokonaisuudessaan noin puolen tunnin mittainen, mutta yleisön palaute ja kysymykset saattavat venyttää sitä varttitunnilla. Scrum Masterin kannattaa miettiä demojärjestys jo ennalta, ja jos kehittäjät demoavat niin sitten pitää miettiä, miten demottavien asioiden väliset vaihdot saadaan toimimaan sulavasti. Usein kaikkein sulavin vaihtoehto demoamiselle on se, että yksi ihminen demoaa kaikki tarinat. Tiimi voi itse sopia kuka tämä on, mutta se voi olla myös Product Owner, erityisesti silloin jos paikalla on stakeholdereita, joiden kanssa Product Owner yleensä keskustelee tarinoiden sisällöstä. Se, kuka demoaa voi vaihdella siis aika paljon, eikä ole niin tärkeää. Se, miten demotaan ja mitä demossa pitäisi näyttää, onkin tärkeämpää.
Kahdeksan pointtia hyvään demo-sessioon!
Hyvässä demossa:
Palaute on koko demon päätarkoitus! Demo kannattaa rakentaa niin, että yleisöltä saadaan kysymyksiä, kommentteja ja parannusehdotuksia. Jos niitä ei tunnu kuuluvan, sitten kannattaa vielä vaikka kysyä heiltä suoraan. Ilmapiirin olisi hyvä olla sellainen, että yleisö tuntee olonsa turvalliseksi esittää kysymyksiä ja kommentteja. Tuoteomistaja voi olla tässä vaiheessa tarkkana ja kirjata mahdolliset backlogille menevät ehdotukset ylös. Joskus harvoin tiimi on saanut ratkaisun valmiiksi, ja sitten demossa saadaankin palautetta, että ei tämä kelpaa – asiakas haluaakin toisenlaista toimintoa. Tällöin on tuoteomistaja epäonnistunut tarinan määrityksessä. Demon tarkoitus on olla varmistus myös sille, että yritetään tehdä asioita oikein asiakkaan näkökulmasta ja asiakas- tai markkinalähtöisesti.
Sprintin katselmointi – miksi sitä tehdään
Täydellisessä maailmassa sprintin katselmoinnille (sprint review) ei ole tarvetta. Tiimi saa tehtävänsä valmiiksi ja noudattaa aina niin definition of donea kuin hyväksyntäkriteereitäkin. Koska olet lukenut tätä jo tänne asti, niin luultavasti olet törmännyt myös vähemmän täydellisiin tiimeihin ja toimintatapoihin. Näitä varten sprintin katselmointi on tärkeää. Sprintin katselmoinnissa tuoteomistaja (product owner) ja tiimi yhdessä käyvät sprintin sisällön läpi ja varmistavat, että sovittuja toimintatapoja on noudatettu. Joissain tiimeissä tämä tehdään niin, että merkitään työkaluun, esimerkiksi Jiraan, että Definition of Donea on noudatettu.
Nämä ajatukset auttavat teitä parantamaan sprintin lopetuksen seremonioitanne!