Agilen tekeminen toimivaksi metagilityn avulla (David Bishop Agile Worxilta)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Annathan anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston: Arvaan siis, että teit asioita vesiputousmallilla, mutta se ei toiminut, minkä jälkeen kokeilit ketterää menetelmää, eikä sekään oikeastaan toiminut.

Nyt yhdistelet ja sovittelet eri lähestymistapoja. Sinulla on annos ketteryyttä ja annos vesipousmallia, ja yrität keksiä päälle vielä koristeita. Kuuntele tämän päivän podcast metagilitystä. Saatat oppia yhden tai kaksi asiaa siitä, miten ketterää käsikirjaa voidaan käyttää yhdistämään molempien maailmojen parhaat puolet.

Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja. Tervetuloa DPM-podcastiin. Tehtävämme on auttaa projektipäälliköitä onnistumaan ja projekteja hallinnoivia ihmisiä toimittamaan parempia tuloksia. Autamme sinua viemään projektiosaamisesi seuraavalle tasolle. Tutustu osoitteeseen thedigitalprojectmanager.com saadaksesi tietoa jäsenyytemme kautta tarjoamistamme koulutuksista ja resursseista. Tämän podcastin tarjoaa Clarizen, yritysten projektien ja projektisalkkujen hallintaohjelmistojen johtava toimittaja. Vieraile osoitteessa Clarizen.com saadaksesi lisätietoja.

Tänään seurassani on David Bishop. Tohtori David Bishop on teknologia-asiantuntija, konsultti, tutkimusyrittäjä ja kouluttaja, jolla on yli 25 vuoden kokemus televiestinnästä, liikenteestä, julkishallinnosta ja energia-alalta. Hän on Agile Worx, LLC:n toimitusjohtaja ja perustaja. Voit tutustua yritykseen osoitteessa Agile-worx.com. Yritys tarjoaa ohjelmistoja, koulutusta ja konsultointipalveluja ohjelma- ja projektinhallintaan. Hän on myös teoksen Metagility: Managing Agile Development for Competitive Advantage kirjoittaja. Kiitos paljon, että liityit seuraamme tänään, David.

David Bishop: Kiitos kutsusta.

Ben Aston: Haluan perehtyä ajatukseen viitekehyksen rakentamisesta tyhjästä. Voitko kertoa hieman taustastasi ja siitä, miten päädyit ajattelemaan, että maailma tarvitsee uuden viitekehyksen? Millainen kokemuksesi johti sinut tähän pisteeseen?

David Bishop: Olen työskennellyt teknologian kehittämisen parissa noin 25 vuotta, pääasiassa järjestelmäarkkitehtina ja järjestelmäinsinöörinä, ja kehittänyt ratkaisuja uusien teknologioiden avulla. Olen toiminut IT-alalla sekä IATA-alalla, matkapuhelin- ja televiestintäalalla ja monilla muilla aloilla. Kuten mainitsit aiemmin, noin kymmenen vuotta sitten aloin työskennellä yrityksessä, joka keskittyi teolliseen esineiden internetiin. Yksi heidän suurimmista haasteistaan oli ketterien menetelmien käyttöönotto.

Ben Aston: Aivan.

David Bishop: Syy oli se, että asiakkaat pyysivät sitä. Yritys toimi uudella alalla – tai oikeastaan suhteellisen uudessa teknologiaympäristössä. He yrittivät integroida tätä teknologiaa kyseiselle alalle, ja markkinoilla oli paljon kilpailijoita, jotka kehittivät uutta älyverkkoteknologiaa erilaisilla radiotaajuusviestinnän ratkaisuilla.

Kaikki tämä liittyi taustalla olevaan teknologiaan. He yrittivät useita kertoja ottaa ketterät menetelmät käyttöön, koska heidän oli tärkeää saada tuotteensa markkinoille mahdollisimman nopeasti. He yrittivät tosissaan, käyttivät paljon rahaa kalliisiin konsultteihin ja epäonnistuivat kerta toisensa jälkeen. Olin itse mukana tässä prosessissa. Autoin organisaatiota kehittämään tuotteita ja samalla ottamaan ketterää toimintatapaa käyttöön. Ajattelin, että tähän täytyy olla jokin toinen tapa.

