Scrum imi mehut

Ei vika ole scrumissa, vaan siinä että sitä käytetään väärin/vääriin tarkoituksiin.

Jos scrum nostaa stressitasoja, niin se on väärin toteutettu. Sopii lähinnä isojen projektien apupyöräksi eli esim. 5 minuutin palaveri jossa kerrotaan yhdellä lauseella mitä tänään on tarkoitus tehdä on hyvä tieto, jos tieto ei muuten välity - voi säästää aikaa kun ukot huomaa ennen aloitusta pohtivansa samaa kohtaa ongelmasta vaikka tikettejä on jostain syystä kaksi..
En pidä myöskään huonona tapana ennen töistä lähtöä kertoa muille, mitä on tehty esim. s-postilla tiimin vetäjälle.
Sen sijaan muutokseen scrum ei sovi lainkaan: Jos on epävarmuutta mitä pitäisi tehdä ja pitää raportoida etenemistä joka päivä - se on aika lailla lopun alkua tiimille.. osa nostaa kytkintä varmasti tilanteessa, jossa ei luontaisesti ole aina mitään raportoitavaa.

Ihan naurettavaa paskaa.... Jokainen järkevä ihminen tajuaa ilman mitään scrumeja tai muitakaan projektimalleja miten asioita PITÄÄ tehdä...eli ihan aluksi suunnitellaan ja speksataan ja järjestellään tehtäviä asioita järkevään tekojärjestykseen jnejne ...nyt van taas muka keksitään pyörää uudestaan. Oikea ongelma on ne juuri ne jotka on yleensä siellä alkaen PO ja sitä korkeammalla tasolla joilla useimmiten ei ole hevonvitunkaan älyä asioista. Ihan joutavia papukaijoja, yleensä eivät edes älyä ohjelmoinnistä mitään.

Kirjoitetaanpa tähän jatkoksi, kun tuli äskettäin vastaan (2023) vastaan eräs nimeltä mainitsematon pk-firma pääkaupunkiseudulta, jonka PowerPointilla hehkutettiin Scrumia joka projektissa – ja käytännössä toteutettiin Scrummia Feature Factoryna (ominaisuustehdas) ™.

Feature Factoryssa on kyse Agile manifeston väärinymmärryksestä ja Scrumin vääntämisestä yrityksen johdon "tarpeisiin". Feature Factoryssa kehittäjät toteuttavat valmiiksi luotua listaa ominaisuuksista Sprinteissä, eikä muulle tekemiselle ole aikaa.

Verkosta muutama kohta Scrum Feature Factoryn tunnistamiseksi (asian voi tunnistaa jopa työhaastatteluissa, jos kysyy oikeita kysymyksiä). Feature factorya toteuttavaan yrityksiä kannattaa välttää, jos ei halua palaa loppuun – käytännössä olet jatkuvassa oravanpyörässä, jossa ei ole hetkenkään rauhaa.

Scrum Feature Factoryn tunnusmerkit:
-
1) Sovelluksen backlog on jalostettu ja arvioitu kuukausia etukäteen. Käytännössä on olemassa valmiit suunnitelmat jopa yli 6 kuukautta etukäteen. Tehtaan masterplanin on oltava valmiina.

2) Nopeuden ihannointi. Mitä nopeammin toteutetaan uusia ominaisuuksia – sitä parempi.

3) Ei ole uuden teknologian testausta tai teknisten ominaisuuksien/vaihtoehtojen selvitystä. Scrum tiimi toteuttaa vain Sprintin töitä. Tiimin ulkopuoliset tekevät testaukset ja esittävät toteutustavat, esimerkiksi teknisestä toteutuksesta ymmärtämätön PO.

4) Opettelulle ei ole aikaa (eikä ole rahaa koulutukseen). Kaikki on suunniteltu etukäteen (scrum sprintit), mikä käytännössä tarkoittaa sitä, että mitään ei voi muuttaa tai suunnitella uudestaan. Tiimi toteuttaa ominaisuuksia – devaajille ei makseta ajattelusta!

5) Tekninen velka on siivottu maton alle. Yrityksen johto ei näe teknistä velkaa ja johto on kiinnostunut ainoastaan onko uudet ominaisuudet/versiot julkaistu ajallaan. Jos tehtävien työmääräarviot ovat pielessä niin ne on silti pakko toteuttaa sprintissä (ei väliä miten). Tehdas ei saa pysähtyä!

6) Sprint review on vain DEMO. Scrum sprintin lopussa esitellään vain uusia ominaisuuksia ja ainoastaan aikatauluilla on merkitystä sprinteissä –> ketään ei kiinnosta, voisiko esimerkiksi teknisiä toteutuksia parantaa.

