Kiireisyyden mittaaminen vs. tulosten mittaaminen

 

Lue litterointi:

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

Galen Low: Pikaesimerkki: projektisi on puolivälissä, ja kaikki mittarisi näyttävät hyvältä. Toimittajasi on käyttänyt sovitun tuntimäärän, ja tiimisi nopeus sekä käyttöaste ovat täsmälleen suunnitellulla tasolla.

Mutta vaikka projektisi näyttää paperilla terveeltä, tuote ei edelleenkään täytä odotuksia kohderyhmähaastatteluissa ja käyttäjätestauksessa. Teknologia, jota projektin toimeenpaneva sponsori vaati käytettäväksi, vanhenee nopeasti, mikä vaikeuttaa muutosten tekemistä. Tiimisi moraali on matalalla: kun pyydät heiltä ratkaisuja, he kohauttavat olkapäitään ja sanovat tehneensä sen, mitä heiltä pyydettiin, annetussa ajassa.

Miten projektisi voi siis olla terve, vaikka sen tuotos ei tuota sille tarkoitettua arvoa?

Jos olet huomannut, että projektimittarisi mittaavat enemmän kiireisyyttä kuin arvoa, jatka kuuntelemista. Perehdymme siihen, miten projektitiimit voivat käytännössä mitata arvoa, ja tarkastelemme ajatuksia siitä, miten kannustin voidaan siirtää käytetyistä tunneista luotuun arvoon.

Hei kaikki, kiitos kun kuuntelette. Nimeni on Galen Low, ja työskentelen Digital Project Managerissa. Olemme digitaalisten ammattilaisten yhteisö, jonka tavoitteena on auttaa toisiamme kehittämään osaamistamme, kasvattamaan itseluottamustamme ja verkostoitumaan, jotta voimme vahvistaa projektinhallinnan arvoa digitaalisessa maailmassa. Jos haluat kuulla siitä lisää, siirry osoitteeseen thedigitalprojectmanager.com.

Selvä. Tänään puhumme projektin terveyden ja edistymisen mittaamisen sekä projektin onnistumisen mittaamisen välisestä erosta. Riittääkö siis tiimin nopeuden ja kustannustehokkuuden seuraaminen? Vai onko meidän projektijohtajina vastuullamme mitata myös projektien tuloksia ja vaikutuksia?

Minulla on tänään seurassani Fred Fowler — tason 3 sertifioitu Scrum Master, joka on julkaissut useita kirjoja Scrum-menetelmästä, järjestää noin 2 000 jäsenen Silicon Valley Professional Scrum -tapaamisryhmää, johtaa vastaavaa Scrum-yhteisöä Shanghaissa Kiinassa ja järjesti ensimmäisen Silicon Valley Scrummit -konferenssin. Toisin sanoen henkilö, joka tietää Scrumista yhtä jos toista.

Tervetuloa, Fred!

Fred Fowler: Hei! Kiitos, että kutsuit minut ohjelmaan.

Galen Low: Hienoa saada sinut tänne.

Fred Fowler: Esittelen itseni Scrum-tyypiksi. Jotkut voisivat sanoa, että olen scrumcious.

Galen Low: Se on parempi kuin jos kutsuisin sinua Frediksi, joka on scrum-kasvuston pohjalla.

Fred Fowler: Scrum-sanalla voi leikitellä monella tavalla. Voit olla scrumbag ja vaikka mitä. Joka tapauksessa, anna tulla.

Galen Low: Niinpä. Mahtavaa. Sinulla on todella kiinnostava tausta, ja uskon, että se antaa kuuntelijoillemme paljon kontekstia näkemyksistäsi projektimittareihin. Jos ymmärsin oikein, aloitit tietokoneohjelmoijana, siirryit sitten politiikkaan, sinusta tuli pormestari ja sen jälkeen tietohallintojohtaja, ennen kuin aloit käyttää harvinaista tason 3 Scrum Master -sertifiointiasi muiden auttamiseen.

Haluaisin siis kuulla hieman matkastasi ja siitä, miten kokemuksesi ovat muokanneet tapaasi tarkastella asioita nykyään.