Miksi niin monet erittäin älykkäät konsultit, joita palkkasimme, kohtasivat näin paljon vaikeuksia? Tajusin, että ketteryydellä on ollut paljon menestystä ja että se on ehdottomasti hyvä ajatus, mutta sillä on myös puutteita. Yksi niistä liittyy hajautettuihin tiimeihin ja suuriin tiimeihin, mutta myös hyvin monimutkaisiin kehitysympäristöihin sekä monimutkaisiin tuotteisiin. Nämä voivat olla valtavia haasteita ihmisille, jotka yrittävät ottaa ketterän menetelmän käyttöön puhtaimmillaan.

Ben Aston: Ehdottomasti. Kerro siis hieman kokemuksestasi näissä projekteissa. Olen kiinnostunut siitä, miltä tilanne näytti käytännössä. Ymmärrän kokonaiskuvan ketterän käyttöönoton haasteista, mutta miltä ne näyttivät arjessa? Miten ne aiheuttivat ongelmia projektissa työskentelyn päivittäisessä toiminnassa? Mitkä olivat varoitusmerkkejä, joiden perusteella tiesit, ettei jokin ollut aivan kohdallaan?

David Bishop: Joissakin tiimeissä esiintyi valtavaa vastarintaa. En tarkoita mitään lievää vastahakoisuutta, vaan todella kovaa vastustusta ja valituksia siitä, ettei prosessi toiminut eikä voisi toimia. Syy oli se, että kyseessä oli sulautettujen järjestelmien ympäristö. He eivät kehittäneet pelkästään ohjelmistoja, vaan laitteita. Laitteet koostuvat yleensä sulautetuista järjestelmistä, joissa laitteisto, laiteohjelmisto ja ohjelmisto kehitetään eri työvirroissa, eri tiimeissä, joskus eri osastoilla ja jopa eri yrityksissä.

Jossain vaiheessa kaikki kolme komponenttia on kuitenkin testattava ja julkaistava yhtenä kokonaisena tuotteena. Tätä kyseinen yritys teki. Se tekee tästä kontekstista erityisen kiinnostavan, koska juuri siellä tapahtuu nykyään paljon innovaatioita. Kun ketterästä manifestista puhuttiin ensimmäisen kerran vuosikymmeniä sitten, kaikki liittyi ohjelmistoihin. Nykyään kyse ei ole vain ohjelmistoista.

Kyse on laitteista, älylaitteista, älymittareista, älyautoista ja matkapuhelimestasi. Lähes kaikki on nykyään sulautettu järjestelmälaitteisto. Siksi tällaisten tuotteiden kehittäjillä on usein suurimmat vaikeudet ketteryyden kanssa: kokonaisuus on niin monimutkainen. Arjessa työskentelimme konsulttien kanssa ja yritimme sanoa: ohjelmistotiimit työskentelevät kahden viikon jaksoissa ja pitävät päivittäisiä tilannepalavereita, mutta emme saa laitteistotiimejä toimimaan samalla tavalla. He eivät pidä sitä tarpeellisena.

Ben Aston: Aivan.

David Bishop: Myös laiteohjelmistotiimeillä oli sama ongelma. He sanoivat, ettei tämä vaikuta toimivan heidän kohdallaan eikä siinä ole järkeä. Ja se oli totta, koska ohjelmistotiimit työskentelivät paljon nopeammin. He pystyivät kehittämään iteratiivisesti. Tämä ei kuitenkaan sopinut laitteistotiimeille, jotka eivät työskennelleet samalla tavalla. Heidän tuotteidensa julkaisusykli saattoi olla 12–18 kuukautta.

Piirisarjan sovittaminen laitteistoon ja sen perusteellinen testaaminen vei yksinkertaisesti paljon aikaa. Lisäksi useimmat sulautettuja järjestelmiä kehittävät organisaatiot toimivat aloilla, joilla on paljon sääntelyä, vaatimustenmukaisuutta ja viranomaisten valvontaa.

Ajattele älymittareita ja energiayhtiöitä, älyautoja tai lentokoneen avioniikkajärjestelmää. Panokset ovat paljon suuremmat, koska mahdolliset ihmishenkien menetykset ja mahdolliset katastrofaaliset epäonnistumiset voivat olla vakavia. Näiden epäonnistumisten kustannukset ovat suuret, joten järjestelmien on täytettävä paljon korkeammat laadun, suorituskyvyn ja luotettavuuden vaatimukset kuin tavallisen ohjelmistosovelluksen tai verkkokaupan.

Ben Aston: Mikä on aivan oikein.

