Tekoäly ketterässä transformaatiossa: Tekoäly paljastaa todellisen edistyksen

Ketterä transformaatio ei ole vielä kunnolla valmis tai on jumissa, ja yhtäkkiä tekoäly astuu kuvaan. Mitä tekoäly tekee ketterille transformaatioille? Millaisia mahdollisuuksia syntyy, ja missä on syytä olla tarkkana?

Tekoäly muuttaa joitakin ketterien transformaatioiden perusoletuksia tuntuvasti. Tiimit tuottavat nimittäin nopeammin vaatimuksia, koodia, testejä, analyyseja ja päätösvaihtoehtoja. Samaan aikaan tarkastustyö, koordinointitarve ja selkeän vastuun merkitys kasvavat.

Vaara on siinä, että ketterässä transformaatiossa juostaan tavoitetilan perässä, joka vanhenee jo lähitulevaisuudessa, koska se ei enää sovi tekoälyavusteiseen toimintatapaan.

Siksi IT:n johtajat eivät nyt saa antaa lyhytnäköisten aloitteiden, kuten AI-lisenssien, token-budjettien, AI-ohjeistusten ja prompt-työpajojen, harhauttaa itseään. Heidän on tartuttava keskeiseen kysymykseen: Miten ketterä organisaatio tuottaa tulevaisuudessa arvoa tekoälyn avulla ja mukautuu tekoälyn tulevaisuuteen?

Miten ketterät transformaatiot muuttuvat tekoälyn myötä

Ensimmäisessä ketterien transformaatioiden sukupolvessa, siis noin vuoteen 2024 saakka, aikaa vievä itse ohjelmointi oli usein pullonkaula. Ketterät menetelmät, kuten Scrum, tähtäsivät siihen, ettei kehitettäisi vääriä inkrementtejä ja että ajattelua ohjaisivat pienet vedot, eli sprintit. Näihin sprinteihin liittyy tietty määrä kokousylikuormaa koordinointia ja yhteensovittamista varten. Osittain tämä kitka on positiivista, koska keskustelut voivat tuottaa tärkeitä oivalluksia.

Myös tekoälyn aikakaudella on ratkaisevan tärkeää, että tiimit työskentelevät oikeiden toimintojen parissa. Kuitenkin tarkasti rajattujen ohjelmointitehtävien vaatima aika voi lyhentyä huomattavasti: kontrolloidussa GitHub Copilot -kokeessa kehittäjät suorittivat JavaScript-tehtävän Copilotin avulla 55,8 prosenttia nopeammin kuin kontrolliryhmä.

Lähde: The Impact of AI on Developer Productivity: Evidence from GitHub Copilot

Sen vuoksi usein kahden viikon sprinttisyklit tuntuvat melko epäluontevilta, koska review- ja palautesilmukat voisivat kulkea vielä paljon nopeammin.

Ennen tekoälyä oli vielä hyväksyttävää julkaista uusi versio vasta sprintin lopussa palautteen saamiseksi, mutta tekoälyn aikakaudella Continuous Delivery (CD) on tärkeämpää. Kun tiimit tuottavat koodia nopeammin, build-, testaus-, review- ja julkaisuprosessien on kyettävä vastaanottamaan sama vauhti luotettavasti.

Vuonna 2026 raportoitu tarkastelu State of DevOps Modernizationista osoittaa tämän jännitteen: 45 prosenttia kehittäjistä, jotka käyttävät tekoälykoodityökaluja useita kertoja päivässä, julkaisee tuotantoon päivittäin tai useammin. Satunnaisilla tekoälyn käyttäjillä osuus on vain 15 prosenttia. Samaan aikaan 69 prosenttia hyvin usein tekoälyä käyttävistä kertoo säännöllisistä julkaisuongelmista tekoälyn tuottaman koodin kanssa.

Lähde: TechRadar Pro: AI has slashed coding time in 2026, but it’s sacrificed software stability

Monet suuremmat aloitteet, jotka aiemmin olisivat vaatineet laajoja yhteensovittamiskierroksia ja priorisointityöpajoja, voidaan nyt kehittää, julkaista ja testata asiakkailla nopeammin. Koska ohjelmointi kehityksen osana voi muuttua vähemmän kalliiksi, ideoita voidaan toteuttaa ja testata aiemmin.