Fred Fowler: Sanoisin, että urani muistutti flipperikoneen sisällä olemista.

Aloitin ohjelmoijana vuonna 1980. Se oli muinaista aikaa, ja työskentelin koneella, joka oli niin suuri ja painava, että sen siirtämiseen tarvittiin käytännössä erikoislaitteet, ja joka oli vähemmän tehokas kuin nykyinen tavallinen puhelin, älypuhelimestasi puhumattakaan. Käytimme sitä puolijohdeyhtiön yhden liiketoimintayksikön pyörittämiseen, ja opin siellä taitoni.

Siirryin eteenpäin, koska Piilaaksossa elettiin alkuaikoja, mikä tarkoitti paljon vapaaehtoista epävakautta. Urani ensimmäisten kahdeksan vuoden aikana työskentelin viidessä eri yrityksessä, ja epävakaus oli, kuten sanoin, uskomatonta. Lopulta ajattelin, että tarvitsen jonkinlaista työturvaa, joten minun pitäisi työskennellä itselleni.

Ryhdyin konsultiksi ja työskentelin seuraavien kymmenen vuoden aikana 60 eri yrityksessä. Tein jälleen samaa työtä: yritin aina soveltaa teknologiaa liiketoimintaongelmien ratkaisemiseen, ja pohjimmiltaan siitä kaikessa on kyse. Sitten eräs yritys, jolle työskentelin konsulttina, teki minulle tarjouksen, josta en voinut kieltäytyä.

Päädyin johtamaan heidän IT-toimintojaan ja toimimaan tietohallintojohtajana. Otin käyttöön monia tekniikoita, jotka osoittautuivat lopulta Scrum-tekniikoiksi, vaikka en silloin tajunnut sitä. Annoimme ihmisille valtuudet ratkaista ongelmia ja perustelimme työn sijoituksen tuoton perusteella.

Noina päivinä tein monia projekteja, jotka muovasivat koko käsitystäni hankkeiden organisoinnista. Monista asioista olen ylpeä. Yritys oli käyttänyt paljon aikaa verkkosivuston rakentamiseen suuren, kaikkien tunnistaman kolmikirjaimisen tietokoneyrityksen kanssa.

Se maksoi tälle yritykselle neljännesmiljoona dollaria melko surkean verkkokaupparatkaisun tekemisestä. Joka tapauksessa osallistuin hankkeeseen ja näin, että siinä oli valtavasti parantamisen varaa. Organisoin projektin ja pitkät Scrum-työjonot.

Meillä oli mukana kaksi erilaista teknologiaa. Toisena oli vanha IBM:n minitietokone, jota kutsuttiin tuolloin AS/400:ksi. Se muodosti taustajärjestelmän, mutta tarvitsimme käyttöliittymän. Matkustin Kiinaan ja löysin sieltä pienen, kunnianhimoisen yrityksen, joka rakentaisi käyttöliittymän. Järjestimme työn niin, että yhdysvaltalainen tiimi teki taustajärjestelmän ja kiinalainen tiimi käyttöliittymän. Meidän tarvitsi vain selvittää, miten saisimme nämä kaksi alustaa keskustelemaan keskenään.

Se osoittautui melko yksinkertaiseksi. Korvasimme neljännesmiljoonan dollarin työn verkkosivustolla, joka tuotti kuuden kuukauden sisällä 40 prosenttia yrityksen liiketoiminnasta. Sen rakentamiseen käytettiin 14 000 dollaria. 14 000 dollaria. Se oli kuitenkin yksinkertaista: annettiin teknologiaa ymmärtäville ihmisille ongelma ratkaistavaksi ja annettiin heidän ratkaista se.

Tiimejä voi olla eri puolilla maailmaa. Se sopii. Sinun on vain hallittava sitä, miten ne toimivat yhdessä.

Galen Low: Siinä se. Kevyet tiimit, datan sopimus ja menoksi.

Fred Fowler: Aivan. Ja ratkaisevaa oli ymmärtää, mitä kannattaa mitata.