David Bishop: Suurin osa ketteristä menetelmistä otettiin ensin käyttöön juuri niillä aloilla, jotka omaksuivat ketteryyden nopeimmin ja aikaisimmin.

Ben Aston: Jos haluat lukea lisää Metagilityn synnystä, tutustu The Digital Project Managerissa julkaistuun artikkeliin osoitteessa thedigitalprojectmanager.com. Siinä kerrotaan, miten ajatus kehittyi ja miten kirja syntyi. Sen sijaan että syventyisimme siihen tarinaan, haluan tarkastella varsinaista viitekehystä ja löytää asioita, joita voimme soveltaa projekteissamme. Tämä on mielestäni erittäin ajankohtaista, koska monet meistä ovat kokeilleet vesiputousmallin elementtejä.

Teemme asioita peräkkäin, koska se vaikuttaa järkevimmältä sidosryhmiemme ja toimeksiantojemme rakenteen vuoksi. Samalla kokeilemme ketteryyttä: työskentelemme yhteistyössä ja iteratiivisesti. Poimimme eri lähestymistavoista palasia. Olemme omaksuneet ajatuksen siitä, että iteroimme ja tuotamme arvoa usein.

Rakennamme, testaamme ja opimme. Käytännössä meidän on kuitenkin ehkä työskenneltävä peräkkäin. Haluan keskustella metagilitystä ja siitä, miten voimme soveltaa sitä projekteihimme. Tässä keskustelussa on tullut esiin, että ketterät menetelmät ovat suosittuja ja laajasti hyväksyttyjä ohjelmistokehityksen parhaana hallintatapana. Se, mitä ketterä menetelmä oikeastaan tarkoittaa, on kuitenkin avoin tulkinnoille.

Kuten olemme puhuneet, tämä aiheuttaa todellisia haasteita useimmille yrityksille. Hybridi lähestymistapa ei ehkä saa osakseen suurinta kiitosta parhaana ratkaisuna, mutta se on käytännössä monien ihmisten todellisuus. He yhdistelevät erilaisia viitekehyksiä ja työskentelytapoja organisaation rajoitteisiin sopiviksi. Laitteiston rakennussykli on ohjelmistoa pidempi, ja väliohjelmiston sykli sijoittuu niiden väliin.

Siksi kaikkea ei voida julkaista samalla tahdilla. Sama haaste esiintyy joskus verkkokehityksessä: käyttökokemus ja suunnittelu voivat edetä nopeasti, mutta kehitys vie paljon kauemmin. Haluaisin tarkastella ongelmaa ja perehtyä kirjassasi kuvaamiisi ketterien menetelmien suorituskykyyn ja rajoituksiin.

Kun puhut rajoituksista, olemme keskustelleet tahdista ja julkaisusykleistä. Voitko syventyä nykyisten ketterien menetelmien rajoituksiin? Verrataan niitä korkealla tasolla esimerkiksi SAFeen ja taktisella tasolla Scrumiin. Mitä rajoituksia näet?

David Bishop: Kun puhutaan esimerkiksi Scrumista ja Kanbanista, on olemassa suuri joukko muitakin viitekehyksiä. On DSDM, LeSS ja DA eli Disciplined Agile, jonka PMI osti hiljattain. On kiinnostavaa nähdä, miten se kehittyy.

Ben Aston: En ole ostamassa viitekehystä. Se on mukavaa.

David Bishop: Ne yrittävät ratkaista ongelmaa eri tavoin ja eri suunnista. Ketterien menetelmien käyttöönoton perusteluihin liittyy paljon väärinkäsityksiä. Nykyään ketteryyttä otetaan käyttöön, koska sen ajatellaan parantavan tiimien yhteistyötä, tekevän johtajasta paremman tai lisäävän tehokkuutta jollakin tavalla. Kaikki tämä on toki hyvää.

Ketteryyden todellinen tarkoitus liittyy kuitenkin kilpailuun ja markkinoiden ykköseksi pääsemiseen. Ketterä manifesti perustui lean-tuotantoon. Se oli ohjelmistosovellus lean-tuotannon tekniikoista, jotka perustuivat Toyotan tuotantojärjestelmään ja kahden japanilaisen tutkijan vuonna 1979 kirjoittamaan tutkimukseen. Mitä tämä teki Toyotalle? Se muutti Toyotan peltipurkkiautoja valmistavasta yrityksestä mahdollisesti maailman johtavaksi autonvalmistajaksi.

