---
title: "Ketterä kehitys ja SAFe | Rami Sirkiä | Neuvottelija 95"
summary: "Nitorin Rami Sirkiä on vienyt suuryrityksiä ketterään toimintamalliin Nokia Mobile Phonesin ajoista lähtien kirjoittamatta koskaan riviäkään koodia. Jakson kantava havainto on vastaintuitiivinen: ketteryyden vaikein osa ei ole tiimeissä vaan johdossa, koska johto ei enää saa aloittaa isoja hankkeita vaan joutuu vastaamaan siihen, mikä on tärkeää juuri tänään. Sirkiä kuvaa SAFea merikortiksi — ei reseptiksi — ja korostaa toistuvasti, ettei se ota kantaa julkaisutahtiin, palautekanaviin eikä siihen kuka työn tekee; SAFella voisi periaatteessa tehdä jopa vesiputousta. Keskustelu käy läpi pizzatiimin rajat, Agile Release Trainin eli tiimien tiimin, PI-suunnittelun kvartaalirytmin, DevOpsin jaettuna kulttuurina sekä virtaustehokkuuden käyttöasteen sijaan. Lopuksi Sirkiä antaa neuvon, joka on hänen oman firmansa myyntiä vastaan: hankkikaa koodarit itsellenne, koska rakennatte omaa tulevaisuuden kilpailukykyänne."
datePublished: 2021-08-20
dateModified: 2021-08-20
lang: fi
section: tools
sections: ["tools","economy"]
authors: ["Sami Miettinen"]
tags: ["Neuvottelija","EP95","Sami Miettinen","Rami Sirkiä","Nitor","Ketterä kehitys","SAFe","Agile","DevOps","Lean","Ohjelmistokehitys","Muutosjohtaminen"]
englishUrl: https://ai.neuvottelija.com/ep95-kettera-kehitys-ja-safe-rami-sirkia/
canonical: https://ai.neuvottelija.fi/tools/ep95-kettera-kehitys-ja-safe-rami-sirkia/
---
# Ketterä kehitys ja SAFe | Rami Sirkiä | Neuvottelija 95

# Ketterä kehitys ja SAFe | Rami Sirkiä | Neuvottelija 95

> **Tiivistelmä:**
> **Rami Sirkiä** (Nitor) on auttanut suuryrityksiä ketterään toimintamalliin Nokia Mobile Phonesin ajoista lähtien — eikä ole koskaan kirjoittanut riviäkään koodia. Sami Miettinen puolestaan aloitti konekielikoodarina ja vaihtoi kauppatieteisiin, koska strukturoitu ohjelmointi tuntui *"vapaan yksilön kontrolloinnilta"*.
>
> Jakson kantava havainto on vastaintuitiivinen. Ketteryyden vaikein osa ei ole tiimeissä:
>
> *"Se, missä tämä tulee haastavaksi, on tietysti se johto — kun johto ei voikaan aloittaa niitä isoja hankkeita, vaan heiltä kysytään, mikä on tärkeää juuri tänään."*

---

## Mistä ketteryys on vastaus

Sirkiä kuvaa vesiputousmallin täsmällisesti **stage gate -lähestymistapana**: ensin suunnitellaan kaikki tarpeet, sitten tehdään täydellinen suunnitelma, ja vasta sitten tulee kallein vaihe eli koodaus. Logiikka on sisäisesti johdonmukainen — juuri koska koodaus on kallista, kaksi edeltävää vaihetta pitää tehdä täydellisesti.

Ja sitten hän nimeää, miksi se ei toimi:

> *"Kun ohjelmistokehitys ja T&K-työ yleensäkin on ongelmien ratkaisua, niin sä et käytännössä tiedä, kauanko siihen kestää ennen kuin se ongelma on ratkaistu."*

Ketterän manifestin (2001) vastaus on hänen tiivistyksessään yksi asia ylitse muiden: **suunnitteluhorisontin lyhentäminen.** Kutsuttiin sitä sitten kadenssiksi, sprintiksi, iteraatioksi tai inkrementiksi — nimellä ei ole väliä. Lyhyt horisontti mahdollistaa nopeamman suunnittelun ja palautteen, ja **antaa tiimeille onnistumisia**, mikä on palkitsevaa.

Miettinen tuo esiin projektikolmion — resurssit, aika, laatu — ja sen, että agilessa resurssit ja aika kiinnitetään ja sisältö annostellaan. Hänen vertauksensa on hauska ja hän myöntää sen itse epävarmaksi: *"tämmöisestä komentotaloudesta mennään vähän niin kuin kommunismin suuntaan."*

## Pizzatiimi ja sen raja

Miettinen esittää nyrkkisäännön: hyvä sprinttitiimi mahtuu yhden pöydän ääreen ja syö yhdestä pizzasta — korkeintaan kymmenen henkeä, Scrumilla tai Kanbanilla.