Kun puhutaan ulkoistetuista tiimeistä ja kaikesta siihen liittyvästä, kaikki hermostuvat: miten tiedämme, mitä he tekevät? Siksi haluamme kaikenlaisia työkaluja mitataksemme, kuinka kovasti he työskentelevät ja kuinka kiireisiä he ovat. Haluamme heidän olevan koko ajan kiireisiä.

Arvaa mitä? Sillä ei ole merkitystä. Sillä ei ole väliä, ovatko ulkoistetut ihmiset kiireisiä vai eivät. Se ei ole tärkeää. Tärkeää on se, mitä he todella toimittavat, eli heidän toimittamansa arvo. Sitä sinun pitäisi mitata. Unohda ihmisten ajanottaminen. Ei ole väliä, jos sinulla olisi esimerkiksi yli 200 ihmistä työskentelemässä kahdeksan tai kymmenen tuntia päivässä kahden vuoden ajan verrattuna viiden tai kuuden, ehkä kymmenen ihmisen tiimiin, joka työskentelee normaalit työajat yhden vuoden ajan. Kumpi mielestäsi tuottaisi enemmän arvoa?

Kävi ilmi, että 200 ihmistä työskenteli kaksi vuotta ja loi healthcare.gov-sivuston, joka oli vuosia sitten rakennettu verkkosivusto ja osoittautui täydelliseksi katastrofiksi.

Sen piti toteuttaa Obaman terveydenhuoltouudistus. Se kaatui ja epäonnistui, koska näitä 200 ihmistä mitattiin sen perusteella, kuinka kiireisiä he olivat. Seuraavan vuoden ajan työskennelleet kymmenen ihmistä kirjoittivat koko järjestelmän uudelleen ja saivat sen toimimaan. He tuottivat huomattavasti enemmän arvoa kuin ne 200 ihmistä.

Galen Low: Sukelletaan tähän, koska tämä on mielestäni valtavan tärkeä asia. Mainitsit yhden syyn sille, miksi mittaamme kiireisyyttä, mutta omassa maailmassani, jossa tulen toimisto- ja konsulttitaustasta, kaikki pyörii laskutettavien tuntien ja käyttöasteen ympärillä. Mittaamme, kuinka monta virhettä korjasimme tai kuinka monta tehtävää suoritimme.

Miksi meillä on taipumus mitata kiireisyyttä?

Fred Fowler: Se on yksinkertaista. Se on helppo mitata. Tarvitset vain kellon mitataksesi, kuinka kiireisiä ihmiset ovat. Tarvitset vain kalenterin selvittääksesi, noudattavatko ihmiset määräaikoja. Se on helppo mitata. Ja tiedätkö mitä? Se on palkkauksen perusta.

Mainitsit laskutettavat tunnit. Se on suuri harhaluulo. Ajatus siitä, että ihmisten aika on arvokasta. Ihmisten aika on heille itselleen arvokasta, mutta sinulle arvokasta on se, mitä he tekevät tuolla ajalla. Olisi paljon parempi, jos maailmassa olisi hyvä mittatikku ihmisten käyttämän ajan tulosten mittaamiseen.

Kun puhun yritysten kanssa, yritän kertoa niille, että tärkeintä on selvittää, mikä luotavan asian arvo on, ja jakaa se järkeviin, mitattaviin osiin. Sen jälkeen edistymistä voidaan mitata luodun arvon perusteella. Lean-ajattelussa on ajatus vähimmäiskelpoisesta tuotteesta.

Teet tuotteesta sen verran kuin on tarpeen, jotta saat jotain asiakkaan käsiin. Miksi se on hyvä ajatus? Koska asiakkaan käsissä olevalla asialla on arvoa. Asiakas voi kertoa, kuinka arvokas se on. Näin voit arvioida, oliko luotu arvo sen kulun arvoinen, joka sen luomisesta aiheutui.

Jos sovelluksen rakentaminen maksaa puoli miljoonaa dollaria, onko se hyvä sijoitus? Se riippuu siitä. Jos sovellus julkaistaan iTunesissa ja sitä ladataan kolme miljoonaa kappaletta kahdella dollarilla kappaleelta, olet ansainnut kuusi miljoonaa dollaria puolen miljoonan dollarin sijoituksella.