Ketteryyden ajatuksena on jäljitellä tällaista menestystä ja tulla markkinoiden ykköseksi. Monet viitekehykset ovat mielestäni unohtaneet tämän. SAFe keskittyy yritystasolle, 30 000 jalan korkeudelle, koska se pyrkii tekemään yrityksen kaikista osa-alueista ketteriä, olipa kyse henkilöstöhallinnosta tai lakiosastosta.

Tavoitteena on tehdä yrityksen kaikista toiminnoista ja prosesseista ketteriä siinä toivossa, että tämä tuottaa ajan mittaan pieniä parannuksia. Se keskittyy myös liikaa prosessiin. Se analysoi liikaa ja muistuttaa vuosikymmenten takaisista pitkistä vakiotoimintamenettelyistä, joita käytimme keskus- ja perintöjärjestelmien tukena. SAFe muistuttaa minua tästä, koska se tuottaa pitkiä ja kalliita menettelyjä yrityksen eri osa-alueiden hallintaan ketterällä tavalla. Siinä ei välttämättä ole mitään väärää, mutta se on joiltakin osin ketteryyden vastakohta.

Ben Aston: Aivan.

David Bishop: Scrum keskittyy tiimitasolle. Se on joukko käytäntöjä, jotka auttavat hallitsemaan tiimejä. Eri viitekehyksiä voidaan käyttää yhdessä, eivätkä ne välttämättä ole ristiriidassa keskenään. Voit käyttää Scrumia, Kanbania, metagilityä ja SAFea samassa organisaatiossa.

Metagility keskittyy tuotteen kehityskoneistoon: tuotteeseen, tuotehallintaan, projektinhallintaan sekä kehitys- ja testaustiimeihin. Se tarkastelee, miten vaatimukset kehitetään ja tulkitaan, miten tuote testataan, miten se viedään markkinoille ja miten asiakkaan kanssa tehdään yhteistyötä, jotta tuote vastaa heidän odotuksiaan ja on mahdollisimman laadukas.

Jos haluat voittaa kilpailun, sinun on keskityttävä olennaiseen. Jos rakennat autoa kiihdytyskilpailun voittamista varten, keskityt moottoriin, voimansiirtoon ja vetolinjaan. Et keskity sähköikkunoihin tai ilmastointiin. Mielestäni monet muut viitekehykset keskittyvät liikaa reuna-alueisiin eivätkä siihen, mitä markkinoiden ykköseksi pääseminen todella edellyttää.

Tätä metagility tekee. Tutkimuksemme perusteella joukko tapaustutkimuksia onnistui saavuttamaan niin sanotun superketterän mukautumisen. Ne hyödynsivät ketteryyttä tullakseen markkinoiden ykkösiksi. Metagility kokoaa yhteen sen, mitä nämä yritykset tekivät oikein, ja pyrkii tuotteistamaan sen, jotta muut organisaatiot voivat saavuttaa samanlaisia tuloksia.

Ben Aston: Kuvaat sitä kattavaksi lähestymistavaksi uuden ja erittäin tehokkaan identiteetin hallintaan. Mikä metagility siis on? Onko se toimitusviitekehys, menetelmä vai käsikirja? Miten kuvailisit sitä?

David Bishop: Kuvailisin sitä viitekehykseksi. Se ohjaa sinut prosessin läpi. Ensimmäinen vaihe on määrittää, millaisen ketterän mukautuksen haluat. Itse asiassa otan askeleen taaksepäin. Kirja alkaa opettamalla ajattelemaan eri tavalla ja tekemään liiketoimintapäätöksiä tutkimukseen perustuvien ja tieteellisten menetelmien avulla.

Kirjassa on kokonainen osio tästä aiheesta. Siinä käsitellään myös sitä, miten ketterä manifesti on muuttunut tutkimustulosten perusteella. Kun päästään ketterän muutoksen osioon, yksi ensimmäisistä kysymyksistä on, millainen ketterä mukautus ja käyttöönotto pitäisi valita. Pitäisikö käyttöönoton olla puhtaasti ketterä? Pitäisikö käyttää hybridilähestymistapaa? Vai pitäisikö pitäytyä vesiputousmallissa? Joissakin tapauksissa vesiputousmalli voi olla oikea ratkaisu.