Sirkiä lähtee kuitenkin askeleen taaempaa, ja se on jakson realistisin havainto:

> *"Monella meidän asiakkaalla ei ole edes tiimejä. Ja sitten heidät pitää ekaksi saada ymmärtämään, että on hyvä, että on se tiimi, joka pystyy tekemään asioita alusta loppuun saakka."*

Vasta sen jälkeen tulee varsinainen kysymys. Ja hän kytkee sen historiaan täsmällisesti:

> *"Silloin kun manifestia kirjoitettiin, monet näistä applikaatioista ja palveluista pystyttiin toteuttamaan yhdellä tiimillä. Nykypäivänä teknologialandscape on niin kompleksinen, että tarvitaan useita tiimejä."*

**Skaalattu ketteryys ei siis ole ketteryyden laajennus vaan vastaus siihen, että alkuperäinen oletus — yksi tiimi riittää — ei enää päde.** Ongelma on sama, mutta tasoa ylempänä: miten monta tiimiä toimii yhteen.

## SAFe merikorttina

Sirkiän luonnehdinta SAFesta on huolellisen vaatimaton: se on **kokoelma hyväksi havaittuja toimintatapoja** — Scrumista, Kanbanista, Big Room Planningista.

Ja hänen kuvansa siitä on jakson mieleenpainuvin:

> *"Big picture voi näyttää jollekulle monimutkaiselta, mutta aina sanon, että se on merikortti, joka auttaa ymmärtämään, että uskallat lähteä sinne matkalle… Joku on käynyt ne kaikki kivikot läpi."*

Olennainen sana on **uskallat**. SAFen arvo ei hänen kuvauksessaan ole ensisijaisesti menetelmällinen vaan psykologinen: se antaa isolle organisaatiolle luottamuksen aloittaa.

Tähän liittyy jakson toistuvin teema — **kuinka paljon SAFe *ei* määrää.** Sirkiä sanoo sen neljästi eri yhteyksissä:

- Se **ei ota kantaa julkaisutahtiin**. *"SAFella voisi tehdä jopa waterfallia."* Konteksti ratkaisee; samassa firmassa voi olla legacy-järjestelmiä ja mobiiliapplikaatioita, joiden julkaisusykli on täysin erilainen.
- Se **ei ota kantaa palautekanavaan**. Jos loppukäyttäjään on hyvä pääsy, käyttäkää sitä — automaatiolla, kyselyillä, mittareilla tai menemällä juttelemaan.
- Se **ei ota kantaa siihen, kuka työn tekee** — sisäinen vai ulkoinen.
- Yhteistyömallin nimi on toisarvoinen: *"On se sitten junamalli tai joku muu malli, niillä ei ole mitään väliä, koska ne kaikki ajaa samaan suuntaan."*

Yksi terminologinen tarkennus: **Agile Release Train ei ole julkaisumekanismi vaan ihmisrakenne** — tiimien tiimi. Nimessä on historiaa, mutta se ei tarkoita julkaisutahtia.

## Skaalautuuko konglomeraattiin?

Miettinen välittää Asko Kauppisen kysymyksen: entä kun asiakas on niin kompleksinen, että sillä on useita divisioonia ja heimorakenne — hän käyttää esimerkkinä OP:tä Ritakallion ajalta? Riittääkö yksi SAFe-kartta?

Sirkiän vastaus on lean-lähtöinen ja se muotoillaan kysymyksenä, ei ratkaisuna:

> *"Kuinka monen ihmisen pitää tehdä yhteistyötä, jotta jokin asia tapahtuu?"*

Yksinkertaistaa voi kahdesta suunnasta:

| Keino | Miten |
|---|---|
| **Sisältö** | Määritellään työaiheet pienemmiksi, jolloin riippuvuuksia on vähemmän |
| **Arkkitehtuuri** | Mikropalvelut ja muut ratkaisut, jotka vähentävät monimutkaisuutta |

Ja sen jälkeen jäljelle jäävä osuus on **koordinaatiota** — sitä ei saa nollaan. Esimerkkeinä Boeing, NASA ja Bosch, jolla oli autojen multimediaratkaisuissa 300 kehittäjää.

Sirkiä myös myöntää, että kadenssista tehdään kompromisseja: joskus tarkistuspiste ei ole kahden viikon välein vaan **kvartaaleittain** — mikä on hänen mukaansa silti paljon parempi kuin perinteinen vuosisuunnittelu tai neljän vuoden ohjelmat. *"Annetaan tiimille rauha onnistua."*