Se on aika hyvä kauppa. Tekisin sen koska tahansa. Jos sama puoli miljoonaa käytetään sovelluksen julkaisemiseen iTunesissa ja sitä ladataan vain 20 000 kertaa kahdella dollarilla, sanotaan vaikka 25 000 kertaa, olet käyttänyt 500 000 dollaria luodaksesi 50 000 dollarin arvon. Sama työ, sama määrä laskutettavia tunteja, mutta tuloksen arvo on erilainen. Tuloksen arvo on se, mikä on tärkeää.

Galen Low: Mainitsit jotain todella tärkeää vähimmäiskelpoisesta tuotteesta. Palaan siihen, mitä sanoit aiemmin. Mittaamme kiireisyyttä joskus siksi, että kyse on luottamuksesta. Emme luota siihen, että ihmiset tekevät työnsä, mutta jos voimme pitää kelloa heidän yllään heidän työskennellessään, tiedämme ainakin heidän käyttäneen ne tunnit.

Mutta kuten sanoit, se ei mittaa arvoa. Ihmiset sanovat minulle: tietenkin tarvitsemme laskutettavat tunnit, koska niin sopimuksessa lukee. Niiden perusteella ihmisille maksetaan. Se on sopimus. Pidän kuitenkin siitä, mitä sanoit vähimmäiskelpoisesta tuotteesta: viedään jotain markkinoille.

Se vaatii investoinnin, ja sen jälkeen asiakas voi päättää, onko se arvokas. Jotkut saattavat ajatella, että haluan tietää sen olevan arvokas ennen rahojen käyttämistä. Todellisuudessa se ei toimi niin. Sinulla on 50 000 dollaria, rakennat tuotteen, ja käytettyäsi rahat sinulla ei ehkä edelleenkään ole sellaista tuotetta, joka loisi arvoa.

Tuntuu kuitenkin siltä, että monet ajattelevat laskutettavista tunneista ja dollareista, että kyseessä on välttämätön paha liiketoiminnan tekemiseksi. Vai pitäisikö meidän pyrkiä pääsemään siitä eteenpäin?

Fred Fowler: Joiltakin osin kyse on välttämättömästä pahasta. Ihmiset on silti pidettävä oikealla tiellä vertaamalla heidän kustannuksiaan arvokkaaseen tulokseen. Scrum-kehyksessä sinun on aina luotava jotain valmista, viimeisteltyä ja asiakkaalle toimitettavaksi kelpaavaa jokaisen sprintin lopussa.

Miksi luulet, että näin on? Miksi on tärkeää, että jokin on valmis ja voidaan antaa asiakkaalle?

Galen Low: Ehkä siksi, että sen arvoa voidaan mitata.

Fred Fowler: Juuri niin. Jollakin on arvoa vasta, kun se on valmis ja valmis annettavaksi asiakkaalle.

Arvoa mitataan sillä, kuinka paljon asiakas maksaa tuotteesta. Scrumissa luodaan kahden viikon välein jotain arvokasta, jotta sen arvoa voidaan verrata luomisen kustannuksiin. Näin tiedät etukäteen, oletko matkalla kohti kuuden miljoonan dollarin tuotetta 50 000 tai 500 000 dollarin investoinnilla vai 50 000 dollarin tuotetta 500 000 dollarin investoinnilla. Tuote on jaettava osiin, joilla jokaisella on mitattava arvo — ei vain oletettua arvoa.

Scrum korostaa päätösten tekemistä mitattujen asioiden, ei arvausten tai mielipiteiden perusteella. Tärkein mitattava asia on arvo.

Galen Low: Voisitko käydä kanssamme läpi tuon arvon mittaamisen? Jos kiireisyyden mittaamisesta ei ole paljon hyötyä, mitä mittareita meidän pitäisi tiiminä, esimerkiksi Scrum-tiiminä, seurata?

