Scrum Demo – Miksi se on niin tärkeää

Scrum sprintin lopussa tulisi näyttää, mitä sprintissä on saatu aikaiseksi. Tälle on useita syitä:

1) Iteratiivinen kehitys perustuu siihen, että pysähdytään katsomaan mitä on tehty ja vastaako se asiakkaan tarpeeseen. Näin voidaan tehdä korjausliikkeitä nopeasti ja tehdä asioita samantien uudelleen ja vastaamaan paremmin asiakkaan tarpeeseen.

2) Sprintin loppu on myös tärkeä paikka varmistaa, että tiimi on toiminut itse sopimansa Definition of Donen pohjalta ja tehnyt laadullisesti hyvää jälkeä. Tähän sprintin katselmointi on hyvä tilaisuus. Usein sprintin katselmointi ja sprintin demo sekoitetaan samaan tapahtumaan, mutta usein näin ei kannattaisi tehdä. Tästä lisää myöhemmin.

3) Tekemisen demoaminen on myös tärkeä keino motivoida tiimiä. Ihmiset, aikuisetkin ihmiset, haluavat olla ylpeitä tekemistään asioita. Demo tilaisuus on tilaisuus, jossa saa ylpeillä ja juhlia suorituksillaan. Tämä auttaa motivoinnin ja yhteishengen luonnissa.

4) Sprintin demo on tärkeä mahdollisuus jakaa tietoa yli organisaatiorajojen. Se on tilaisuus, johon tulisi osallistua tiimin ulkopuolisia tärkeitä sidosryhmien jäseniä. Tilaisuudessa tieto kulkee sidosryhmien suuntaan, mutta kannattaa aina mahdollistaa lyhyt palaute ja lisäinformaatio myös sidosryhmiltä tiimien suuntaan.

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ä?

Miksi näitä kokouksia ei kannata pitää yhdessä kokouksessa?

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.
• Sprint review ja demo kannattaisi pitää erillään sen takia että niillä on eri yleisö: demoon kannattaisi kutsua vaikkapa tuotepäälliköitä, myyntiä, asiakastukea, firman johtoporrasta ja muita vastaavia henkilöitä. Sprint review taas on tarkoitettu tiimille itselleen. Älä käsitä väärin – demo ja review voivat hyvin olla aika peräkkäin sprintin lopussa. Mutta ne kannattaa ajastaa omiksi kokouksikseen. Hyvä demo on aika lyhyt kokous, luulisin että vaikkapa noin 30 minuuttia. Sprint review taas voi kestää pidempäänkin. Kannattaa siis tehdä näistä omat kalenterikutsut
• Sprint review ja sprint planning kannattaisi myös pitää erillisinä kokouksina, tosin jos jotain kokouksia lähtee yhdistelemään, tässä on eniten järkeä. Ainoastaan kokouksen pituus alkaa mietityttää – monituntiset kokoukset eivät ole kovin tehokkaita. Olisin edelleen suosittelemassa niin, että pidettäisiin nämäkin kokoukset erillisinä.

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

Sprinttiä ei kannata yleensä lopettaa perjantaisin, vaan sprintin lopetus ja aloitus kannattaa ajoittaa keskelle viikkoa. Perjantaisin ihmisillä on mielessä jo viikonlopun aktiviteetit. Se ei ole paras aika varmistaa, että sprintin lopputuotokset ovat release-laatua. Sen takia keskellä viikkoa tapahtuva sprint katko on yleensä parempi vaihtoehto.

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?

Demosession olisi hyvä olla tiivis tietopaketti siitä, mitä sprintissä saatiin valmiiksi.

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:

1. Demoa toimivaa ohjelmistoa – Demotkaa vain oikeaa softaa, joka toimii! Ei powerpointteja! Ei koodin katsomista. Show it working!
2. Ei kyhäelmiä – Demoa asioita, jotka on konfiguraation hallinnassa ja pääkoodilinjassa. Ammut itseäsi ja tiimiäsi jalkaa, jos demoat jotain kasattua kyhäelmää!
3. Näytä hyväksyntäkriteerit – Näytä miten demottava asia täyttää sille suunnitellut hyväksyntä kriteerit (acceptance criteria), mitkä tarinalle määriteltiin viimeistään Sprint Planningissä.
4. Hyödynnä hyväksyntätestejä – Demon tärkeimmät asiat löytyvät usein hyväksyntätesteistä (acceptanca tests), ja niitä kannattaa hyödyntää demon suunnittelussa.
5. Varmista etukäteen, että demo toimii! Tätä kannattaa kokeilla viimeistään demopäivän aamupäivällä. ”It worked fine yesterday”  kuulostaa pahalta, kun toimitusjohtaja on katsomassa.
6. Selitä kokonaisuus – miten demottava ratkaisu liittyy koko järjestelmän käyttäjän toimintaan? Entä miten tehty ratkaisu on arvokas käyttäjälle?
7. Pidä demot lyhyenä – Yksittäinen demottava asia on tiivis ja lyhyt, vaikka max 5 minuuttia.
8. Mahdollista palaute – anna yleisölle mahdollisuus palautteeseen ja kysymyksiin.

Palaute on tärkeää

Palaute on koko demon päätarkoitus!

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. Varsinkin reguloidussa ympäristössä puutteet DoD:n noudattamisessa kirjataan ylös, jotta voidaan jäljittää syyt, miksi jossain ei voitu noudattaa sovittuja periaatteita.

Sprintin katselmointi vaikuttaa hieman byrokraattiselta tavalta toimia, mutta se on omiaan lisäämään ketterässä kehityksessä tärkeää itsekuria. Alkuun lähes jokaisessa tiimissä tullaan huomaamaan, että kaikki eivät pidä DoD aidosti pakollisena, vaan enemmänkin ohjeena. DoDin tulee kuitenkin olla sen verran helppo, että se on ehdoton ja siitä ei voi joustaa. Tämä toimintatapa kannattaa ehdottomasti ottaa mukaan sprintteihin, tällä voi olla niin tehokkuuden, vaikuttavuudeen kuin laadun parantumisenkin kannalta oleellinen vaikutus.

Nämä ajatukset auttavat teitä parantamaan sprintin lopetuksen seremonioitanne!

Haluatko kehittää scrum demoa ja muita agile-seremonioita? Lataa ilmainen Agilen superseremoniat -oppaamme ja nosta seremoniasi seuraavalle tasolle!