Ketteryden skaalaaminen (Giovanni Aspronilta Zuhlke Engineering Limited -yrityksestä)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmistolla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston:

Tervetuloa DPM-podcastiin, jossa menemme teoriaa pidemmälle ja annamme käytännössä toimivia neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, Digital Project Managerin perustaja. Kaikki ovat innostuneita ketteryydestä, mutta miten se saadaan toimimaan useiden tiimien tai projektien välillä? Miten sitä voidaan nopeuttaa, missä se voi mennä pieleen ja miten ongelmat voidaan estää jo etukäteen? Kuuntele tämänpäiväinen podcast ymmärtääksesi, miten ketterää toimitusta voidaan skaalata ja miten ketteryys saadaan toimimaan suuressa mittakaavassa. Tämän podcastin tarjoaa Clarizen, yritysten projektien ja projektisalkkujen hallintaohjelmistojen johtava toimittaja. Lisätietoja löydät osoitteesta clarizen.com.

Tänään vieraanani on Giovanni Asproni. Hän toimii pääkonsulttina Zuhlke Engineering Limitedissä. Ääntämykseni ei ehkä ollut täydellinen, mutta hän työskentelee Lontoossa. Hän on ohjelmistoarkkitehti, ohjelmoija, valmentaja ja konsultti, jolla on runsaasti kokemusta useilta eri toimialoilta, kuten televiestinnästä, pankkialalta sekä öljy- ja kaasualalta. Hän on osallistunut moniin konferensseihin ja ollut mukana kirjoittamassa useita kirjoja. Giovanni, kiitos kun liityit seuraamme.

Giovanni:

Hei. Kiitos kutsusta.

Ben Aston:

Miten yrityksesi nimi pitäisi lausua?

Giovanni:

Se on itse asiassa sveitsiläinen nimi, ja se lausutaan Zuhlke.

Ben Aston:

Aivan, siitähän se selvisi. En olisi kyllä osannut lausua sitä oikein.

Giovanni:

Minäkin lausun sen jatkuvasti väärin, joten älä huolehdi.

Ben Aston:

Selvä. Kerro hieman, mitä parhaillasi työskentelet. Puhuimme siitä jo ennen nauhoitusta, mutta miltä tavallinen päiväsi näyttää?

Giovanni:

Tavallinen päiväni on nykyään melko kiireinen. Aloitin kesäkuun alussa uuden projektin, jossa noudatan itse omia neuvojani, mikä on varsin viisasta. Olemme tehneet Zuhlken suuren asiakkaan kanssa arvioinnin erittäin laajasta ohjelmasta. Puhumme noin 500 ihmisestä ja 57–60 tiimistä. Nyt toteutamme osaa suosituksista, eli tarjoamme heille järjestelmän, jonka avulla voidaan kerätä projekti- ja ohjelmamittareita ja hallita koko kokonaisuutta paremmin. Työ on melko kiireistä: vastaan teknisestä johtamisesta ja vaatimuksista, raportoin asiakkaan organisaation kaikille johtotasoille ja kirjoitan välillä myös koodia.

Ben Aston:

Kerro hieman arviointiprosessista, jonka käytte läpi. Minusta on kiinnostavaa, ettette vain mene yritykseen ja sano, että heidän pitää ottaa Scrum käyttöön ja yritä sitten viedä sitä läpi, vaan prosessiin kuuluu arviointi. Pitääkö tämä paikkansa?

Giovanni:

Kyllä.

Ben Aston:

Miltä se näyttää käytännössä?

Giovanni:

Arvioinnissa yritämme ensisijaisesti ymmärtää, mitä organisaatiossa tapahtuu. Keskustelemme ihmisten, tiimien edustajien ja kaikilla tasoilla työskentelevien johtajien kanssa ja yritämme selvittää, mitä käytännössä tapahtuu. Teemme esimerkiksi prosessien katselmointeja, tarkastelemme tiimien käyttämiä toimintatapoja ja sitä, miten he toimittavat koodia järjestelmään sekä mitä he tekevät laadun varmistamiseksi. Keskustelemme johdon kanssa ymmärtääksemme heidän näkemyksensä tilanteesta. Näin muodostamme kokonaiskuvan, sillä suurilla projekteilla on paljon yhteisiä piirteitä, mutta niiden yksityiskohdat ovat yleensä hyvin erilaisia.

Ben Aston:

Miten erilaisia suosituksenne yleensä ovat suurten yritysten arviointien jälkeen, erityisesti toteutuksen osalta? Palaavatko ne aina lopulta samoihin perusasioihin?

Giovanni:

Se riippuu siitä, mitä löydämme. Jotkin asiat toistuvat, koska ihmiset tekevät usein samoja virheitä. Kun yritykset kasvattavat ohjelmansa hyvin suureksi, esimerkiksi sadan, kahdensadan tai tässä tapauksessa viidensadan ihmisen kokonaisuudeksi, ne tekevät sen yleensä nopeuttaakseen toimintaa. Usein niillä ei kuitenkaan ole tarvittavia välineitä sen ymmärtämiseen, tuottaako kasvu todellista hyötyä.

Ben Aston:

Kun puhut välineistä, mitä työkaluja käytät arvioidaksesi, toimiiko lisäresurssien avulla tehty skaalaaminen vai ei?

Giovanni:

Tarkastelemme useita asioita. Yritämme selvittää, ymmärtävätkö kaikki, mitä heidän pitäisi tehdä ja vetävätkö he samaan suuntaan. Ihmiset näkevät projektin tavoitteet yllättävän usein eri tavoin. Tarkastelemme mittareiden käyttöä: kun organisaatiossa on tiimejä ja ihmisiä, miten tiedetään, että työ etenee nopeammin? Ei vain tuntemusten vaan todellisen tiedon perusteella. Tarkastelemme myös järjestelmän suunnittelua ja arkkitehtuuria sekä sitä, sopiiko se tiimien rakenteeseen. Suurissa projekteissa viestintäkanavat muuttuvat usein hyvin muodollisiksi, jolloin ihmiset eivät enää pysty ratkaisemaan ongelmia nopeasti.

Ben Aston:

Mitä neuvoja antaisit projektipäälliköille ja muille ketteryyttä aloittaville? Mikä olisi tärkein vinkkisi asiakkaalle, joka ei ole aiemmin työskennellyt ketterästi mutta haluaa nyt olla ketterä?

Giovanni:

Tärkeintä on ymmärtää ja selkeyttää odotukset. Kun joku sanoo haluavansa projektin olevan ketterä, pitää kysyä: mitä sillä tarkoitat? Mikä tarve taustalla on? Minkä ongelman yrität ratkaista? Ketteryys ei ole tavoite, vaan keino jonkin tavoitteen saavuttamiseen. Ihmiset päättävät usein haluavansa olla ketteriä, koska ovat kuulleet muiden yritysten tekevän niin ja saavuttavan hienoja tuloksia nopeasti. Silloin asian ydin helposti unohtuu. Kyse on odotusten hallinnasta ja selkeyttämisestä.

Ben Aston:

Pidän tuosta paljon. Tavoite ei ole prosessi, vaan arvon tuottaminen tehokkaammin ja tulosten saavuttaminen. Kiitos hyvästä neuvosta. Mitä työkaluja käytät arvioidessasi ja auttaessasi tiimejä toimimaan ketterämmin?

Giovanni:

Käytän hyvin analogista työkalua: muistikirjaa. Kun keskustelen ihmisten kanssa projektin arvioimiseksi, en yleensä käytä tietokonetta. Jos avaat kannettavan tietokoneen, se voi muodostaa esteen sinun ja toisen henkilön välille. Muistikirjaan kirjoittaminen on paljon vähemmän uhkaavaa. Kynä ja muistikirja ovat tärkeimmät laitteistotyökaluni. Ohjelmistoista käytän Scapplea. Sen avulla voin kirjoittaa asioita ja yhdistää niitä toisiinsa ilman, että kaikki muodostuu vain puumaiseksi rakenteeksi. Se on enemmänkin pensas tai metsä.

On tärkeää kuunnella ihmisten sanojen lisäksi myös tilannetta. Onko huoneessa rento vai jännittynyt tunnelma? Sanovatko ihmiset jotain, mihin he eivät oikeasti usko? Myös turvallinen ympäristö on arvioinnissa erittäin tärkeä. Kun keskustelen esimerkiksi kehittäjien kanssa projektin tilanteesta, varmistan, etteivät johtajat ole samassa huoneessa. Teen saman johtajien kanssa, sillä vaikka yritys sanoisi olevansa avoin, käytäntö on yleensä monimutkaisempi. Turvallisuus on ratkaisevan tärkeää.

Ben Aston:

Entä ketterien projektien ohjelmistotyökalut? Suositteletko jotain tiettyä työkalua?

Giovanni:

Se riippuu tilanteesta. Jos kaikki ovat aina toimistolla, valkotaulu toimii hyvin. Valkotaulusta voi ottaa kuvia, jos asioita pitää jakaa verkossa. Jos tiimi työskentelee eri paikoissa tai osa ihmisistä työskentelee välillä kotoa, sähköiset työkalut ovat parempia. Yksi yleinen työkalu on Jada. En erityisesti pidä siitä, koska se on hidas ja siinä on omat ongelmansa, mutta eri paikoissa työskentelevälle tiimille se on parempi kuin valkotaulu. Minulle kyse on siis aina tilanteesta riippuvasta valinnasta.

Ben Aston:

Oletko löytänyt viime aikoina muita kiinnostavia työkaluja?

Giovanni:

En oikeastaan. En edes etsi niitä aktiivisesti. Olen elämässäni ja työssäni vaiheessa, jossa en etsi erityisiä työkaluja. Yksinkertaisena pitäminen on usein paras ratkaisu. Suosittelen yksinkertaisinta työkalua, joka tekee tarvittavan työn.

Ben Aston:

Puhutaan sitten artikkelistasi, joka käsittelee ketteryyden skaalaamista. On hyvin tunnettua, ettei ihmisten lisääminen ohjelmistoprojektiin välttämättä lisää tuottavuutta. Usein tuottavuus jopa laskee, kun hämmennys lisääntyy, työnjako vaikeutuu ja integrointi muuttuu ongelmalliseksi. On siis oltava parempi tapa saada enemmän aikaan. Artikkelissasi käsitellään skaalaamisen sääntöjä ja edellytyksiä sekä tiimirakennetta. Jos et ole vielä lukenut artikkelia, suosittelen tutustumaan siihen osoitteessa thedigitalprojectmanager.com.

Miksi ketteryyden skaalaaminen on tärkeää?

Giovanni:

Skaalaamisesta kannattaa tietää, koska siihen törmää ennemmin tai myöhemmin. Erityisesti suurissa yrityksissä projektit kasvavat helposti osallistujamäärältään suuriksi. Yleinen suositukseni on: älä skaalaa heti. Selvitä ensin nykyinen tilanteesi. Miksi haluat skaalata? Mikä on syy? Oletko varma, että se on mahdollista? Jos skaalaamisen edellytyksiä ei ole kunnossa, lopputuloksena on vain suurempi sotku. Olen nähnyt suuren projektin, jossa oli 1 300 ihmistä ja 2 000 ohjelmistovarastoa. Se oli valtava sotku. Tällaisissa projekteissa hyvän työn tekemiseen tarvitaan usein alle kaksikymmentä tai kolmekymmentä ihmistä. En liioittele. Työ pitää ensin tehdä vaikuttavasti ja tehokkaasti ennen kuin sitä kasvatetaan.