Fred Fowler: Scrum-kehyksessä arvon mittaaminen kuuluu oikeastaan vain yhdelle henkilölle. Scrum jakaa vastuut kolmeen osaan: tuotteen omistajaan, kehittäjiin ja Scrum Masteriin.

Tuotteen omistajan tehtävä on maksimoida tiimin työn arvo. Hän vastaa arvosta. Mitään ei voi maksimoida, ellei sitä voi mitata. Jos et voi mitata asiaa, jota yrität maksimoida, et tiedä, parantaako vai heikentääkö toimintasi sitä.

Arvoa voi kasvattaa neljällä tavalla. Yleisin on liikevaihto. Toinen tapa on kustannusten pienentäminen. Kolmas on riskin pienentäminen. Neljäs tapa on mahdollisuuksien lisääminen.

Kun esimerkiksi vähennät vuosittaisen miljoonan dollarin riskin 50 000 dollarin investoinnilla, kyse on arvon luomisesta. Samoin jos voitat yhden tarjouksen kuudesta ja pystyt toiminnallasi voittamaan kaksi kuudesta, voit verrata syntyvää lisäarvoa sen saavuttamisen kustannuksiin.

Galen Low: Tuotteen omistaja vastaa siis arvosta ja mittaa sitä. Miten hän välittää tämän takaisin kehitystiimille?

Fred Fowler: Tuotteen omistaja tekee investointipäätöksiä. Hän arvaa, mikä voisi olla arvokasta, ohjaa tiimin luomaan sen ja antaa sen sitten asiakkaiden käsiin. Arvo mitataan jälkikäteen sen perusteella, mitä ihmiset ovat valmiita maksamaan, mitä kustannuksia säästetään tai mitä uusia mahdollisuuksia syntyy.

Jos sprinttiin käytetään 50 000 dollaria, syntyykö sillä yli 50 000 dollarin arvoa? Tuotteen omistaja ja tiimi ovat samassa veneessä. Heidän on tuotettava enemmän arvoa kuin mitä he maksavat.

Galen Low: Se on todella selkeä toteamus. Joskus ajattelemme, että tietenkin minulle maksetaan, tein 80 tuntia töitä ja lupasin tehdä 80 tuntia. Miksi minulle ei maksettaisi?

Todellisuudessa olemme jääneet omaan ansaamme, koska kyse ei ole arvosta vaan ajan vaihtamisesta dollareihin.

Fred Fowler: Aivan. Kun kehittäjät ymmärtävät tämän, he ymmärtävät, että heidän etunsa mukaista on varmistaa työnsä arvo.

Tuotteen omistaja toimii liiketoimintaroolissa ja kehittäjät teknisessä roolissa. Tuotteen omistaja kertoo, mikä olisi toivottavaa, ja kehittäjät kertovat, mikä on mahdollista. Neuvottelun avulla päätetään, mikä on käytännöllistä ja arvokkainta.

Galen Low: Pidän sanasta kumppanuus. Kaikki eivät ehkä näe sitä aluksi niin. He saattavat ajatella, että tehdään vain se, mitä tuotteen omistaja päättää. Se tuntuu helposti alisteiselta suhteelta, mutta Scrumissa on kyse valtuuttamisesta: yksilöiden ja heidän asiantuntemuksensa valtuuttamisesta.

Fred Fowler: Kehittäjät voivat vaikuttaa merkittävästi kustannuksiin. Jos tuotteen omistaja pyytää rakentamaan oman kirjautumisjärjestelmän, kehittäjien pitäisi kysyä, voisiko käyttää esimerkiksi Google- tai Facebook-kirjautumista. Silloin heidän ei tarvitse keksiä samaa pyörää uudelleen.

Kehittäjät voivat kertoa, mikä on helppoa ja vaikeaa, ja tuotteen omistaja voi kertoa, mikä on arvokasta. Neuvottelussa etsitään helpoin tapa tehdä jotain arvokasta.

Galen Low: Olen itsekin syyllistynyt kiireisyyden tai nopeuden mittaamiseen. Nopeus on edelleen asia, jota seurataan, samoin burndown-kaavioita. Millaiselta arvosta käytävä keskustelu näyttää Scrum-tiimeissä?