Mielenkiintoista on se, että tästä on olemassa paljon vertaisarvioitua liiketoimintatutkimusta, jonka ovat tehneet alan johtavat asiantuntijat. Useimmat konsultit eivät edes tiedä sen olemassaolosta, saati hyödynnä sitä.

Eräs tutkija nimeltä Barlow julkaisi tutkimuksen siitä, miten tämä päätös tehdään. Sisällytin kirjaani siihen perustuvan kaavion. Sen mukaan valittavan ketterän käyttöönoton tulee perustua tuotteen ja organisaation riippuvuuksien ja keskinäisten riippuvuuksien monimutkaisuuteen sekä tiimien kokoon.

Tämä on erittäin tärkeää. Esimerkiksi sulautetuissa järjestelmissä tuotteet ovat monimutkaisia ja tiimit suuria ja hajautettuja. Eri komponenttien välillä on paljon riippuvuuksia ja vuorovaikutusta. Tällainen monimutkaisuus tarkoittaa, että on toimittava hieman eri tavalla. Koko organisaatiossa ei yleensä voida käyttää täysin ketterää lähestymistapaa. Hybridilähestymistapa voi tarkoituksellisesti toteutettuna tuottaa erinomaisia tuloksia.

Hybridilähestymistapoihin suhtaudutaan alalla usein kielteisesti. Kun kuulemme sanan hybridi, ajattelemme helposti epäonnistunutta toteutusta, jossa yhdistetään ketteryyttä, Scrumia ja vesiputousmallia sattumanvaraisesti. Näin käy, kun ketterä muutos epäonnistuu. Jos hybridin ketterä toteutus kuitenkin suunnitellaan tarkoituksellisesti, perustetaan tieteelliseen päättelyyn ja tutkimukseen ja valittu lähestymistapa sopii organisaatiolle, ollaan oikealla tiellä.

Ben Aston: Voitko kuvata, miten viitekehys toimii ja mitä sen osia siihen kuuluu niille, jotka eivät ole lukeneet kirjaa?

David Bishop: Kirjassa on suuri kaavio, joka kuvaa kaikki eri osat. Ensimmäinen metagilityn vaihe on tehdä päätös siitä, millainen muutos lähdetään toteuttamaan.

Ben Aston: Miten maksuun pääsee käsiksi?

David Bishop: Tarkoitat varmaankin aiemmin mainitsemaani Barlow'n kaaviota, joka on kirjassani. Se perustuu tutkimukseen ja kuvaa, miten päätös voidaan tehdä. Se on olennaisesti riippuvainen tiimien koosta, tuotteiden monimutkaisuudesta ja tiimien välisen vuorovaikutuksen ja keskinäisten riippuvuuksien määrästä.

Tuotteiden monimutkaisuus auttaa määrittämään, kuinka paljon riippuvuuksia eri tiimien tai kehitystyövirtojen välillä on yhden tuotteen luomiseksi. Tämä kertoo, pitäisikö käyttää hybridilähestymistapaa puhtaasti ketterän lähestymistavan sijaan.

Mitä hybridilähestymistapa tarkoittaa? Metagility sisältää vaiheet ketterien ja vesiputousmallin oletuskäytäntöjen yhdistämiseen. Se esimerkiksi määrittää, miten eri tiimit työskentelevät. Ohjelmistotiimit voivat käyttää kahden viikon sprinttejä ja päivittäisiä tilannepalavereja. Laiteohjelmistotiimit voivat käyttää 30 päivän sprinttejä ja pitää tilannepalavereja kerran viikossa.

Laitteistotiimit toimivat tyypillisesti hitaammalla ja pidemmällä 12–18 kuukauden syklillä. Ne voivat käyttää vesiputousmallia, mutta hyödyntää esimerkiksi nopeaa prototypointia, jotta ne pysyvät muiden tiimien tahdissa. Näin ne voivat tarjota tarvittavat alustat ja testausmateriaalit ilman työn estymistä. Tärkeintä on säilyttää virtaus koko prosessin ajan.

Metagility kuvaa, miltä tämä näyttää. Se kertoo, miten eri tiimit ottavat käyttöön ketteryyden tai vesiputousmallin käsitteitä. Vesiputousmallin vaiheportteja voidaan mukauttaa hybridimenetelmään tarkistus- ja tasapainotusmekanismiksi. Näin eri nopeuksilla etenevät työvirrat pysyvät synkronissa.