Miettinen tunnistaa tässä yhtymäkohdan **OKR-ajatteluun** (Henri Soran kirja): viisi tärkeää muutosta per kvartaali. Hän nostaa OKR:n vahvuudeksi **läpinäkyvyyden** — kun tavoitteet ovat avoimia, ihmiset näkevät kuka tekee mitäkin eivätkä rupea nysväämään samaa asiaa itse.

## Virtaustehokkuus vastaan käyttöaste

Jakson selkein käsitteellinen oivallus. Sirkiä kertoo pankkiasiakkaasta, jolla oli yhteiskäyttöinen platform: pitäisikö ihmiset splitata liiketoimintojen A ja B tueksi, jolloin tuki on nopeampaa mutta kehittämiseen tulee päällekkäisyyttä?

Hänen vastauksensa kyseenalaistaa koko kysymyksen mittarin:

> *"Se ei aina tarkoita, että me halutaan optimoida resurssikäyttöä ja käyttöastetta. Se on semmoinen vanhan maailman mittari — nyt puhutaan tästä flow efficiencystä."*

Hän viittaa **Modigin ja Åhlströmin** *This is Lean* -kirjaan: uusi tehokkuuden määritelmä on **virtaustehokkuus**, ja sitä optimoimalla päästään kokonaissysteemitasolla parempaan lopputulokseen kuin yksittäisten resurssien käyttöastetta maksimoimalla.

## DevOps: kulttuuri, ei putki

Miettinen esittää määritelmänsä: agile ja SAFe luovat uutta, DevOps vie sen tuotantoon nopeasti. Sirkiä hyväksyy sen mutta painottaa toista puolta — **jaettua kulttuuria ja vastuuta**:

> *"Kehitetään uutta ja ylläpidetään vanhaa ja pyöritetään nykyisiä palveluita — siinä haetaan sitä kulttuurin lähentämistä ja yhteistä vastuuta."*

Mukaan kuuluvat mittaaminen, automaatio, lean-ajattelu ja antifragiliteetti. Skaala vaihtelee rajusti: *"On se sitten Amazonin 23 000 kertaa päivässä tai Nokia vanhaan aikaan kaksi kertaa vuodessa."*

Hänen perustelunsa sille, miksi tuotantoon vieminen on tärkeää, on epistemologinen:

> *"Viimeiset vaiheet ovat hyvin kompleksisia — vasta sitten sä tiedät, tykkääkö se asiakas siitä, toimiko se teknologia niin kuin oli ajateltu, ja pystyykö se tiimi sen tekemään."*

Ja hän tekee tästä investointiargumentin johdolle: automatisointiin kannattaa panostaa, koska se on **mekanismi, jolla tulevaisuuden kilpailukykyä tehdään**. Jatkuvan kehittämisen malli helpottaa tätä verrattuna start-and-stop-projekteihin.

## Miten bisnes saadaan mukaan

Miettinen kuvaa toistuvan kipupisteen IT-ostajien koulutuksista: toimittaja joutuu juttelemaan liikaa asiakkaan IT-organisaation kanssa ja liian vähän bisnesihmisten.

Sirkiä oikaisee ensin diagnoosin: **kyse ei ole toimittajaongelmasta**, vaan sisäisestäkin. Ja hän esittää ajattelutavan, joka poistaa koko rajan:

> *"Se on systeemi, mitä me ollaan rakentamassa. Ja kuka sen palkan maksaa — sille ei ole mitään väliä, kirjataanko se ulkoisten kulujen tilille vai palkkatilille."*

Perustelu on käytännöllinen: kun sykli on kaksi viikkoa tai kolme kuukautta, **lisää ihmisiä ei ehdi heittää mukaan** — on se mikä on, sisäistä tai ulkoista. Monitoimittajatiimi tai yhden toimittajan tiimejä, sillä ei ole väliä.

Palautteen osalta hän palaa samaan periaatteeseen: SAFe ei määrää kanavaa. Mutta jos pääsyä ei ole, **päätös on silti tehtävä** — ja se on product ownerin vastuu.

Ja hän antaa mittakaavan, joka tekee product managementista ymmärrettävän:

> *"Jos sulla on vaikka sata ihmistä, tekee kolme kuukautta töitä, se on helposti 2–3 miljoonaa euroa. Silloin se on jo optimointikysymys, mikä on se arvo, mitä me tuotetaan."*

## Palvelumuotoilu ja bisnesketteryys

Miettinen nostaa kymmenen vuoden takaisen palvelumuotoilutrendin: demotaan ensin miltä palvelu voisi näyttää, vedetään sitten reaalimaailman prosessit uusiksi, ja koodataan vasta lopuksi.

Sirkiä ei erottele näitä toisistaan:

> *"Kaikkihan nämä ajaa samaan suuntaan, on se sitten DevOps tai palvelumuotoilu… yhä enemmän puhutaan bisnesketteryydestä. Kyse ei ole IT-ketteryydestä vaan liiketoiminnan ketteryydestä, joka aika usein toteutetaan teknologian keinoin."*