Fred Fowler: Se liittyy palkitsemiseen. Jos kaikki saavat palkkansa tunneittain, kannustin on tehdä kaikki mahdollisimman vaikealla tavalla. Tämä on monien projektien ongelma. Olen työskennellyt Fortune 50 -yrityksen kanssa projektissa, jonka piti kestää kaksi vuotta ja maksaa 500 miljoonaa dollaria. Kahden vuoden ja lähes koko budjetin jälkeen se ei ollut luonut lainkaan arvoa. Se oli tuottanut vain melua, toimintaa ja suuren määrän laskutettavia tunteja.

Palkitsemisessa on kaksi puolta. Ensin ihmiset on saatava mukaan, ja silloin on maksettava markkinahinta. Sen jälkeen ihmisille on annettava osa heidän tuottamastaan arvosta palkkiona. Jos tiimi luo 100 000 dollarin arvosta arvoa ja yritys antaa siitä 20 prosenttia tiimille, tiimi saa 20 000 dollaria. Tiimin pitäisi päättää itse, miten summa jaetaan, koska he tietävät parhaiten, kuka ansaitsee palkkion.

Galen Low: Se muistuttaa voitonjakojärjestelmää: peruspalkka tuo ihmiset mukaan ja kannustin perustuu tuotettuun arvoon.

Fred Fowler: Se on järkevää, koska se ohjaa kannustimet oikein. Tuotteen omistaja on sijoittaja, jolle annetaan valta päättää, miten tiimin aikaa käytetään. Investointien tuloksia on kuitenkin mitattava.

Kehitystiimillä puolestaan on täysi valta päättää, miten työ tehdään. Jos joku muu kertoo heille, mitä tehdä, he voivat syyttää tätä, jos jokin menee pieleen. Kun kehittäjillä on päätösvalta, heillä ei ole ketään muuta syytettävänä kuin itsensä.

Galen Low: Ala ei ole aina onnistunut rakentamaan vastuullisuutta. Liian usein sanotaan: tee näin, koska minä sanon niin.

Fred Fowler: Se on tehotonta, koska tehdessä opitut asiat eivät vaikuta päätöksiä tekeviin ihmisiin. Siksi Scrumissa kehitystiimien on oltava itseohjautuvia ja monialaisia. Niiden on pystyttävä luomaan tuote itse ja tekemään omat päätöksensä.

Vanha sanonta kuuluu: mikään ei ole mahdotonta, jos sinun ei tarvitse tehdä sitä itse. Jos joku käskee sinua tekemään jotain, tehtävä ei ole hänelle mahdoton, koska hänen ei tarvitse tehdä sitä.

Galen Low: Se on hauska ajatus. Kyse on valtuuttamisen ja vastuullisuuden tasapainosta, ja se on matka, joka ei tapahdu yhdessä yössä.

Fred Fowler: Mukana on kolme asiaa: valtuuttaminen, vastuullisuus ja kyvykkyys. Valtuutettujen ihmisten on pystyttävä tekemään työ. Tuotteen omistajan on pystyttävä investoimaan suuria summia arvokkaiden tuotteiden luomiseen. Kehittäjien on pystyttävä luomaan tuote tiiminä ja vastattava siitä.

Scrum Masterin suurin haaste on saada kaikki työskentelemään yhdessä tiiminä ja ymmärtämään omat vastuunsa. Yksi hyvä tapa auttaa on palkitsemismalli, joka palkitsee todellisesti luodusta arvosta. Mittaa arvoa ja palkitse arvosta.

Tuotteen omistajan työn on tuotettava mitattavaa arvoa. Jos työskentelet jonkin parissa mutta et voi mitata sen arvoa, kyse ei ole tuotteesta etkä voi tehdä järkeviä päätöksiä sen suhteen.

Galen Low: Voisimme lopuksi kysyä, voiko tätä soveltaa myös muihin menetelmiin.