Miksi tekoäly tekee ketterästä transformaatiosta entistä tärkeämmän

Klassinen digitalisointi on usein nopeuttanut prosesseja tai tehnyt niistä läpinäkyvämpiä. Tekoäly tuottaa itse tietotyötä: vaatimuksia, koodia, testejä, kokousyhteenvedot, päätösvaihtoehtoja.

Siten transformaation painopiste siirtyy. Kun artefakteja syntyy enemmän lyhyemmässä ajassa, tarvitaan vahvempia mekanismeja merkitykselle, laadulle ja vastuulle.

McKinsey kuvaa State-of-AI-tutkimuksessa 2025 tätä kuilua: Lähes yhdeksän kymmenestä vastaajasta raportoi säännöllisestä tekoälyn käytöstä organisaatioissaan. Merkittävää enterprise-hyötyä syntyy kuitenkin ennen kaikkea siellä, missä yritykset uudistavat työnkulkuja, selkeyttävät johtamisvastuuta, määrittelevät inhimillisen validoinnin ja hyödyntävät ketteriä tuotekehitys- ja toimitusprosesseja.

Lähde: McKinsey State of AI 2025

Kettereissä transformaatiokehityksissä tekoäly on siten organisatorisen käyttöjärjestelmän stressitesti.

Tyypillisiä murtumiskohtia:

• Epäselvät tavoitteet johtavat nopeampaan työskentelyyn väärän ongelman parissa.
• Heikko laaturakenne lisää tarkastelutyötä ja riskiä.
• Pitkät päätöspolut hidastavat myös tekoälyavusteisia tiimejä.
• Alhainen psykologinen turvallisuus estää virheiden, epäilyjen ja riskien näkymisen ajoissa.
• Silo-rakenteet estävät paikallisten tekoälyhyötyjen muuttamisen asiakashyödyksi.

Näkemys aiemmista AI-in-Agile-artikkeleistamme pysyy siten keskeisenä: tekoäly vaikuttaa vuonna 2026 ennen kaikkea organisaatioissa, joilla on kestävät palautesilmukat.

Tutkimustilanteesta: Tekoäly ketterässä ohjelmistokehityksessä: tutkimustilanne 2026 .

Ajatusvirhe: “Tarvitsemme tekoälystrategian”

Yritykset tarvitsevat tekoälyn reunaehtoja: tietosuoja, turvallisuus, vaatimustenmukaisuus, työkalujen valinta, budjetti, koulutukset, hallintamalli. Silti erillinen tekoälystrategia jää liian kapeaksi.

Ajatusvirhe: tekoälyä käsitellään lisäkyvykkyytenä olemassa olevan organisaation rinnalla. Tällöin syntyy ohjelmia, joilla on vain vähän kytköstä arvontuottoon:

• tekoälyosaamiskeskus ilman suoraa yhteyttä arvontuottoon
• Prompt-koulutuksia ilman muutosta työprosesseihin
• Työkalujen hyväksyntöjä ilman laatu- ja tarkistusjärjestelmää
• Tuottavuustavoitteita ilman asiakashyötymittareita
• Hallintasääntöjä ilman oppimissilmukoita aidosta käytöstä

Nämä toimet eivät ole vääriä. Ne eivät vain yleensä mene riittävän syvälle. Tekoälyä hyödyntävän ketterän transformaation on muutettava työsysteemejä, rooleja, päätösoikeuksia ja palautesyklejä.

DORA-tutkimus AI-assisted Software Development -aiheesta muotoilee saman ytimen: onnistunut tekoälyn omaksuminen on järjestelmäongelma. Paikalliset tuottavuusvoitot on Value Stream Managementin kautta muunnettava mitattavaksi tuote- ja organisaatiotasoiseksi suorituskyvyksi.

Lähde: 2025 DORA State of AI-assisted Software Development Report

Transformaatio: mitä tekoäly muuttaa ketterissä organisaatioissa

1. Pullonkaula siirtyy toteutuksesta suuntaamiseen

Kun toteuttaminen halpenee, suuntaamisesta tulee niukempaa. Tiimit voivat rakentaa prototyyppejä nopeammin, testata vaihtoehtoja ja toteuttaa backlog-aihioita. Huono priorisointi skaalautuu siten myös nopeammin.