Ben Aston:

Kun puhumme ketteryyden skaalaamisesta, keskeinen viesti näyttää olevan, että kokonaisuus kannattaa pitää mahdollisimman pienenä ja kevyenä. Näin voidaan maksimoida tehokkuus, säilyttää tavoitteen selkeys ja varmistaa arvon tuottaminen. Kun työskentelet viidensadan ihmisen organisaation kanssa, onko yksi lähestymistapa kaikille sopiva vai tarvitsevatko eri ihmiset ja tiimit erilaisia toimintamalleja?

Giovanni:

Yksi ratkaisu ei koskaan sovi kaikille. Erityisesti suurissa projekteissa tiimeillä on erilaiset tarpeet, mieltymykset ja työskentelytavat. Jonkin verran yhdenmukaisuutta tarvitaan kuitenkin, jotta kokonaisuudesta voidaan muodostaa kuva. Ehdotukseni on antaa tiimien työskennellä omalla suosimallaan tavalla, mutta määrittää yhtenäiset rajapinnat esimerkiksi raportointiin, edistymisen esittämiseen ja läpinäkyvyyteen. Muuten johdon voi olla mahdotonta ymmärtää, mitä kokonaisuudessa tapahtuu.

Ben Aston:

Miltä hyvä ja huono skaalaaminen näyttävät?

Giovanni:

Huono skaalaaminen tapahtuu yleensä silloin, kun joku johtoketjun yläpäässä päättää kaiken olevan liian hidasta ja heittää ongelman kimppuun lisää ihmisiä. Toinen esimerkki on kapasiteettiin perustuva suunnittelu: ajatellaan, että sadan henkilön työmäärä voidaan ratkaista palkkaamalla sata ihmistä ja tekemällä työ vuodessa. Se ei toimi niin. Tiimeissä pitää olla oikeat ihmiset ja oikeanlaiset taidot. Paras tapa aloittaa skaalaaminen on ottaa tiimit ja kokeneet tekniset ihmiset mukaan keskusteluun: pystyttekö työskentelemään muutaman lisähenkilön kanssa, tarvitsetteko apua ja riittääkö työtä uusille ihmisille? Työn tekijät tietävät parhaiten, tarvitsevatko he apua.

Ben Aston:

Eli tietoisuus on tärkeää.

Giovanni:

Kyllä. Lisäisin vielä, että ihmisten pitää ymmärtää todellinen roolinsa. Ohjelmistoprojektissa kehittäjät, jotka kirjoittavat koodia, ja järjestelmän käyttäjät ovat välttämättömiä. Kaikki muut ovat tässä mielessä valinnaisia, myös projektipäälliköt, konsultit ja testaajat, vaikka he voivat olla erittäin hyödyllisiä. Heidän tehtävänsä on tehdä kehittäjistä vaikuttavampia ja tehokkaampia. Projektipäällikön kannattaa siis kysyä tiimiltä, mitä se tarvitsee ja miten projektipäällikkö voi auttaa.

Ben Aston:

Miltä ketteryyden skaalaaminen parhaimmillaan näyttää?

Giovanni:

Olen nähnyt sen toimivan hyvin vain kerran tai kahdesti, eikä kyse ollut kovin suurista järjestelmistä. Yhdessä tapauksessa oli viisi tai kuusi tiimiä ja noin viisikymmentä kehittäjää ja testaajaa. Ihmiset tiesivät, mitä tekivät ja mikä heidän paikkansa kokonaisuudessa oli. He tiesivät myös, kenen kanssa toisissa tiimeissä piti puhua. Viestintä oli osittain muodollista mutta pääosin epämuodollista. Tiimit olivat silti pieniä. Suurissa projekteissa olen yleensä nähnyt merkittäviä ongelmia, ja ne olisivat selvinneet kymmenesosalla ihmisistä. Skaalaaminen oli tehty vääristä syistä, eikä kukaan ollut ensin selvittänyt, toimiko se.