Fred Fowler: Muihin menetelmiin? Kyllä. Scrum on eräänlainen kerros syvemmän perustan päällä, kuten myös Agile. Syvempi totuus on, että pätevien ihmisten on voitava tehdä päätöksiä, joista he ovat vastuussa liiketoiminnan ja tuotekehityksen näkökulmasta.

Kehittäjien on pystyttävä luomaan tuote ja johtamaan itseään. Lisäksi tarvitaan tapa mitata projektin ja tuotteen asteittaista edistymistä. Kaikesta huolimatta kannattaa keskittyä arvon, ei toiminnan, mittaamiseen ja tulosten, ei tuotosten, mittaamiseen. Kun teet niin, millä tahansa kehyksellä työskenteletkin, olet matkalla kohti onnistumista.

Galen Low: Siinä se, ihmiset. Erittäin hyvä.

Fred, keskustelimme tapaamisryhmästäsi ja kirjoittamistasi kirjoista. Mistä kuuntelijat voivat oppia lisää?

Fred Fowler: Olen johtanut Scrum-aiheista tapaamisryhmää vuodesta 2015. Kutsumme sitä Advanced Scrum Case Studies -tapaamiseksi.

Kokoonnumme verkossa joka toinen viikko, ja julkaisen etukäteen tapauskuvauksen, jossa käsitellään projektinhallintaan tai Scrum-hallintaan liittyvää ongelmaa. Aiheet voivat käsitellä esimerkiksi hajautettujen tiimien johtamista tai arvon mittaamista.

Jos kiinnostuit, olet tervetullut mukaan. Ryhmän nimi on Silicon Valley Professional Scrum meetup group, ja sen löytää Meetup-palvelusta. Tapaamisryhmässä on syntynyt paljon kiinnostavaa materiaalia.

Olen saanut muistiinpanot noin 60 tapauksesta. Olen koonnut ne kirjaksi nimeltä Advanced Scrum Case Studies. Se on saatavilla Amazonissa ja verkkosivustollani osoitteessa www.siliconvalleyscrum.com.

Kirjassa on 15 kiinnostavaa tapausta, ja työstän parhaillani toista osaa.

Galen Low: Mahtavaa. En tiennyt, että kirja perustui tapaamisryhmän keskusteluissa syntyneeseen materiaaliin.

Fred, kiitos paljon, että tulit ohjelmaan. Nautin tarinoistasi ja näkökulmastasi. Keskustelumme palkitsemisesta voisi olla kokonaan oma jaksonsa.

Toivottavasti kuuntelijamme saivat keskustelusta paljon hyödyllistä. Kiitos.

Fred Fowler: Kiitos. Nautin keskustelustamme todella paljon. Kiitos kutsusta.

Galen Low: Mitä mieltä olet?

Onko projektitiimien mahdollista keskittyä arvon luomiseen käytettyjen tuntien tai valmiiden käyttäjätarinoiden sijaan? Vai olemme liian riippuvaisia työpanokseen perustuvasta rahamallista?

Kerro meille tarina: mitkä ovat olleet oikeat mittarit projektiesi seuraamiseen? Millaisia muutoksia tai tuloksia olet nähnyt, kun olet saanut näkyvyyttä projektisi dataan?

Jätä ajatuksesi alla oleviin kommentteihin!

Jos haluat kehittää taitojasi strategisena projektijohtajana, liity yhteisöömme!

Siirry osoitteeseen thedigitalprojectmanager.com/membership saadaksesi käyttöoikeuden tukevan yhteisön sisältöihin. Yhteisö jakaa tietoa, ratkaisee monimutkaisia haasteita ja muovaa ammattimme tulevaisuutta yhdessä.

Vankat mallipohjat ja kuukausittaiset koulutukset säästävät aikaasi ja energiaasi. Lisäksi Slack-keskustelut, live-tapahtumat ja mastermind-ryhmät tarjoavat vertaistukea. Yhteisön jäsenenä saat yli tuhat ihmistä tueksesi, kun etenet digitaalisessa projektitoimituksessa.

Jos pidit tämänpäiväisestä jaksosta, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com.

Kuullaan taas ensi kerralla. Kiitos kuuntelusta.