---
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. Artikkeli lukee vuoden 2021 jakson myös tekoälykoodauksen jälkeisestä näkökulmasta: Sirkiän perustelu ketteryydelle on epävarmuus eikä koodauksen hinta, joten se ei kaadu siihen että koodin kirjoittaminen halpenee — nopeampi rakentaminen vain siirtää pullonkaulan validointiin ja katselmointiin."
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://www.neuvottelija.com/ai/ep95-kettera-kehitys-ja-safe-rami-sirkia/
canonical: https://www.neuvottelija.fi/fi/episodes/107-kettera-kehitys-ja-safe-rami-sirkia-neuvottelija-95/
---
# 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.

---

## Ketterä kehitys ennen tekoälykoodausta

*Tämä osio ei ole jaksosta. Se on artikkelin oma luenta. Jakso on äänitetty elokuussa 2021, ennen kuin koodia generoivat mallit olivat kenenkään arjessa, eikä kumpikaan puhuja ota kantaa tekoälykoodaukseen. Sen väitteet kestävät silti tarkastelun — ja osa niistä kestää paremmin kuin voisi olettaa.*

Sirkiän perustelu ketteryydelle **ei nojaa siihen, että koodaaminen on työlästä.** Sen voi lukea väärin, koska jakso alkaa vesiputousmallin kuvauksella, jossa koodaus on kallein vaihe ja juuri siksi kaksi edeltävää vaihetta halutaan tehdä täydellisesti. Jos tuo olisi ollut ketteryyden peruste, tekoälykoodaus heikentäisi sitä: kun koodin kirjoittaminen halpenee, kalliin vaiheen ympärille rakennettu logiikka menettää voimansa.

Mutta Sirkiä perustelee epävarmuudella, ei kustannuksella:

> *"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."*

**Tämä perustelu on riippumaton siitä, kuka tai mikä näppäimistöä käyttää.** Epävarmuus on ongelmassa, ei kirjoittamisessa. Nopeampi generointi lyhentää yhtä vaihetta ketjussa, mutta ei kerro, oliko ratkaistava ongelma oikea.

Neljä kohtaa, joissa jakson väitteet näyttävät viisi vuotta myöhemmin luettuina joko vahvistuneilta tai kääntyneiltä:

**1. Suunnitteluhorisontti lyhenee, palautehorisontti ei automaattisesti.** Manifestin ydinvastaus oli Sirkiän tiivistyksessä horisontin lyhentäminen. Tekoälykoodaus lyhentää rakentamisvaihetta, ei oppimisvaihetta. Sirkiän oma havainto osuu tähän suoraan: *"viimeiset vaiheet ovat hyvin kompleksisia — vasta sitten sä tiedät, tykkääkö se asiakas siitä."* Jos rakentaminen nopeutuu ja validointi ei, sitova rajoite siirtyy. Se ei katoa.

**2. Käyttöastemittarin houkutus on suurempi kuin 2021.** Sirkiä kutsui käyttöastetta *"vanhan maailman mittariksi"* ja asetti tilalle virtaustehokkuuden. Uudet tuottavuusluvut ovat monilta osin samaa vanhaa mittaria muodossa, joka näyttää uudelta: hyväksyttyjen ehdotusten osuus, generoidun koodin määrä, suljetut tiketit. Modigin ja Åhlströmin erottelu pätee muuttumattomana — yksikön tehokkuus ei ole virran tehokkuutta, ja kokonaisuus optimoituu vain jälkimmäisestä.

**3. Automaatioportin arvo nousee.** Jakson DevOps-osuus perustelee automaatiota investointina tulevaisuuden kilpailukykyyn. Kun koodia syntyy nopeammin kuin sitä ehditään lukea, testien, katselmoinnin ja tuotantoonviennin kapasiteetista tulee todennäköisin pullonkaula. Sirkiän *"jaettu vastuu"* on tässä sisältökysymys eikä kulttuurifraasi: vastuun on oltava jollakulla, eikä generoitu koodi ota sitä.

**4. Insourcing-neuvon pääperustelu vahvistuu, yksi sivuargumentti heikkenee.** Neuvo *"hankkikaa ne koodarit itsellenne"* nojaa siihen, että osaaminen on tulevaisuuden kilpailukykyä eikä sen kuulu asua toimittajalla. Jos työkalut moninkertaistavat nimenomaan sen, joka jo tuntee toimialan ja järjestelmän, perustelu vahvistuu. Vastakkaiseen suuntaan vetää se, että vieraan koodikannan lukeminen ja korvaaminen on halvempaa kuin ennen, mikä pienentää yhtä klassista toimittajalukkiutumisen riskiä. Jakso ei käsittele kumpaakaan; molemmat on johdettu tässä sen omista premisseistä.