7) Scrum tiimit eivät puhu/auta muita tiimejä, kaikista tärkeintä on saada sprintin ominaisuudet toteutettua. Tehdas toteuttaa vain ominaisuuksia – muuta ei saa tehdä.

8) Scrum tiimin jäsenet eivät tiedä mitä arvoa heidän työllään on yritykselle tai asiakkaalle, esimerkiksi koodareille on backlog itemit valmiina. Tiimin ei tarvitse tietää asiakkaista tai bisneksestä – ajattelu jätetään asiakkaille tai tiimin ulkopuolisille.
-
Lopuksi: Kanban ja/tai aikataulutetut tehtävät/asiakkaan kanssa sopiminen toimivat projektissa kuin projektissa. Agile manifeston kirjoittaneet ovat todenneet, että koko Scrum on nykymuodossaan enemmän tai vähemmän kuollut.

Onhan tuota scrumia jo tullut vuosia harjoiteltua, parissakin eri firmassa. Varmaankin on ollut tuuriakin mukana, että se ei ole tuntunut juurikaan rasitteelta, eli johtajat ovat osanneet muotoilla siitä työskentelyyn sopivan mallin. On valikoitu käyttöön sellaisia osia joista on ajateltu olevan hyötyä, eikä orjallisesti otettu kaikkea suoraan ns. "oppikirjasta".

Tehtäville töille on selkeä paikka, jonne kaikki ne laittaa ja josta kaikki löytyy, meillä Jira taskit, isommat kokonaisuudet Jira epiceinä. Yleensä ylemmän tason managerit tekee Jiraan epicin, sen perusteella millainen toiminto asiakkaalle tulisi toimittaa. Epicissä on korkean tason kuvaus mitä pitää tehdä. Sen alle tehdään taskit, joissa on tarkempi toteutus. Aluksi yleensä ns. design taski(t) joissa se tarkempi toiminta suunnitellaan, ja joiden pohjalta luodaan implementointitaskit. Nämä taskit on jo koodareiden tekemistä, eli he pääsevät suunnittelemaan toteutuksen yksityiskohdat itse. Yleensä kokeneemmat tekevät designeja, etenkin jos feature vaikuttaa useampaan komponenttiin ja/tai eri tiimien alueille.

Koodarit voi itsekin ehdottaa/luoda taskeja, jos huomaavat että jokin asia kaipaa parannusta, ja niitä voidaan ottaa mukaan mikäli nähdään hyödylliseksi. Ihan mitä tahansahan ei kannata lähteä muuttelemaan, koska siinä on usein jonkin tasoinen riski että tulee tehtyä bugi jo aiemmin toimivaksi testattuun asiaan.

Tiimissä on myös testaajia, ja lisäksi on erillisiä testaustiimejä, jotka tekevät laajempaa testausta. Heidän kanssa käydään feature läpi, ja he puolestaan suunnittelevat testaustaskit koodarien inputin ja oman osaamisensa perusteella. Ensimmäisen tason testauksen koodarit tekevät itse yksikkötestauksena.

Työmääräarviot ovat koodareiden ja testaajien itse määriteltävissä. Ylempää on yleensä määrätty vain aikataulutavoite epicin valmistumiselle, eli joku tietty release, jossa toiminnon olisi oltava mukana.

Sprintit kestää 2 viikkoa. Alussa on palaveri jossa katsotaan että ollaan tekemässä järkevästi sopivia taskeja, esim. jonkin tietyn osakokonaisuuden paloja eikä ihan mitä kukakin sattuu. Näin saadaan jo esim. joidenkin osien testaustakin käyntiin. Lopussa on toinen palaveri jossa katsotaan mitä saatiin tehtyä ja mitä ei. Johtajat laskevat jotain performanssiarvoja, ja kertovat miten meni esim. työmääräarviot kohdalleen, millä tiimillä meni parhaiten jne. Samalla jutustelevat vähän laajemmasta kuvasta, esim. jos on uusia asiakkaita tai isoja tilauksia näköpiirissä jne.. Tekemättä jääneistä taskeista ei sinänsä mitään suurta numeroa nosteta, ne siirretään seuraavalle sprintille.

Ns. "daily" miitinkejä on vain pari kertaa viikossa, eikä aina sitäkään. Turhahan se on esim. tiistai aamuna kokoontua kun maanantai iltapäivällä on ollut sprintin aloituspalaveri.

Nojoo, tulipa kirjoitettua paljon, vaikka ajattelin ihan vaan lyhyesti laittaa jotain.

Jahas, mun vanha aloitus täällä nousi pintaan. Tuo oli eka kerta kun jouduin tuolla scrum-tyylillä tekemään hommia, onhan tuohon jo tottunut. Pääasia etten ole scrum-master, siihen ei kykene, ei helevetti millään. Masterin hommaan pitää olla ennemmin joku kirjuri, välttämättä tarvi olla edes mikään koodari.

Ap.