Scrum on alun perin ohjelmistokehitykseen luotu ketterään kehittämiseen pohjaava projektinhallintatapa. Sen ytimessä ovat nopeat kehittämissprintit, joiden aikana toteutetaan arvoa tuottavia kokonaisuuksia. Kehittämistyössä on selkeä rakenne, jossa tiimiläisillä on määritellyt tehtävät ja seuranta tapahtuu mallissa määritellyillä kokouskäytänteillä (Scrum.org 2025).
Klassisen ja oikein toteutetun Scrumin vahvuus on läpinäkyvyydessä ja kyvyssä mukautua projektin tarpeisiin. Tiimi on koko ajan selvillä mitä tapahtuu nyt, mitä seuraavaksi ja tiimi omistaa projektin etenemisen.
Klassisesti Scrumia on tarkoitus seurata raamien mukaisesti. Tässä verkkoartikkelissa kuitenkin keskityn siihen, miten toteuttaa tietoisesti Scrumia väärin, jotta se palvelee paremmin TKI-kehittämistä erityisesti korkeakouluympäristössä.
Mikä on Scrum ja miksi toteutin sitä väärin?
Koko Scrum-metodologian läpikäyminen on liian iso homma tämän verkkoartikkelin yhteydessä. Tiedonjanoisemmille linkkaankin tähän virallisen suomenkielisen Scrum-oppaan (Schwaber & Sutherland 2020), jos haluaa opiskella asiaa enemmän. Jatkossa viittaan kohtiin, joita olen muuttanut alkuperäisestä mallista, jotta seuraaminen on helpompaa. Oppaasta voi käydä tarkemmin katsomassa, miten metodin luojat ajattelivat asian.
Ohjelmistokehityksessä Scrum on jo vanha tuttu ja siellä näkee monia tapoja toteuttaa Scrumia. Oikein tehtynä tiimi tietää omat rajansa, projektilla on realistinen tavoite ja turhat tapaamiset pidetään minimissään. Pidempään työskennelleiden parissa se kuitenkin nostattaa myös joskus hikikarpaloita ja muistoja loputtomista palavereista, planning sessioista ja tyhjänpäiväisiltä tuntuvista daily Scrummeista. Tämä on valitettavan usein esimerkki siitä, miten Scrum on otettu käyttöön. Tässä verkkoartikkelissa keskityn omaan tapaani toteuttaa Scrumia väärin ja miten ”pakotin” sen palvelemaan Metropolian Robo Garagella tehtäviä TKI-projekteja.
Robo Garage on Metropolian Myyrmäen kampuksella sijaitseva yritysyhteistyöpaja, jossa tehdään useita eri projekteja sekä hankkeita. Se on opiskelijoille avoin tila, jossa pääsee tekemään oman mielenkiinnon ohjaamana joko omia projektejaan tai osallistumaan johonkin Garagen tarjoamaan projektiin tai hankkeeseen.
”Oikein” tehtynä Scrum ei mielestäni taivu korkeakouluissa tehtäviin TKI-projekteihin, sillä aikataulu on niissä usein tiukka ja projekteissa mukana olevat tiimit saattavat vaihtua joskus tiuhaankin. Korkeakoulussa TKI-projektit toteutetaan usein kertaluontoisina kokeiluina tai pienimuotoisina Proof of Consepteina (Todiste toimivuudesta). Niissä lopputulos on usein TRL (Teknologian valmiustaso, Technology Readiness Level) tasoa 3, joskus jopa 7. TRL on NASA:n alun perin kehittämä tapa määritellä projektin valmius (European Space Agency, n.d.).
Level 1: Basic principle
Level 2: Application formulated
Level 3: Proof-of-concept
Level 4: Functional verification
Level 5: Breadboards (reduced scale) verification in relevant environment
Level 6: Models (full scale) demonstration in relevant environment
Level 7: Model demonstration for operational environment
Level 8: Flight qualified
Level 9: Flight proven
Kertaluontoisten kokeilujen lisäksi korkeakoulussa toteutetaan pidempiä TKI-hankkeita ja -projekteja, joissa mukana on useita vaihtuvia tekijöitä osana Robo Garagen toimintaa. Toteutusta tekevät ryhmät saattavat vaihtua ilman muodollista soihdunvaihtoa, missä kesken jääneet kehitystyöt jäävät kertomatta ja työn jatkuvuus katkeaa hetkellisesti. Tämä tiedon jatkuvuuden varmistaminen on jokaisen hankkeen ja projektin päänvaiva.
Kanban Scrumin apuna projektinhallinnassa
Scrum on avuksi näiden edellä mainittujen korkeakouluympäristön TKI-työn haasteiden ratkaisemissa, sillä sen avulla voidaan kirjata ylös tarpeelliset tehtävät. Kehittämässäni mallissa Scrumin tueksi lisätään käyttöön kuitenkin myös Kanban-menetelmä. Näin saadaan aikaiseksi kokonaisuus, jolla saadaan paloiteltua isommatkin ja monimutkaiset projektit pieniin helposti pureskeltaviin paketteihin. Kanbanin avulla Scrumissa käytettävien Sprinttien tehtävät saadaan helposti jaettua tekijöiden kesken ja tieto sprintin etenemisestä saadaan helposti kaikkien projektin tekijöiden saataville.
Kanban on maailmansotien jälkeen Toyotan insinöörien kehittämä menetelmä tehdaslinjaston ylituotannon vähentämiseksi. TKI-projekteissa ylituotanto ei niinkään ole huoli, mutta turha työ on realistinen riski. Tämä yhdistettynä tiukkaan aikatauluun aiheuttaa aina huolta projektin etenemisestä. (Wikipedia, 2025)
Kanbanin merkitys käännettynä japanista suomeksi on “liikennemerkki” tai “opaste”. Kanban onkin juuri sitä: se näyttää mitä pitää tehdä, mitä tehdään nyt ja mikä on jo tehty valmiiksi.
Käyttämällä kanban-taulua projektin tekemisen tukena voidaan Scrum Backlogissa (Projektin kehitysjonossa) olevat projektin osat ottaa työn alle projektille hyvässä järjestyksessä. Lisäksi jokainen taululta tehtävän työn alle ottava projektityöntekijä tietää, että se mitä tekee, edistää mahdollisimman paljon projektia.
Kokemuksia Scrumista Robo Garagella
Metropolian Robo Garagella on vuoden 2025 aikana toteutettu Scrumin ja Kanbanin käyttöä useassa projektissa ja kokemus on ollut enimmäkseen positiivinen. Isoin ero ”normaaliin” työpaikkaan Garagella on, että suuri osa projektissa työskentelevissä on opiskelijoita, jolloin he ovat käytännössä aina osa-aikaisia ja heillä on opiskeluaikataulun takia rajallinen mahdollisuus tehdä projektin eteen töitä. Jotta Scrum voitiin ottaa käyttöön, siitä piti jättää pois elementtejä, jotka palvelevat pitkiä tai jatkuvia projekteja, joissa on yhtenäinen tiimi alusta loppuun.
Scrumin peruselementeistä käyttökelpoisia meille Robo Garagella ovat tiimi sellaisenaan ja työn rakenteen jäsentely. Seremonioissa joustamme jonkin verran: suunnittelpalaveri ja säännölliset päivitystapaamiset pidetään, päivittäisistä minipalavereista on luovuttu ja sprintti retrospektiivi omana seremonianaan poistettiin ottamalla se osaksi viikoittaista päivityspalaveria.
Kuinka käytännössä?
Käytännössä Scrum on Robo Garagella muovautunut seuraavaan muotoon:
- Alkupalaveri, jossa määritellään projekti ja sen tavoitteet ja valitaan tavataanko viikoittain vai joka toinen viikko. Scrum suosittelee 1-4 viikon välein tapaamista, itse olen huomannut että 2 viikkoa on hyvä aikaväli päivityksille. Ryhmälle opetetaan miten Scrum toimii ja mitä heiltä odotetaan.
Ryhmä saa tehtäväkseen luoda alustavan projektisuunnitelman ja luonnostella koko projektille backlogin, eli karkean määrityksen tehtävistä projektin osista seuraavaa palaveria varten. - Viikkopalaverit rytmittävät sprintin eli työrupeaman palaverien välissä ja määrittävät hyvin sprintin pituuden. Nämä palaverit toimivat myös sprint-katselmuksina ja sprint-suunnittelusessioina. Ensimmäisessä palaverissa olemme kasanneet backlogin pohjalta ensimmäisen Kanban-taulun, jolla määritellään spintin aikana tehtävä työ.
Myöhemmissä palaverissa on ollut tapana, että tarkastetaan backlog, mikäli halutaan muuttaa osia projektista ja päivitetään Kanban-taulu seuraavaa sprinttiä varten. - Sprintti on viikkopalaverien välissä tehtävä työ ja projektin varsinainen liha. Viikkopalaverien aikana tehtävä työ pohjustaa sen, mitä sprintin aikana valitaan tehdä. Kanban-taulun rakentamisen, eli valinnan siitä mikä osa projektia tehdään ensin, tekee projektin varsinaiset toteuttajat.
- Loppupalaveri/projektin esittely, on hetki, jossa projektin lopputulokset esitellään asiakkaalle joko opiskelijoiden opintojakson loppuesityksen puitteissa tai erikseen sovitussa näytöksessä.
Edellä esitetyllä tavalla Scrumin hyödyntäminen ei silti takaa automaattista onnistumista, sillä Scrum on vain yksi tapa hoitaa projektin aikataulutus ja hallinta. Kuten kaikissa muissakin projektimetodeissa, onnistuminen riippuu siitä noudattaako tiimi metodia. Paras onnistuminen on ollut ryhmillä, jotka jaksavat käyttää kanban-taulua tekemisen tukena.
Scrum tällä sovelletulla metodilla toteutettuna on ollut isossa roolissa Robo Garagella viime aikoina, mutta käytössä meillä on toki myös muita projektinhallintamalleja. Toteutamme projekteja myös esimerkiksi perinteisillä vesiputousmalleilla ja Gant-kaavioilla. Niille toki on oma paikkansa projektinhallinnassa ja menetelmä tuleekin valita projektin lähtökohtia tukevaksi.
Kaiken kaikkiaan ketterät metodit mahdollistavat suunnan nopean vaihtamisen, mikäli kesken projektin tulee olo, että nyt ei tehdä juuri sitä mitä tarvitaan tai halutaan. Uskon myös vahvasti, että ketterien metodien tärkeys tulee korostumaan tulevaisuudessa, etenkin jos TKI-työnä kehitetään maksullisia palveluita tai lisensoituja tuotteita.
Lähteet
European Space Agency. n.d. Technology Readiness Levels (TRL). Haettu 17.12.2025.
Schwaber, K. & Sutherland, J. 2020. Scrumin määritelmä ja pelisäännöt (pdf). Haettu 17.12.2025.
Scrum.org. n.d. What is Scrum? Haettu 17.12.2025.
Wikipedia. 2025. Kanban. Päivitetty 3.9.2025. Haettu 3.12.2025.
Kirjoittaja
-
Niko Hutri
Projekti-insinööri, Metropolia AmmattikorkeakouluNiko työskentelee projekti-Insinöörinä Myyrmäen kampuksen Robo Garagella TECHBOOST hankkeessa.
Tutustu tekijään