Ben Aston:

Mitä mieltä olet valmiista skaalatuista ketteristä viitekehyksistä, kuten laajamittaisesta Scrumista?

Giovanni:

Tiedän tilanteita, joissa ne ovat toimineet, mutta vain silloin, kun ympäröivä toimintaympäristö sopii viitekehykseen. Yleisesti en pidä valmiista viitekehyksistä, koska ne yrittävät muovata projektin omaan muotoonsa. Jokainen viitekehys olettaa tietyn ympäristön. Jos ympäristö ei sovi siihen, edessä on vaikeuksia. Viitekehykset keskittyvät usein liikaa rakenteeseen eivätkä riittävästi siihen, mitä ihmiset päivittäin tekevät. Ne voivat antaa johdolle hallinnan tunteen, mutta eivät välttämättä auta työn tekijöitä.

Giovanni:

Kun otin kerran äärimmäisen ohjelmoinnin käyttöön tiimissä, emme yrittäneet ottaa kaikkia käytäntöjä kerralla käyttöön. Sovimme tavoitteista, aloitimme yhdestä tai kahdesta arvoa tuottavasta käytännöstä, opimme niistä ja rakensimme niiden päälle. Tämä on tärkeää myös suurten viitekehysten kanssa. Kun asioita on liian paljon opittavana samanaikaisesti, ihmiset kuormittuvat. Ihmiset eivät voi oppia kaikkea kerralla. Pienestä aloittaminen, prosessin kehittäminen ja uusien käytäntöjen lisääminen tarpeen mukaan on järkevämpi lähestymistapa.

Ben Aston:

Projektipäälliköille, tuottajille ja tuotepäälliköille: mikä olisi tärkein asia, jonka he voivat tehdä auttaakseen tiimiä?

Giovanni:

Ymmärtää, mitä tiimi tarvitsee heiltä. Kysy, miten voit auttaa. Oleta myös, että projektissa työskentelevät ihmiset tekevät parhaansa omassa tilanteessaan. Älä arvaile heidän puolestaan, vaan kysy heiltä. Projektipäälliköiden tehtävänä on huolehtia esimerkiksi budjetista, aikataulusta ja dokumentaatiosta, joita kaikki tiimin jäsenet eivät halua tehdä. Kun annat tiimille suojaa ja puolustat sitä asiakkaan edessä, tiimi arvostaa sitä.

Ben Aston:

Arvioista puhuttaessa älä pakota kehittäjiä pienentämään arviota vain siksi, että se ei miellytä sinua. Jos arvio on liian pitkä tai kallis, kysy aidosti, miksi. Älä pyydä uutta pienempää lukua, koska silloin et enää pyydä arviota vaan sitoumusta. Projektipäällikön tehtävänä on viestiä selkeästi tiimien ja asiakkaiden välillä sekä tehdä näkyväksi, mitä voidaan toimittaa, millä aikataululla ja millä kustannuksilla.

Kiitos paljon, Giovanni, että liityit seuraamme.

Giovanni:

Kiitos paljon. Oli ilo olla mukana.

Ben Aston:

Mitä mieltä sinä olet? Oletko kokeillut ketteryyden skaalaamista? Miten se sujui? Mikä toimi ja mikä ei? Kerro kommenteissa. Jos haluat oppia lisää ja kehittyä työssäsi, liity DPM-jäseneksi. Osoitteessa thedigitalprojectmanagement.com/membership saat käyttöösi Slack-tiimin, mallipohjia, työpajoja, vastaanottoaikoja, sähköisiä kirjoja ja paljon muuta. Jos pidit kuulemastasi, tilaa podcast ja käytä pari minuuttia rehellisen arvostelun jättämiseen DPM-podcastista Apple Podcastsissa. Ensi kertaan asti, kiitos kuuntelusta.