Menetelmä määrittelee myös käytettävät mittarit sekä ketterän työn edellyttämät vuorovaikutustavat. Ketterässä työssä puhutaan usein vuorovaikutuksesta työkalujen ja prosessien sijaan, mutta harvoin kerrotaan, mitä vuorovaikutuksen pitäisi tarkoittaa. Metagilityssä tämä jaetaan kuuteen tarkasti määriteltyyn kategoriaan menestyneimpien tapaustutkimusten perusteella. Kategoriat kuvaavat vuorovaikutustapoja, niiden käyttöönottoa ja hallintaa. Näin muodostuu yksityiskohtainen käsikirja hybridin ketterän toteutuksen hallintaan.

Ben Aston: Miten määritätte eri ketterien ominaisuuksien oikean yhdistelmän? Ihmiset suhtautuvat muutokseen yleensä kielteisesti. Miten organisaation ketteryyttä tai metagilityä lisättäessä määritetään sopiva yhdistelmä ja se, milloin nykytila riittää ja milloin prosessissa tarvitaan kehitystä tai vallankumouksellista muutosta?

David Bishop: Se palaa tieteellisen menetelmän ja osallistavan tutkimuksen hyödyntämiseen. Näin saat parhaan vastauksen. Liian usein ihmiset käyttävät intuitiota, parhaita käytäntöjä tai haastatteluja ja pyrkivät saavuttamaan yhteisymmärryksen. Siinä ei ole mitään täysin väärää, ja teemme liiketoiminnassa päätöksiä näin jatkuvasti.

Ketterä, DevOps- tai digitaalinen muutos on kuitenkin niin haastava, että tarvitaan vahvempaa lääkettä. On aika kutsua lääkäri paikalle. Voit hoitaa itseäsi kotona jonkin aikaa, mutta lopulta se ei enää riitä.

Näin epäonnistumisen toistuvan, koska konsultit ja asiantuntijat yrittivät ratkaista ongelmaa samalla tavalla kuin mitä tahansa liiketoimintaongelmaa: se mikä toimi edellisessä yrityksessä, pitäisi toimia täälläkin. Liiketoimintatutkimus, erityisesti tietojärjestelmien tutkimus, osoittaa kuitenkin, että nämä ympäristöt ovat erittäin kontekstisidonnaisia. Ne eroavat merkittävästi yrityksestä toiseen.

Tieteellisten menetelmien avulla, esimerkiksi tulkitsevalla tapaustutkimuksella, voidaan tehdä yleistyksiä tietyissä rajoissa. Voidaan selvittää, mikä siirtyy organisaatiosta toiseen ja mikä ei. Riittävän monien tapaustutkimusten, tulkitsevan tapaustutkimustekniikan ja etnografioiden avulla voidaan määrittää, mikä on yleistettävissä yritysten ja organisaatioiden välillä. Tämä vie aikaa.

Ben Aston: Kyse ei siis ole kaikille sopivasta viitekehyksestä, vaan muokattavasta viitekehyksestä. Muokattavuuden haasteena on kuitenkin tietää, onko toteutus todella metagilityä. Miten sen onnistumista arvioidaan?

David Bishop: Hyvä kysymys. Metagility sisältää myös ketterän vortisiteetin teorian. Hybridin ketterän lähestymistavan ja tiimien välisiä vuorovaikutuksia koskevien havaintojen lisäksi siihen kuuluu ketterän vortisiteetin teoria, joka syntyi tutkimuksesta.

Ketterän vortisiteetin käsite vastaa kysymykseen siitä, kuinka ketterä organisaatio on. Tämä on alan suuri kysymys. Teemme kaiken tämän ketterän muutoksen eteen, mutta mistä tiedämme, onko siitä ollut hyötyä? Mistä tiedämme, missä olemme? Miten tiedämme, että olemme kehittyneet?

Ketteryyttä ei ole aiemmin pystytty kunnolla mittaamaan. Ketterä vortisiteetti ratkaisee tämän ongelman. Se on monimutkainen käsite, jota käsittelen kirjassa yksityiskohtaisesti. Se perustuu tutkimusartikkeleihin ja tarjoaa tavan mitata onnistumista.

Ben Aston: Mitä vaikutuksia olet nähnyt organisaatioissa, jotka ovat ottaneet viitekehyksesi käyttöön? Puhuimme alussa siitä, että tavoitteena on tulla alan ykköseksi ja kilpailukykyisemmäksi. Millaisia vaikutuksia olet nähnyt?

