Ketterä kehitysmalli muuttaa projektin pelisäännöt, mutta ohjaus on edelleen tärkeää. Projektiyhdistyksen työpajassa pohdimme, kuinka ohjausryhmä voi tuottaa konkreettista lisäarvoa ketterälle projektille.
Jos ohjausryhmässä palvotaan projektikolmiota (alunperin suunniteltua sisältöä, aikataulua ja budjettia), odotetaan projektipäällikön raporttia ja höpistään tyyliin “projektin aikataulu vaikuttaa hyvältä mikäli suunnitelmassa pysytään”, on korkea aika järkevöittää toimintaa.
Joskus ohjausryhmä voi unohtaa, että tarkoituksena on tuottaa arvoa loppukäyttäjille. Se vaatii ohjausryhmän jäseniltä uudenlaista johtajuutta: Loppukäyttäjien ja liiketoiminnan tuntemusta, tuotejulkaisuiden ja suurten vaatimusten keskinäistä priorisointia, jatkuvan oppimisen kulttuurin kehittämistä sekä projektin tukemista auttamalla poistamaan työn esteitä ja yhdistämällä yrityksen strategian iteratiiviseen toteutukseen. Tämä poikkeaa perinteisestä “ohjaamisesta”, jossa pyritään pakottamaan todellisuutta jo aikaa sitten vanhentuneisiin suunnitelmiin.
Ketterä ohjausryhmä -työpajalle listattiin seuraavia odotuksia
Tarvitaanko Agilessa projektin ohjausryhmää?
Kuinka saada yhteistyötä ja ryhtiä projektin ohjaamiseen?
Kuinka ketteryys parantaa mm. keskustelua ohjausryhmässä?
Ketterä projektin governance: Kuka päättää, milloin ja miten?
Vaihtoehtoja perinteiselle projektin ohjausryhmälle?
Perusmalli ketterälle ohjaamiselle?
Mitä ketterä ohjausryhmä käytännössä päättää ja tekee?
Scrum ei määrittele projektin ohjausryhmää, mutta käytännössä siitä on usein hyötyä kehitysprojekteille. Alla muutamia näkökulmia.
Kuinka ketterä kehitys muuttaa projektin ohjausryhmän toimintaa
1. Selkeät roolit ja pull-raportointi
Tuoteomistaja omistaa vaatimukset (iteraatiotasolla)
Kehitystiimi omistaa tehtävät (päivätasolla)
Scrummaster tukee työn sujuvuutta (prosessitasolla)
Scrumin roolien myötä myös ohjausryhmän rooli selkiytyy. Jos tuoteomistajaa vertaisi toimitusjohtajaan, voisi ketterää ohjausryhmää verrata yhtiön hallitukseen. Sen tehtävänä on tukea tuoteomistajia ja projektin onnistumista. Kehityksen alussa ohjausryhmä voi esimerkiksi nimittää tuoteomistajan (ja antaa hänelle mandaatin päätöksentekoon), osallistua tuotteen vision luomiseen, auttaa rekrytoinnissa sekä julkaisuiden ja suurten vaatimusten järjestämisessä.
Selkeiden roolien lisäksi ketterä kehitysprosessi poistaa perinteisen “push”-raportoinnin tarpeen. Tuoteomistajan ei enää tarvitse antaa ohjausryhmälle raporttia kehityksen tilasta, koska kaikki olennainen tieto on ohjausryhmän jäsenten ulottuvilla: Ohjausryhmän jäsenet ovat tervetulleita tuotteen katselmointeihin (sprint review), heillä on jatkuva pääsy uusimpaan tuotteen kehitysversioon, tuotteen kehitysjonoon (product backlog) ja mahdollisiin edistymiskäyriin (burndown / burnup charts). Toki ohjausryhmässä voidaan seurata tiettyjä avainmuuttujia ja tuoteomistaja(t) voivat kertoa näkemyksistään. Mutta ohjausryhmän kontrollintarpeen tyydyttämiseksi kyhätyille mekaanisille statusraporteille ei enää ole tarvetta.
2. Tuotteen ja ohjausryhmän pitempi elinkaari
Perinteinen ohjausryhmä toimii vain projektin loppuun asti. Ketterässä kehityksessä taas tuoteomistaja ja ohjausryhmä ovat pysyviä elementtejä, jotka ovat olemassa useiden julkaisuprojektien (koko tuotteen elinkaaren) ajan. Näin kehittyvät tuoteomistajan sekä ohjausryhmän ammattitaito, loppukäyttäjien ja liiketoiminnan tuntemus sekä yhteistyö ja vastuun kantaminen tuoteliiketoiminnan menestyksestä.
Ketterän ohjausryhmän tapaamiset ovat säännöllisiä aktiviteetteja, jotka toistuvat sopivin välein koko tuotteen elinkaaren ajan. Tyypillinen tapaamisväli on 1-3 viikkoa, riippuen seuraavien julkaisuiden strategian selkeydestä ja odottamattomien muutosten määrästä. Usein tuotekehityksen alussa ja julkaisun lähestyessä tarvitaan enemmän korkean tason priorisointia ja tukea, jolloin ohjausryhmä voi tavata kerran viikossa.
3. Projektiajattelusta tuote- tai palveluliiketoimintaan
Vanhan vitsin mukaan leikkaus onnistui, mutta potilas kuoli. Vastaavasti projektin perinteiset mittarit (aika, sisältö ja budjetti) ovat ketterässä kehityksessä toissijaisia. Ketterässä ohjaamisessa keskitytään tuote- ja palveluliiketoiminnan onnistumiseen ja arvontuoton mittareihin:
Paljonko tuotettiin lisäarvoa loppukäyttäjille (Return On Investment)
Kuinka nopeasti päästiin markkinoille (Time-to-Market)
Kehityksen ja ylläpidon kokonaiskustannus (Total Cost of Ownership)
Tuotteen tai palvelun markkinaosuus
Liikevoitto
Käyttäjätyytyväisyys
Oman henkilöstön tyytyväisyys, yhteistyö ja oppiminen
Perinteinen ohjausryhmä voi piiloutua projektikolmion (alunperin suunniteltu aikataulu, vaatimukset ja budjetti) taakse ja vaatia raskasta raportointia, vaikka oltaisiin rakentamassa täysin turhaa vimpainta. Nykyaikaisen ohjausryhmän tärkein tavoite onkin varmistaa, että ollaan rakentamassa jotain oikeasti hyödyllistä. Tämä onnistuu iteratiivisella kehityksellä, jossa arvoa tuotetaan ripeästi, lyhyin iteraatioin ja näin myös pienemmällä riskillä. Hyvä lähtökohta on legendaarinen kirja The Lean Startup, joka sopii myös suuryritysten projektien ohjaamiseen.
4. Säännöllinen priorisointi projekti- ja vaatimustasolla
Klassinen esimerkki toimimattomasta ohjausryhmästä on tilanne, jossa yrityksen tulee kehittää samanaikaisesti tuotejulkaisut A, B ja C. Koska kaikki projektit koetaan “erittäin tärkeiksi”, eikä julkaisuprojektien keskinäistä priorisointia ole totuttu ohjausryhmässä tekemään, priorisointivastuu kipataan käytännössä kehitysorganisaatiolle. Tällöin projektipäälliköt päätyvät taistelemaan keskenään kehittäjien ajasta, eikä hommasta tule välttämättä mitään. Tällainen hölmöily saadaan loppumaan, kun ohjausryhmä ymmärtää priorisoida kehitysprojektien A, B ja C keskinäisen toteutusjärjestyksen ja kommunikoida sen selkeästi organisaatioon.
Julkaisuiden priorisoinnin lisäksi ohjausryhmässä on hyödyllistä päättää tärkeimmistä strategisista vaatimuksista. Tällaisia voivat olla esimerkiksi asiakkaalle luvattu erikoistoiminto, tekninen liittymä sisartuotteeseen tai merkittävä korjaus tai parannus. Ohjausryhmässä voidaan sopia muutamasta (noin 1-5) strategisesta vaatimuksesta ja niiden järjestyksestä per julkaisuprojekti. Sen jälkeen tuoteomistaja saa kehitystiimeineen vapaat kädet määrittää julkaisun muut vaatimukset (Release Backlogin).
Fokuksen säilyttämiseksi ketterässä ohjausryhmässä puhutaan vähintään yhtä paljon siitä, mitä vaatimuksia ei toteuteta seuraavaan julkaisuun, kuin siitä mitä toteutetaan.
5. Kiinteästä sisällöstä ketterään sopimusmalliin
Kiinteä budjetti ja deadline on ketterässä kehityksessä täysin normaali ja hyvä asia (vaikka joskus kuvitellaan, ettei ketteryys toimisi kiinteässä budjetissa tai ajassa). Kiinteä sisältö taas on erittäin huono asia minkä tahansa projektin arvontuoton kannalta.
Säännöllinen vaatimusten priorisointi toimii luonnollisesti paremmin, kun vaatimuksia on mahdollista muuttaa projektin aikana. Siksi ohjausryhmän tulisi tehdä parhaansa, jotta projektille valitaan ketterä sopimusmalli, jossa ostetaan kehittäjien aikaa eikä tuotteen ominaisuuksia.
Ketterä sopimusmalli ei ole vaikea, vain erilainen kuin perinteinen sopimusmalli. Mikäli asiaa ymmärtämätön asiakas ei hyväksy ketterää sopimusmallia, voidaan projektia kuitenkin seurata ja pyrkiä ohjaamaan ketterän ohjauksen keinoin. Tällöin asiakas saattaa tuotekatselmoinneissa huomata, ettei sopimukseen kirjattua elefanttia kannatakaan rakentaa kokonaan, vaan toteuttaa ensin tärkeimmiksi havaitut piirteet.
Kiinteäsisältöisen sopimusmallin ongelmana on kuitenkin se, että se poistaa tarpeen priorisoida vaatimuksia keskenään (kaikki vaatimuksethan on luvattu sopimuksessa). Tämä voi saada asiakkaan uskomaan, että kaikki vaatimukset olisivat loppukäyttäjille arvokkaita ja ne ehditään toteuttaa. Kumpikaan oletus ei yleensä toteudu, jonka vuoksi perinteinen kiinteäsisältöinen sopimusmalli on käytännössä järjetön ja jopa kansantaloudelle vaarallinen.
CASE-esimerkki ketterästä ohjausryhmästä käytännössä
Kun ketterä ohjausprosessi alkaa toimia, se tuntuu luontevalta ja tukee hyvin tuotekehityksen ja koko organisaation onnistumista. Tässä avainkohtia ketterän ohjausryhmän käytännön toteutuksesta noin 100 hengen tuotekehitysorganisaatiossa:
Mieti ensin riittääkö organisaatiossanne yksi ohjausryhmä kaikille tuotteille (jos tuotteita on useampia), vai tarvitaanko eri tuotteille erillisiä ohjausryhmiä. Itse olen yhdistetyn ohjausryhmän kannalla, josta on hyviä kokemuksia useammasta pk-organisaatiosta. Tällöin yksi ohjausryhmä ohjaa kaikkia organisaation (tai sen osaston) kehityshankkeita ja pystyy näin koordinoimaan tuotteiden ja tuoteomistajien välisiä riskejä, riippuvuuksia ja prioriteettejä.
Anna ohjausryhmälle tarvittaessa nimi, joka erottaa sen perinteisestä ohjausryhmästä. Esim. Release Board, Release Management Team, Roadmapping Team, tms.
Kutsu mukaan avainhenkilöt. Esim. Pienen yrityksen toimitusjohtaja ja/tai myyntijohtaja, kaikki tuoteomistaja(t), mahdollinen tuotejohtaja (Chief PO), teknologiajohtaja ja tarvittaessa tekninen arkkitehti tai senioritason kehittäjä. On tärkeää, että ohjausryhmässä on kaikki päätösvalta tuotekehitykseen sekä vahva linkki myynnin ja liiketoiminnan johtoon.
Pidä ohjausryhmän henkilömäärä alle kymmenessä, jotta kommunikointi ja yhteistyö on sujuvampaa. Kysy tarvittaessa osallistujilta “mikä sinun roolisi on täällä” ja pyydä tarpeettomia henkilöitä siirtymään tuottavampiin töihin. Ketterään ohjausryhmään ei osallistuta viran puolesta, vaan lisäarvon tuottamiseksi. Siksikin jokin erikoinen nimi ketterälle ohjausryhmälle voi auttaa pitämään tarpeettomat poissa.
Sopikaa säännöllisesti toistuva tapaaminen aluksi esimerkiksi kahden viikon välein. Tapaamisen pituudeksi riittää yleensä 60 tai 90 minuuttia. Mikäli asiaa on vähemmän, lopettakaa ohjausryhmän kokous nopeammin. On tärkeää luoda tapaamisesta toistuva rutiini.
Mitä ketterän ohjausryhmän kokouksissa käsitellään
Ketterän ohjausryhmän etuina on sopia yhteistyössä kehitystyön strategisesta suunnasta, tulevista julkaisuista ja tukea kehitystyön onnistumista mm. varmistamalla asiakkaiden tarpeiden tyydyttäminen ja toteutustyön esteiden poistaminen. Käytännössä ohjausryhmän kokouksissa keskitytään tuleviin julkaisuihin ja niiden tärkeimpään strategiseen sisältöön:
Puheenjohtaja (mielellään toimitus-, myynti-, tai tuotejohtaja) avaa kokouksen. Puheenjohtajan olisi hyvä olla liiketoiminnan edustaja, jotta linkki liiketoimintaan pysyy vahvana.
Valitaan kirjanpitäjä, esim. (Chief) Scrum Master tai teknologiajohtaja. Käytännössä kirjanpitoon riittää muutama ranskalainen viiva tai action pointti tärkeimmistä päätöksistä sähköpostitse lähetettynä. Kirjanpitäjä päivittää myös Roadmap-kalvon kokouksen aikana tai jälkeen.
Varmistetaan kokouksen asialista ja tavoitteet (agenda on periaatteessa aina sama, mutta erityiset seikat on hyvä lähettää osallistujien tiedoksi etukäteen ja sopia käsittelystä kokouksen alussa)
Avataan datatykillä yksi kalvo: Kehityksen Tiekartta (Roadmap), kts. esimerkki alla.
Keskustellaan lyhyesti kehityksen tilanteesta suhteessa Roadmapiin ja käsitellään mahdolliset viimeksi sovitut action pointit. Virallisia raportteja ei tarvita, koska ohjausryhmän jäsenet tuntevat virkansa puolesta tilanteen (katso tämän artikkelin alusta kohta 1). Näin osallistujat voivat keskittyä valaisemaan tilannetta omista näkökulmistaan, esim. Uudet asiakastilaukset, sopimukset, messut ja muut liiketoiminnan tilaisuudet joihin tarvitaan kehitystyötä, tuotannon tai alihankinnan häiriöt ja muut kehitykseen vaikuttavat asiat.
Priorisoidaan haasteet ja ideoidaan niille erilaisia ratkaisuvaihtoehtoja. Osallistujat voivat esittää lyhyitä tietoiskuja perustuen uuteen tai osallisille ennalta toimitettuun materiaaliin.
Vedetään keskustelua yhteen ja tehdään päätöksiä: 1) Milloin tuotteesta X pyritään julkaisemaan seuraava versio (tai sitä seuraava), 2) Mitkä tavoitteet perustelevat tätä julkaisua (esim. Asiakkaan deadline, liikemessut, kilpailutilanne, akuutti virheenkorjaus, tms.), 3) Mitkä ovat julkaisun muutamat tärkeimmät (1-5) vaatimusta tai “Epicciä”, joiden avulla julkaisun strateginen tavoite toteutuu. Huom. Ohjausryhmä voi myös ajan salliessa tehdä “Epic Refiningia” eli auttaa tuoteomistajia pilkkomaan strategisia vaatimuksia pienempiin toteutuskelpoisiin vaatimuksiin. Loppu pilkkominen ja Release Backlogin luominen jää tuoteomistajalle ja hänen kehitystiimilleen.
Sovitaan tarvittaessa käytännön action pointeista, jotka ohjausryhmän jäsenet hoitavat seuraavaan tapaamiseen mennessä.
Käsitellään lyhyesti muut esilletulevat asiat.
Puheenjohtaja päättää kokouksen.
Yläpuolella on yksinkertainen slide, jota ketterä ohjausryhmä seuraa ja päivittää. Jokaiselle tuotteelle on oma janansa (kuvassa on kaksi tuotetta, joista molemmista kaavaillaan kolmea julkaisua). Näin nähdään yhdellä silmäyksellä, milloin eri tuotejulkaisuja on odotettavissa ja mitä vaatimuksia niiden kesken tulee tarvittaessa synkronoida.
Tuoteomistajan ja ohjausryhmän suhteesta
Scrumissa korostetaan tuoteomistajan päätösvaltaa julkaisun sisältöön, jotta epämääräisyys sisällön päätöksenteossa saadaan loppumaan. Kannattaa kuitenkin muistaa, että tuotekehitys on joukkuelaji. Siksi viisaalla tuoteomistajalla on suuret korvat. Ketterä ohjausryhmä ei “käskytä” tuoteomistajia, vaan tuoteomistajat osallistuvat keskusteluun ja päätöksentekoon. Ristiriitatilanteissa tuoteomistajalla on edelleen päätösvalta, mutta käytännössä jokainen fiksu tuoteomistaja ymmärtää priorisoida ohjausryhmässä yhdessä tunnistettuja strategisia vaatimuksia oman tuotteensa Release Backlogin kärkeen. Käytännössä tästä ei ole koskaan muodostunut ongelmaa.
Ketterä ohjausryhmä -työpajan yhteenveto
Kokeile ohjausryhmässä näitä:
Seuraa projektin arvontuottoa enemmän kuin projektikolmiota
Kyseenalaista tarvittaessa ohjausryhmän osallistujat / vastuut / roolit
Vaihda ohjausryhmän nimeksi esim. Release Board, niin voit karsia turhia osallistujia, joiden “täytyy” osallistua viran puolesta.
Kutsu ohjausryhmän jäsenet (tarvittaessa erilliseen) tuotteen katselmointipalaveriin, ja tarjoa heille jatkuva pääsy viimeisimpään kehitysversioon ja Product Backlogiin. Näin raportointitarve ohjausryhmän kokouksissa vähenee.
Muuta ohjausryhmä projektin resurssiksi, ts. projektin puolustajaksi ja tukitoiminnoksi, eikä resurssien kuluttajaksi.
Pyydä tarvittaessa anteeksi lisäarvon tuottamista, älä lupaa.
Vältä ohjausryhmässä näitä:
Projektipäällikön (tai tuoteomistajan) raportointitilaisuus.
Ohjausryhmässä on päällekkäisiä omistajuuksia tai vastuita.
Suuri ohjausryhmän koko (> 9 hlö).
Projektikolmion palvominen, kuten “projektin aikataulu näyttää hyvältä, mikäli suunnitelmassa pysytään” -höpinät.
“Hiekottajat”, jotka istuvat ohjausryhmässä ja jarruttavat kaikkea toimintaa esim. ristiriitojen lietsomisella, välinpitämättömyydellä, kontrollintarpeella, tms.
Hidden Agenda.
Kuvassa Projektiyhdistyksen tuotekehityksen intressiryhmä 16.9.2014.
Kiitos kaikille osallistuneille ja tervetuloa mukaan 2015!