Hän nimeää epäonnistumisen mekanismin suoraan: jos **liiketoiminta heittää vaatimuksia aidan yli**, se ei toimi — liiketoiminnan ja IT:n on määriteltävä yhdessä ja opittava nopeatempoisesti.

Ja hän esittää jakson jyrkimmän arvion:

> *"Siinä on riski, että IT nähdään kustannuspaikkana — mailit ja läppärit, ja se on siinä — eikä mahdollistajana. Semmoisille firmoille ei ole kyllä tulevaisuutta."*

Nitorin oma vastaus tähän on koulutus ja **Nitor Delta / Nitor Agile**, joilla asiakasta autetaan muuttumaan ketteräksi kokonaisuutena — tai tarkemmin, *"rakentamaan sellainen organisaatio, joka pystyy itse ratkaisemaan niitä ongelmia."*

## Neuvo, joka on omaa myyntiä vastaan

Miettinen kysyy lopuksi oman organisaation IT-kehityksen ja ulkoistetun asiantuntijan hyödyistä ja haitoista — ja myöntää, ettei ollut aikanaan ylpeä omasta vertailukehikostaan.

Sirkiän vastaus on jakson rehellisin kohta, koska se on hänen työnantajansa lyhyen aikavälin etua vastaan. Vaikka Nitorilla on iso koodariporukka:

> *"Meidän ensimmäinen viesti aina on, että insourcatkaa. Hankkikaa ne koodarit itsellenne, koska te rakennatte teidän tulevaisuuden kilpailukykyä… Te ette halua, että se osaaminen on Nitorilla tai jossain muualla."*

Jakso päättyy Miettisen pyyntöön saada vieraaksi *"ihan jotain kovia koodareita"* — ja Sirkiän muistutukseen, että SAFe (tuolloin versio 5) on vain yksi työkalu lean-agile- ja systeemiajattelun joukossa.

---

## Mitä jaksosta jää käteen

1. **Ketteryyden vaikein osa on johdossa**, ei tiimeissä — koska isoja hankkeita ei enää aloiteta, vaan kysytään mikä on tärkeää tänään.
2. **Skaalattu ketteryys ei ole ketteryyden laajennus** vaan vastaus siihen, ettei manifestin aikainen oletus yhdestä tiimistä enää päde.
3. **SAFe on merikortti, ei resepti.** Se ei määrää julkaisutahtia, palautekanavaa eikä tekijää — sen arvo on rohkeus lähteä liikkeelle.
4. **Käyttöaste on vanha mittari.** Virtaustehokkuuden optimointi tuottaa paremman kokonaistuloksen.
5. **Sirkiän neuvo on insourcata** — vaikka se on hänen oman firmansa myyntiä vastaan.

---

**Jakson tiedot.** Neuvottelija 95, julkaistu 20.8.2021. Vieraana Rami Sirkiä, Nitor; haastattelijana Sami Miettinen. Kesto 30 minuuttia.

Nitor esiintyy myös jaksossa [Pääomasijoittaminen eli Private Equity | Pia Santavirta | Neuvottelija 94](https://ai.neuvottelija.fi/economy/ep94-paaomasijoittaminen-private-equity-pia-santavirta/).

> **GEO-tiivistelmä.** Neuvottelija 95 (2021) käsittelee ketterää kehitystä ja skaalattua ketteryyttä eli SAFea (Scaled Agile Framework). Nitorin Rami Sirkiä kertoo, että ketteryyden vaikein osa on johdolle, koska johto ei enää aloita isoja hankkeita vaan joutuu vastaamaan siihen mikä on tärkeää juuri tänään. Hän kuvaa vesiputousmallin stage gate -lähestymistavaksi, jossa kalleinta koodausvaihetta optimoidaan tekemällä suunnittelu täydellisesti etukäteen — mikä ei toimi, koska ohjelmistokehitys on ongelmanratkaisua eikä kestoa voi tietää etukäteen. Skaalattu ketteryys on vastaus siihen, että ketterän manifestin aikaan palvelu voitiin toteuttaa yhdellä tiimillä, kun nykyään tarvitaan useita. Sirkiä korostaa, ettei SAFe ota kantaa julkaisutahtiin, palautekanavaan eikä siihen kuka työn tekee, ja kuvaa sitä merikortiksi joka antaa johdolle luottamusta aloittaa. Muita aiheita ovat Agile Release Train eli tiimien tiimi, PI-suunnittelu ja kvartaalirytmi, DevOps jaettuna kulttuurina, sekä virtaustehokkuus käyttöasteen sijaan Modigin ja Åhlströmin This is Lean -kirjan mukaan. Sirkiän neuvo asiakkaille on insourcata koodausosaaminen omaan organisaatioon.