David Bishop: Monet tapaustutkimuksemme liittyivät sulautettujen järjestelmien markkinoihin, koska se on mielestäni tällä hetkellä kiinnostavin, kuumin ja haastavin markkina. Metagilityn käsitteitä käyttöön ottaneet yritykset ovat useimmiten onnistuneet nousemaan markkinajohtajiksi tai hyvin lähelle sitä.

Se tarkoittaa yleensä markkinaosuuden kasvua, useampien laitteiden saamista markkinoille ja useampien älylaitteiden toimittamista asiakkaille kuin kilpailijat. Menestyminen uusilla markkinoilla edellyttää kriittisen markkinaosuuden saavuttamista ennen kilpailijoita. Tämä tarkoittaa innovatiivisen teknologian omaksumista ja sen viemistä markkinoille muita nopeammin.

Ketterä toiminta on paras tapa tehdä tämä, ja erityisesti metagility on mielestäni tehokas. Menestyneimmät tapaustutkimuksemme onnistuivat lyhentämään kehityssyklejä mahdollisimman paljon, säilyttämään halutun laadun ja asiakastyytyväisyyden sekä viemään innovatiiviset tuotteet markkinoille ennen kilpailijoita.

Ben Aston: Missä olet nähnyt metagilityn tai sen käyttöönoton epäonnistuvan? Miksi näin on käynyt? Tiedän, että puhut johdon merkityksestä prosessissa, mutta mitä haasteita olet nähnyt?

David Bishop: Näen kaksi erityistä kohtaa. Ensimmäinen koskee johdon sitoutumista ja tukea. Ilman johdon hyväksyntää ja tukea ei päästä pitkälle. Tämä pätee kaikkiin muutoksiin, olipa kyse digitaalisesta muutoksesta, ketterästä muutoksesta tai jostakin muusta. Muutos alkaa huipulta, ja johdon on ymmärrettävä tavoite.

Analyytikon tehtävänä on esittää vakuuttava liiketoimintaperustelu, jotta johto ymmärtää vaikutukset tulokseen ja muutoksen tarkoituksen. Kyse ei ole vain ihmisten tekemisestä tyytyväisiksi, vaan kilpailukyvystä, tuloksen parantamisesta ja mahdollisesti johdon palkkioiden kasvattamisesta.

Toinen syy on heikko vaatimustenhallinta. Ketterässä muutoksessa keskitytään usein kehitys- ja testaustiimeihin: tiimit perustetaan, sprintit määritellään ja tilannepalaverit järjestetään. Vaatimuksiin ja liiketoiminta-analyytikoihin tai ketterässä maailmassa tuotteen omistajiin kiinnitetään liian vähän huomiota.

Kun liiketoiminta-analyytikosta tulee tuotteen omistaja, hänen on muutettava tapaa, jolla vaatimuksia kehitetään. Vesiputousmaailmassa puhutaan vaatimusten keräämisestä. Ketterässä maailmassa vaatimuksia kehitetään. Ero on merkittävä.

Vesiputousympäristössä liiketoiminta-analyytikko yrittää määrittää kaiken etukäteen ja pelkää unohtavansa jotakin. Ketterässä ympäristössä seuraava iteraatio tarjoaa aina uuden mahdollisuuden. Kun vaatimuksia vain kerätään ja ideoidaan, niitä syntyy jatkuvasti lisää. Kaikkien priorisointi muuttuu mahdottomaksi, julkaisut täyttyvät, käyttöasteeltaan vähäisiä ominaisuuksia rakennetaan ja tekninen velka kasvaa hallitsemattomaksi. Näin ketterät muutokset epäonnistuvat.

Mikä tahansa viitekehys, myös metagility, voi epäonnistua, jos vaatimusten kehittämisen tapaa ei muuteta. Liiketoiminta-analyytikoiden on opittava toimimaan todellisina ketterinä tuotteen omistajina, tehtävä yhteistyötä asiakkaan kanssa ja purettava vaatimuksia ylhäältä alaspäin asiakkaan tarpeiden perusteella. Aivoriihiä on vältettävä.

Ben Aston: Olen kokenut tämän liian monta kertaa. Jos vaatimusten keräämistä käsitellään todella vaatimusten keräämisenä, prosessi voi kestää päiviä tai viikkoja ja vaatimuksia tulee aina lisää. Jos metagility on sinulle uusi ja lähestymistapa kuulostaa järkevältä, mikä olisi ensimmäinen askel organisaatiossa, joka haluaa hyötyä siitä eniten?