Tuoteomistajat, tuotepäälliköt ja johtajat tarvitsevat siksi parempaa ongelma- ja tavoiteymmärrystä:

• Mitkä käyttäjäongelmat ovat todella relevantteja?
• Mitkä oletukset ovat kriittisiä?
• Mikä päätös tarvitsee enemmän näyttöä?
• Mitkä ominaisuudet tuottavat mitattavaa lopputulosta?

Roadmapeista tulee priorisoituja hypoteeseja. Backlogin on oltava tiiviimmin yhteydessä käyttäjäongelmiin, liiketoimintatavoitteisiin ja oppimiskysymyksiin.

Jos etsit tähän klassista transformaatiokehystä, tämä lisäys on hyödyllinen.

Lue lisää: Agile Transformation Roadmap: 5 mallia ja niiden yhteiset piirteet .

2. Pullonkaula siirtyy luomisesta varmistamiseen

Tekoäly tuottaa sisältöä nopeasti. Se ei silti ole sen vuoksi vielä totta, turvallista, hyödyllistä tai ylläpidettävää.

Satunnaistettu tutkimus kokeneilla avoimen lähdekoodin kehittäjillä havaitsi vuonna 2025 jopa pidempiä käsittelyaikoja tekoälyn käytön vuoksi. Kehittäjät odottivat ajansäästöä, mutta joutuivat käytännössä tarkistamaan, ymmärtämään ja korjaamaan enemmän.

Lähde: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Der käytännön johtopäätös: tekoälyn hyöty riippuu vahvasti kontekstista. Heikot määrittelyt, puutteelliset testit, pintapuoliset katselmoinnit ja epäselvät arkkitehtuuripäätökset muuttavat tekoälyn tuottaman sisällön manuaaliseksi tarkistus- ja korjaustyöksi.

Juuri tämän kaavan kuvasimme artikkelissamme tyypillisistä virhemalleista.

Lue lisää: Miksi tekoäly epäonnistuu ketterässä ohjelmistotoimituksessa .

3. Pullonkaula siirtyy rooleista vastuisiin

Tekoäly hämärtää roolirajoja. Kehittäjät kirjoittavat tuotetekstejä. Product Managerit rakentavat prototyyppejä. Johtajat analysoivat käyttödataa ja analyysejä itse.

Se laajentaa toimintamahdollisuuksia ja lisää samalla vastuun hajoamisen riskiä. Selkeyttävät kysymykset tulevat tärkeämmiksi:

• Kuka päättää?
• Kuka tarkistaa?
• Kuka kantaa asiantuntijavastuun?
• Kuka pysäyttää muutoksen riskin ilmetessä?
• Kuka oppii virheellisistä päätöksistä?

Roolien ei tarvitse muuttua näin jäykemmiksi. Ainoastaan vastuurajojen ja päällekkäisyyksien tulisi muuttua eksplisiittisemmiksi.

4. Pullonkaula siirtyy kokouksista oppimisjärjestelmiin

Tekoäly voi tiivistää tilannepäivitykset, kirjoittaa pöytäkirjoja ja jäsentää tietoa. Jotkin kokoukset menettävät näin merkitystään.

Vaativa ketterä työ säilyy: yhteinen ymmärrys asiakkaasta ja tavoitteesta, konfliktien selvittäminen, priorisointi, oppiminen virheistä ja yhteistyön mukauttaminen.

Tiimit, joissa on paljon “Doing Agile” -tekemistä ja vähän oppimista, kyseenalaistavat monia rituaaleja. Tiimit, joissa on aitoa “Being Agile” -asennetta, hyödyntävät tekoälyä ennemmin nopeampiin kokeiluihin ja parempaan reflektointiin.

Erottelun vuoksi: Doing Agile vs. Being Agile .

Uusi tiekartta: tekoäly osaksi ketterää transformaatiota

Järkevä tiekartta tekoälylle ketterässä transformaatiossa alkaa arvovirrasta ja organisaation oppimiskyvystä.

Vaihe 1: Analysoi arvovirta työkalukokonaisuuden sijaan

Aloita pullonkaulakysymyksellä: missä menetämme tällä hetkellä eniten aikaa, laatua tai asiakasläheisyyttä arvovirrassa?

Tyypillisiä kohtia ovat:

• epäselvät vaatimukset
• hitaat päätökset
• manuaaliset luovutukset
• pitkät katselmointisyklit
• heikko testikattavuus
• heikko näkyvyys tiimin hyvinvointiin
• myöhästynyt asiakaspalaute

Tekoälyn tulisi kohdistua kohtaan, jossa se vähentää todellista pullonkaulaa. Muussa tapauksessa paikallinen tehokkuus kasvaa, जबकि toimitusjärjestelmän suorituskyky pysyy ennallaan.

Vaihe 2: Muotoile tekoälykäyttötapaukset muutoshypoteeseiksi

Käsittele tekoälyn käyttötapauksia kokeiluina, joilla on selkeä hyöty- ja riskihypoteesi.

Hyvä hypoteesi kuulostaa esimerkiksi tältä:

Kun käytämme tekoälyä hyväksymiskriteerien ensimmäiseen muotoiluun, jälkityö refinementissa vähenee, ilman että Storiesin virheiden määrä kasvaa.

Tai:

Kun käytämme tekoälyä retrospektiivien valmisteluun, toistuvat esteet tulevat aiemmin näkyviin ja action itemit täsmentyvät.

Näin organisaatio tarkastelee hyötyä ja riskiä yhdessä. Pintapuoliset työkalujen käyttöasteet jäävät toissijaisiksi.

Vaihe 3: Suunnittele inhimillinen validointi tietoisesti

Monet tekoälyohjelmat kirjaavat inhimillisen vastuun politiikkaan. Arjessa jää usein epäselväksi, miten tätä vastuuta käytännössä toteutetaan.

Merkittävää tekoälyn käyttöä varten tarvitaan selkeät validointimallit:

• Matala riski: tekoäly saa tehdä ehdotuksia, ihmiset tarkistavat otantana.
• Keskitasoinen riski: tekoäly tuottaa luonnoksia, ihminen review’aa ne kokonaan.
• Korkea riski: tekoäly tukee analyysiä ja vaihtoehtoja, mutta päätös ja hyväksyntä säilyvät selkeästi ihmisen vastuulla.

McKinsey mainitsee määritellyt prosessit mallien tuottamien outputien inhimilliselle validoinnille yhtenä tekijänä, joka erottaa AI High Performerit muista.

Lähde: McKinsey State of AI 2025

Vaihe 4: Säädä tiimirutiinit tekoälyn nopeuteen

Enemmän tekoälyoutputia ei vaadi useampia rituaaleja. Se vaatii parempia oppimis- ja laatukysymyksiä.

Käytännössä tämä tarkoittaa:

• Planning: enemmän tavoitteiden selkeyttä, eksplisiittiset riskioletukset.
• Refinement: enemmän kontekstia, paremmat hyväksymiskriteerit, parempi testattavuus.
• Review: enemmän käyttäjävaikutusta, vähemmän pelkkää ominaisuusdemoa.
• Retrospektiivi: enemmän systeemisten mallien analysointia.

Hyviä retro-kysymyksiä tekoälyolosuhteissa:

• Missä tekoäly todella nopeuttaa?
• Missä meidät tulvii yli tekoälyn tuottamaa sisältöä?
• Täytämmekö yhä vaatimuksemme tekoälyn verifioinnille ja ihmisen vastuun kantamiselle?
• Missä yhteinen ymmärrys vähenee?
• Mitä laaturiskejä näemme aikaisemmin tai myöhemmin kuin ennen?

Scrum mastereille ja agile coacheille tässä on suuri vipuvoima: he auttavat tiimejä kalibroimaan työjärjestelmänsä jatkuvasti uudelleen tekoälyn ehdoilla.

Sopivasti tähän tarkastelimme yhteisökyselyssämme tarkemmin Agile Coachien ja Scrum Masterien roolia.

Lue lisää: Echometer-yhteisökysely tekoälystä ketterässä ohjelmistokehityksessä .

Spoileri: Agile Coachien ja Scrum Masterien rooli tulee tulevaisuudessa entistä tärkeämmäksi.

Vaihe 5: Ota tiimin terveys vakavasti johtamisen tietona

Tekoälytransformaatiot synnyttävät epävarmuutta: roolit muuttuvat, odotukset kasvavat, osaamisen on kehityttävä, ja katselmointiin kuluva työ siirtyy.

