Hiukan tarinaa Scrummista, kun omassa it-alan työssä (ja työnhaussa) on tullut vastaan useita pieniä ja isompia suomalaisia IT-alan yrityksiä, joissa mainostetaan ”teemme asioita Agilella (Scrummilla)”.
Välttäkää Scrummia mainostavia yrityksiä kuin ruttoa. Tai pyytäkää ylimääräistä (palkkaa/bonuksia), jos yrityksen sisältä oikeasti paljastuu Scrumin daily/planning-palaverit tai ylipäätään Scrum-projektit/roolit (joista pidetään kiinni väkisin, eikä asiasta edes keskustella tuotetiimin jäsenten kanssa).
Scrum kehitettiin ’90-luvulla – nyt Scrum on verrattavissa vesiputousmalliin!
Yritykset, jotka käyttävät Scrummia ja Scrum-rooleja 2020-luvulla ovat jämähtäneet paikalleen ts. elävät menneisyydessä. Toki esim. Jira tarjoaa Scrum-projekteja, mutta se ei tarkoita, että projektia pitäisi oikeasti toteuttaa Scrumin sprintteinä ja Scrummin rooleilla.
Scrum on hyvin kankea tapa tehdä töitä ja verrattuna Kanbaniin (kehittämisen kuninkaaseen) Scrum sprintteineen kuluttaa _kaikkien_ siihen osallistuvien työaikaa, eikä anna mitään lisäarvoa tekemiselle. Pahimmillaan Scrum kuluttaa kehittäjät loppuun (burn out), kun koko ajan pitäisi olla tekemässä ”ominaisuuksia” 2-3 viikon sprinteissä.
--
Scrum rooleista hiukan kuvausta – miksi Scrum-roolit eivät vastaa Scrummin alkuperäisiä kuvauksia rooleista (todellisessa elämässä):
1 Tuoteomistaja (engl. product owner)
Tuoteomistajalla pitäisi olla viimeinen sana tuotteen ominaisuuksia. Tämä toteutuu harvoin; yrityksissä sovellukset tehdään yleensä asiakkaalle ja maksava tahon pitäisi olla tuoteomistaja. Juuri kukaan yrityksen tuoteomistajista ei omista Scrum-tiimin kehittämää tuotetta -> ”Product Owner” ei ole projektipäällikkö Scrummissa, joka hoitaa asiakasrajapintaa!! ja valitsee sprintin taskit.
2 Kehittäjät
Scrummissa kehittäjillä pitäisi olla valtaa mitä he tekevät. Todellisuudessa useassa yrityksessä kehittäjät ovat ns. jonkun CTO tai Lead (johtava kehittäjä)-rooli alaisuudessa ja eivät saa itsenäisesti päättää mitä ovat tekemässä.
Tämä johtaa siihen, että kehittäjät jäävät ns. "feature factoryn" sisälle. Ominaisuuksia tehdään sprinttien takia – usein _ilman laatuvaatimuksia_, ja vaaditut tehtävät tulevat ylemmän tason roolilta.
3 Scrum Master
Yritykset eivät yleensä palkkaa ketään Scrum Masterin rooliin. Scrum Masterilla ei ole mitään valtaa Scrum tiimin tekemisiin. Scrum Master on yleensä vain vanhempi kehittäjä, joka joutuu tekemään ylimääräistä työtä Scrummin takia.
-
Lähteitä:
https://betterprogramming.pub/scrum-is-dead-all-hail-kanban-the-new-king-2cd6249feef8
https://medium.com/serious-scrum/sorry-scrum-the-game-might-be-over-for-you-915227f3a0d
https://ahmadnassri.com/blog/scrum-is-dead-exploring-the-new-open-development-method/
--
Ps. Jätän sanomatta mitä mieltä olen Spotifyn? "kehittäjäheimoista" ja Scrum-tiimeistä.
Välttäkää Scrummia mainostavia yrityksiä kuin ruttoa. Tai pyytäkää ylimääräistä (palkkaa/bonuksia), jos yrityksen sisältä oikeasti paljastuu Scrumin daily/planning-palaverit tai ylipäätään Scrum-projektit/roolit (joista pidetään kiinni väkisin, eikä asiasta edes keskustella tuotetiimin jäsenten kanssa).
Scrum kehitettiin ’90-luvulla – nyt Scrum on verrattavissa vesiputousmalliin!
Yritykset, jotka käyttävät Scrummia ja Scrum-rooleja 2020-luvulla ovat jämähtäneet paikalleen ts. elävät menneisyydessä. Toki esim. Jira tarjoaa Scrum-projekteja, mutta se ei tarkoita, että projektia pitäisi oikeasti toteuttaa Scrumin sprintteinä ja Scrummin rooleilla.
Scrum on hyvin kankea tapa tehdä töitä ja verrattuna Kanbaniin (kehittämisen kuninkaaseen) Scrum sprintteineen kuluttaa _kaikkien_ siihen osallistuvien työaikaa, eikä anna mitään lisäarvoa tekemiselle. Pahimmillaan Scrum kuluttaa kehittäjät loppuun (burn out), kun koko ajan pitäisi olla tekemässä ”ominaisuuksia” 2-3 viikon sprinteissä.
--
Scrum rooleista hiukan kuvausta – miksi Scrum-roolit eivät vastaa Scrummin alkuperäisiä kuvauksia rooleista (todellisessa elämässä):
1 Tuoteomistaja (engl. product owner)
Tuoteomistajalla pitäisi olla viimeinen sana tuotteen ominaisuuksia. Tämä toteutuu harvoin; yrityksissä sovellukset tehdään yleensä asiakkaalle ja maksava tahon pitäisi olla tuoteomistaja. Juuri kukaan yrityksen tuoteomistajista ei omista Scrum-tiimin kehittämää tuotetta -> ”Product Owner” ei ole projektipäällikkö Scrummissa, joka hoitaa asiakasrajapintaa!! ja valitsee sprintin taskit.
2 Kehittäjät
Scrummissa kehittäjillä pitäisi olla valtaa mitä he tekevät. Todellisuudessa useassa yrityksessä kehittäjät ovat ns. jonkun CTO tai Lead (johtava kehittäjä)-rooli alaisuudessa ja eivät saa itsenäisesti päättää mitä ovat tekemässä.
Tämä johtaa siihen, että kehittäjät jäävät ns. "feature factoryn" sisälle. Ominaisuuksia tehdään sprinttien takia – usein _ilman laatuvaatimuksia_, ja vaaditut tehtävät tulevat ylemmän tason roolilta.
3 Scrum Master
Yritykset eivät yleensä palkkaa ketään Scrum Masterin rooliin. Scrum Masterilla ei ole mitään valtaa Scrum tiimin tekemisiin. Scrum Master on yleensä vain vanhempi kehittäjä, joka joutuu tekemään ylimääräistä työtä Scrummin takia.
-
Lähteitä:
https://betterprogramming.pub/scrum-is-dead-all-hail-kanban-the-new-king-2cd6249feef8
https://medium.com/serious-scrum/sorry-scrum-the-game-might-be-over-for-you-915227f3a0d
https://ahmadnassri.com/blog/scrum-is-dead-exploring-the-new-open-development-method/
--
Ps. Jätän sanomatta mitä mieltä olen Spotifyn? "kehittäjäheimoista" ja Scrum-tiimeistä.
Vastaukset 2
Vanhimmat
Meillekin on ympätty scrumia. Harmi vain, että toimintatavalla ei ole paljoa tekemistä todellisten vaatimusten kanssa. Sopii ehkä pelifirmoille tai muuhun vastaavaan bisnekseen, jossa työnnetään markkinoille omia uusia ohjelmia tai niiden ominaisuuksia jatkuvasti. Ei sovi pitkäjänteiseen ja monimutkaisia kokonaisuuksia sisältävään työskentelyyn varsinkaan jos toteutetaan ulkopuoliselle.
Agilen kehittäjä on todennut (2015), että "yksikään kirja ei kerro miten softakehittäjien pitäisi kehittää sovelluksia". Agilen tarkoituksena ei ollut koskaan määrittää ns. "menetelmää", jota jokaisen it-tiimin pitäisi noudattaa.
On erilaisia kehitystiimejä, vaatimuksia ja projekteja: scrum ei todellakaan sovi sellaisenaan kaikkialle, eikä ole ratkaisu reaalimaailman vaatimuksiin. Asiakasta harvemmin edes kiinnostaa millä menetelmällä jokin it-projekti toteutetaan, kunhan sovelluksen halutut (tilatut) ominaisuudet tehdään vain sovittuun pvm mennessä (kaikesta voidaan sopia).
Agile is Dead • Pragmatic Dave Thomas • GOTO 2015: https://www.youtube.com/watch?v=a-BOSpxYJ9M
https://medium.com/agileinsider/agile-is-dead-mckinsey-just-killed-it-547df8c6c9df
-
Agile is not what you do. Agility is how you do it.
-
Scrum was not guiding us anymore. It was limiting us.