David Bishop: Ensimmäisenä on luotava uusi asiakassuhde. Ketterässä manifestissa puhutaan asiakasyhteistyöstä sopimusneuvottelujen sijaan. Tutkimuksemme perusteella sopimusneuvottelu ja asiakasyhteistyö ovat kuitenkin pohjimmiltaan sama prosessi.

Neuvottelu tapahtuu organisaation kaikilla tasoilla. Kyse ei ole vain juristeista ja johtajista neuvottelemassa asiakkaan kanssa. Neuvottelu on jatkuvaa yhteistyötä sidosryhmien, tuotejohtajien, tuotteen omistajien, projektipäälliköiden, kehitystiimien, Scrum-tiimien ja asiakkaan organisaation muiden sidosryhmien välillä.

Asiakkaan kanssa on luotava yhteistyöhön perustuva suhde. Asiakkaan on osallistuttava testaamiseen, erityisesti jos innovatiivinen tuote halutaan saada nopeasti markkinoille. Metagilityssä kerromme johdolle, ettei kyse ole suunnitelmasta vaan visiosta.

Menestyneimmillä tapaustutkimuksilla oli visio siitä, mihin ne halusivat markkinoilla päästä. Ne päättivät, minkä asiakkaiden kanssa ne työskentelevät ja minkä kanssa eivät. Kaikkia asiakkaita ei tarvitse hyväksyä vain siksi, että halutaan kasvattaa tuloja. Osa asiakkaista on käännytettävä pois, jos he eivät ole valmiita yhteistyöhön ja pitkäaikaisen menestyksen kannalta välttämättömään osallistumiseen.

Sopivien asiakkaiden löytäminen, vahvan yhteistyösuhteen rakentaminen ja tavoitteen määrittäminen ovat todennäköisesti ensimmäiset askeleet.

Ben Aston: Viisaita neuvoja. Liian usein ajattelemme, että otamme vastaan kaiken, mitä ovesta tulee. Jos haluamme tuottaa todellista arvoa loppukäyttäjille ja asiakkaille, tarvitsemme kuitenkin oikean yhteistyötä tukevan toimintamallin. Luottamukseen perustuvassa toimeksiannossa voimme sanoa, ettemme vielä tiedä tarkalleen, mitä teemme, mutta selvitämme sen yhdessä parhaan tuloksen saavuttamiseksi.

Kiitos paljon, David, että liityit seuraamme ja kerroit metagilitystä.

David Bishop: Kiitos paljon.

Ben Aston: Haluaisin kuulla, mitä ajattelet. Oletko lukenut kirjan metagility? Kerro mielipiteesi kommenteissa. Jos et ole vielä tutustunut siihen, lisäämme litterointiin linkin. David, jos ihmiset haluavat kuulla lisää metagilitystä ja kirjastasi, mistä he löytävät lisätietoa?

David Bishop: Voit hakea Googlesta sanalla metagility, jolloin löydät paljon resursseja. Voit myös vierailla osoitteessa Agileworx.com (Agile-worx.com) ja tutustua yritykseemme sekä siihen, mitä pyrimme tekemään. Tarjoamme myös kursseja. Kurssit järjestetään yleensä kasvokkain, mutta niitä on siirretty syksyyn.

Ajantasaisen aikataulun löydät osoitteesta metagility.technology. Voit tutustua kurssien aikatauluun ja ilmoittautua mukaan. Voit myös ottaa minuun yhteyttä osoitteessa David@agileworx.com (Agile-worx.com). Kuulen aina mielelläni ihmisistä ja tarkistan sähköpostini jatkuvasti.

Ben Aston: Hienoa. Kiitos paljon, David. Jos haluat oppia lisää ja kehittyä työssäsi, liity seuraamme. Liity DPM-jäsenyyden yhteisöömme osoitteessa thedigitalprojectmanager.com/membership. Saat käyttöösi Slack-tiimimme, jossa keskustelemme juuri tällaisista aiheista, sekä mallipohjamme, työpajamme, kysy mitä tahansa -tilaisuudet, vastaanottoajat, e-kirjat ja paljon muuta. Jos pidit tämän päivän jaksosta, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com. Ensi kertaan asti, kiitos kuuntelusta.