Tiimin terveys, psykologinen turvallisuus ja kuormitus kuuluvat siksi ohjaukseen. Ne ovat varhaisvaroitusjärjestelmiä, eivät pehmeitä sivumittareita.

Jos ihmiset eivät tuo esiin virheitä, epäilyksiä tai kuormittumista, tekoälyriskit tulevat usein näkyviin vasta, kun ne ovat jo skaalautuneet: laatuongelmina, luottamuksen heikkenemisenä tai tiimimoraalin laskuna.

Sopivasti syventymiseen käy tämä artikkeli: Virheiden käsittelyn kulttuuri yrityksissä .

Vaihe 6: Johda transformaatiota kokeilujen portfoliona

Täydellinen tavoitetila vanhenee tekoälytransformaatioissa nopeasti. Järkevämpää on hallittujen kokeilujen portfolio.

• 30 päivää: työkalu- ja työnkulku-kokeiluja yksittäisissä tiimeissä.
• 60–90 päivää: mitattavia muutoksia review’ssä, testauksessa tai refinementsa.
• Kvartaaleittain: päätöksiä siitä, mitkä käytännöt skaalataan, mukautetaan tai lopetetaan.
• Säännöllisesti: retrospektiivejä tiimi-, alue- ja johtamistasolla.

Näin organisaatio oppii nopeammin sitoutumatta varhain jäykkään toimintamalliin.

Hyvä inspiraatio ajatukselle “transformaatio kokeilujen portfoliona” on mielestäni OpenSpace Agility Handbook.

Lähde: The OpenSpace Agility Handbook

Kolme anti-patternia tekoälyssä ketterässä transformaatiota

Anti-pattern 1: Tokenmaxxing transformaatiostrategiana

Kun johto mittaa ennen kaikkea tekoälyn käyttöä, syntyy symbolista tuottavuutta. Tiimit optimoivat työkalujen käyttöä arvonluonnin sijaan.

Parempi kysymys kuuluu: Mitä arvovirran pullonkauloja tekoäly voi todennettavasti vähentää?

Anti-pattern 2: Keskittäminen pelon vuoksi

Tekoäly tuo mukanaan todellisia riskejä. Tietosuoja, tietoturva ja compliance tarvitsevat selkeät reunaehdot. Täydellinen keskittäminen muuttaa tämän nopeasti uudeksi byrokratiaksi.

Parempi on guardrail-malli: selkeät punaiset viivat, hyväksytyt riskiluokat, läpinäkyvät oppimissilmukat ja hajautetut kokeilut määriteltyjen rajojen sisällä.

Anti-pattern 3: Agile Coachien muuttaminen työkalukouluttajiksi

Agile Coachien ja Scrum Masterien pitäisi ymmärtää tekoälyä ja käyttää sitä järkevästi. Prompt-koulutus on kuitenkin vain pieni osa tehtävää.

Tärkeämpää ovat roolien selkeys, psykologinen turvallisuus, päätösten laatu, konfliktien ratkaisu, oppimisrytmi ja järjestelmän parantaminen.

Jos etsit konkreettisia työkalukategorioita tälle roolille, löydät täältä yleiskatsauksen.

Lue lisää: Tekoälytyökalut Scrum Mastereille ja Agile Coacheille vuonna 2026 .

Mitä tämä tarkoittaa johtajille?

Johtajien ei pitäisi myydä tekoälyä ketterässä transformaatiossa pelkkänä tehokkuusohjelmana. Se synnyttää nopeasti vastarintaa ja kaventaa näkymän outputiin.

Kestävämpi viesti:

Käytämme tekoälyä oppiaksemme nopeammin, tehdäksemme parempia päätöksiä ja vähentääksemme toistuvaa työtä. Samalla teemme vastuusta, laadusta ja tiimin hyvinvoinnista entistä näkyvämpää.

Konkreettiset johtamistehtävät:

• Muotoile tavoitteet asiakasarvon ja oppimisen edistymisen kautta, älä vain outputin kautta.
• Anna tiimeille liikkumavaraa hallittuihin tekoälykokeiluihin.
• Vakiinnuta validointi, tietosuoja ja laatu yhteisiksi työstandardeiksi.
• Ota johtajat itse mukaan tekoälyn käyttöön ja reflektointiin.
• Lue vastarinta signaalina selvittämättömistä riskeistä, peloista tai tavoitteiden ristiriidoista.