**Ja yksi kysymys, jota ei kannata sulkea.** Sirkiän lean-kysymys oli *"kuinka monen ihmisen pitää tehdä yhteistyötä, jotta jokin asia tapahtuu?"* Skaalattu ketteryys on hänen kuvauksessaan vastaus siihen, ettei manifestin aikainen oletus yhdestä tiimistä enää päde. Jos pienempi tiimi kattaa isomman pinta-alan, koordinaatiotarve voi aidosti pienentyä — tai siirtyä ihmisten välisestä koordinaatiosta järjestelmien ja agenttien väliseen, jolloin se ei vähene vaan vaihtaa muotoa. Kumpi tapahtuu, on empiirinen kysymys, eikä tämä artikkeli väitä tietävänsä vastausta.

Yksi asia on kuitenkin syytä sanoa suoraan: **jos organisaatiolla ei ollut tiimejä vuonna 2021, sillä ei ole niitä nytkään.** Sirkiän realistisin havainto — *"monella meidän asiakkaalla ei ole edes tiimejä"* — on edellytys, ei välivaihe. Työkalu, joka nopeuttaa rakentamista, ei rakenna vastuunjakoa, kadenssia eikä päätöksentekoa. Ne ovat yhä sitä työtä, josta jakso puhuu.

---

## 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.
6. **Ketteryyden peruste on epävarmuus, ei koodauksen hinta.** Siksi jakson argumentti ei kaadu siihen, että koodin kirjoittaminen halpenee.
7. **Nopeampi rakentaminen siirtää pullonkaulan validointiin ja katselmointiin** — se ei poista sitä.
8. **Vastuunjako, kadenssi ja päätöksenteko eivät synny työkalusta.** Ne ovat organisaation työtä ennen tekoälykoodausta ja sen jälkeen.

---

## Jakson aikajana

- **00:00** — Suunnitteluhorisontin lyhentäminen on johdolle vaikeinta
- **00:51** — Rami Sirkiä Nitorista ja isännän konekielitausta
- **02:43** — Vesiputousmalli ja ketterän manifestin vastaus
- **04:43** — Resurssit, aika, laatu ja sprinttien kadenssi
- **06:11** — Pizzatiimi ja monen tiimin koordinaation ongelma
- **07:49** — Agile Release Train eli tiimien tiimi
- **08:48** — SAFen big picture on merikortti johdolle
- **09:20** — OP:n heimomalli ja SAFen skaalautuminen konglomeraattiin
- **10:31** — Lean-yksinkertaistaminen ja Boschin 300 kehittäjää
- **12:01** — PI-suunnittelu ja kvartaalirytmi vuosisuunnittelun sijaan
- **13:43** — Yhteinen platform, virtaustehokkuus vastaan käyttöaste
- **15:08** — DevOps on jaettu kulttuuri ja vastuu
- **17:23** — Release Train ei määrää julkaisutahtia
- **19:15** — Miten bisnesihmiset saadaan mukaan kehitykseen
- **22:20** — Nitor Delta, koulutus ja bisnesketteryys
- **24:22** — Palvelumuotoilu toi koodin lähemmäs liiketoimintaa
- **27:49** — Oma osaaminen vai ulkoistettu, insourcing-viesti
- **29:19** — Loppusanat ja SAFe versio 5

---

## Liittyvät jaksot

- [Kun agentteja on enemmän kuin työntekijöitä | Tapio Nissilä | Neuvottelija 402](https://www.neuvottelija.fi/tools/ep402-kun-agentteja-on-enemman-kuin-tyontekijoita-tapio-nissila/) — sama koordinaatiokysymys silloin kun tekijöitä ei enää lasketa henkilöinä.
- [OKR eli Objectives and Key Results | Henri Sora | Neuvottelija 58](https://www.neuvottelija.fi/tools/ep58-okr-objectives-and-key-results-henri-sora/) — kvartaalirytmi ja läpinäkyvyys, joihin Miettinen tässä jaksossa viittaa.
- [Suomi leaniksi | Juha Ketola | Neuvottelija 140](https://www.neuvottelija.fi/tools/ep140-suomi-leaniksi-meemihaaste-juha-ketola/) — lean-ajattelu, josta virtaustehokkuuden käsite tulee.
- [Onko tekoäly pelkkää kuplaa | Petri Kajander | Neuvottelija 392](https://www.neuvottelija.fi/tools/ep392-onko-tekoaly-pelkkaa-kuplaa-petri-kajander/) — vastapaino sille, mitä tekoälyltä on lupa odottaa.

---

**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://www.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. Artikkeli sisältää lisäksi oman luennan siitä, miten jakson väitteet kestävät tekoälykoodauksen aikakaudella: ketteryyden peruste on ongelmanratkaisun epävarmuus eikä koodaamisen hinta, joten halventuva koodin tuottaminen ei kumoa argumenttia; nopeampi rakentaminen siirtää pullonkaulan validointiin, testaukseen ja katselmointiin; uudet tuottavuusmittarit toistavat vanhaa käyttöasteajattelua virtaustehokkuuden sijaan; ja vastuunjako, kadenssi sekä päätöksenteko ovat organisaation työtä, jota työkalu ei tee.