Juuri viimeinen kohta on ratkaiseva. Tekoälytransformaatio on muutosjohtamista suuren epävarmuuden vallitessa. Vastustus osoittaa usein, missä muutosta ei ole vielä ymmärretty, varmistettu tai missä se ei ole vielä yhteensopivaa.

Tähän sopii: Vastustus muutosjohtamisessa .

Johtopäätös: Tekoäly tekee ketterästä transformaatiosta rehellisempää

Tekoäly lisää painetta ottaa ketterä transformaatio vakavasti. Organisaatiot, jotka ymmärtävät ketteryyden ensisijaisesti prosessimallina, kohtaavat rajansa nopeammin. Suurempi tuotos auttaa vähän, jos tavoitteiden selkeys, laatukulttuuri ja palautteen nopeus ovat heikkoja.

Organisaatiot, joilla on aito oppimiskyky, voivat käyttää tekoälyä vahvistimena: paremmat määrittelyt, nopeammat kokeilut, lyhyemmät palautesykli, parempi reflektio, selkeämmät päätökset.

Tärkein teesi:

Tekoäly ketterässä transformaatiossa on seuraava kypsyyskoe organisaatioille, jotka haluavat olla todella ketteriä.

Jos haluat syventyä ohjelmistokehityksen näkökulmaan, tämä opas on sopiva seuraava askel.

Lue lisää: Opas tekoälyavusteisen ketterän ohjelmistokehityksen tulevaisuuteen .

UKK tekoälystä ketterässä transformaatiossa

Mitä tekoäly tarkoittaa ketterässä transformaatiossa?

Tekoäly ketterässä transformaatiossa tarkoittaa: Tekoäly muuttaa työtapoja, rooleja, päätöksentekoprosesseja ja palautesyklejä. Ratkaisevaa on, tuleeko organisaatiosta oppimiskykyisempi ja asiakasläheisempi. Nopeammin luodut artefaktit itsessään eivät ole vielä transformaation edistymistä.

Miksi tekoälytyökalujen käyttöönotto ei riitä?

Työkalujen käyttöönotto muuttaa yleensä vain teknologian saatavuutta. Varsinainen hyöty syntyy, kun tiimit mukauttavat työnkulkunsa, laatustandardinsa, vastuunsa ja oppimissyklinsä. Ilman tätä mukauttamista tuotos usein kasvaa, mutta samalla myös tarkastustyö, riskit ja koordinointiongelmat lisääntyvät.

Mikä on Scrum Masterien ja Agile Coachien rooli tekoälytransformaatioissa?

Scrum Masterien ja Agile Coachien merkitys korostuu, kun tekoäly nopeuttaa työtä. Heidän roolinsa siirtyy vahvemmin kohti järjestelmäsuunnittelua, roolien selkeyttämistä, tiimin hyvinvointia, psykologista turvallisuutta ja jatkuvaa parantamista. He auttavat tiimejä integroimaan tekoälyn järkevästi yhteistyöhönsä.

Miten tekoälyn kanssa aloitetaan pragmaattisesti ketterässä transformaatiossa?

Aloita arvovirran pullonkaulasta, älä työkalusta. Muotoile selkeä hypoteesi, rajoita kokeilu muutamaan viikkoon, määrittele laatu- ja validointisäännöt ja reflektoi sen jälkeen tiimissä, pienenikö pullonkaula todella. Tämän jälkeen käytäntöä voidaan mukauttaa, skaalata tai se voidaan lopettaa. Scrum Masterit ja Agile Coachit voivat toimia hyvinä moderaattoreina tässä.

Mitä riskejä tekoälyyn liittyy ketterissä transformaatioissa?

Suurimmat riskit ovat epäselvä vastuu, sokea luottamus tekoälyn tuotoksiin, yhteisen ymmärryksen heikkeneminen, lisääntynyt tarkastuskuorma, tietosuojaongelmat ja yksipuolinen keskittyminen tuotokseen. Näitä riskejä voidaan vähentää selkeillä suojakaiteilla (guardrails), inhimillisellä validoinnilla, hyvillä suunnittelukäytännöillä, tiimin retrospektiiveillä ja läpinäkyvällä johtamisella.