Ketterän projektinhallinnan elementit – puuttuuko mitään?
Julkaistu: 18.01.2010 Kategoria(t): Scrum, Tuotekehitys 5 kommenttia »Ketterät menetelmät sisältävät riittävän paljon elementtejä ollakseen hyödyllisiä mutta riittävän vähän elementtejä soveltuakseen useimpiin kehityshankkeisiin.
Esimerkiksi Scrum sisältää vain yhdeksän elementtiä:
- Kolme roolia
- Kolme dokumenttityyppiä
- Kolme aktiviteettia
Minimalistisuuden vuoksi ketteriä menetelmiä on lähes aina hyödyllistä täydentää lisäämällä piirteitä toisista menetelmistä. Ketteryyden soveltamisessa vallitseekin synerginen “sekä että” -ajattelu “joko tai” -ajattelun sijaan.
Tuotekehityksen prioriteetit (product backlog) perustuvat tuotteen visioon, jonka tuoteomistaja määrittelee. Ketterät menetelmät eivät kuitenkaan ota kantaa siihen, kuinka visio tuotetaan, kommunikoidaan ja ylläpidetään linjassa yhtiön strategian kanssa.
Kuinka ketterää kehitystä sitten ohjataan johtotasolla, varsinkin kun tuoteomistajia ja kehitysryhmiä on useampia?
Taulukossa on listattu ketterän projektinhallinnan tärkeimpiä elementtejä johtamisen näkökulmasta:
| Mikä | Mitä |
| Projektin johtoryhmä |
Ylläpitää tuotekehityksen Tiekarttaa ja synkronoi tuoteomistajien tuotevisiot yhtiön strategiaan |
| Kehitysryhmä | Auttaa paloittelemaan ja aika-arvioimaan Product Backlogia |
| Jakson suunnittelukokous | Suunnittelee jakson realistisen tavoitteen ja sisällön |
| Jakson arviointikokous | Arvioi jakson tavoitteen ja sisällön toteutumista (demo) |
| Daily Scrum | Suunnittelee ja synkronoi päivän työt |
| Retrospektiivi | Opitaan jakson tai julkaisun virheistä ja onnistumisista |
Projektin johtoryhmä on hyväksi havaittu keino ylläpitää tuotekehityksen Tiekarttaa (roadmapia) ja synkronoida sen avulla tuotevisiot yhtiön strategian mukaisiksi. Näin tuoteomistajat saavat säännöllisesti palautetta ja voivat kehitysryhmineen helpommin ylläpitää tuotteensa työjonoa.
Tuotekehityksen johtoryhmä tapaa yleensä 1-4 viikon välein. Johtoryhmään kannattaa valita pysyvät jäsenet tuotekehityksen, tuotehallinnon, myynnin sekä markkinoinnin johdosta ja hyödyntää tarvittaessa vierailevia asiantuntijoita. Osan jäsenistä olisi hyvä kuulua myös yhtiön johtoryhmään, jotta strategiatieto on saatavilla.
Kuinka teillä johdetaan ketterää kehitystä? Hyödynnättekö projektin johtoryhmää tai muita lisäyksiä, joihin alan kirjallisuus ei ota kantaa?
Scrumissa tuotehallinta ja -strategia ovat tyypillisesti sellaisia alueita, jotka kaipaavat vahvistusta muualta samaan tapaan kuin engineering-käytönnöt jotka usein hieman harhaanjohtavasti oletetaan olevan osa menetelmää.
Varsinaiseen ketterään tuotehallintaan tuntuu olevan paljon vähemmän metodiikkaa kuin kehitystiimin ja yksittäisten koodaajien työhön. Usein menetelmät tuotehallinnan osalta ovat perinteisestä maailmasta ja tämä voi aiheuttaa joskus ristiriitoja, kun esimerkiksi kolmen vuoden tiekartan kuvitellaan olevan täsmälleen toteutuva suunnitelma.
Kun tuotekehitysmoottori on viritetty ketteräksi, täytyisi myös muun organisaation pysyä kelkassa ja ymmärtää tilanne jatkuvasti liiketoiminnan kannalta jotta tuotteen omistajalla on riittävästi eväitä määritellä liiketoiminnan prioriteetteja.
Itselläni kokemukset eri organisaatiosta ovat tapauskohtaisia ja tuotehallinnan kypsyystaso vaihtelee laidasta laitaan. Joitakin yhteisiä nimittäjiä on kyllä löydettävissä, erityisesti tuo tiekartan ylläpito erilaisin menetelmin (tuotteen ohjausryhmät, strategiapalaverit jne.) tuntuu olevan kaikille tyypillistä.
Aika vähällehän nuo menetelmät kirjallisuudessa ovat tosiaan jääneet ja aloitteleva tuotepäällikkö tai tuotteen omistaja joutuu helposti lujille opetellessaan kantapään kautta hyvän tavan ohjata tiimiä, samalla kun liiketoiminta ja kehitystiimi odottavat oraakkelimaisia lausuntoja prioriteeteista ja lisäarvosta.
Ohessa muutama lähde jotka sivuavat ketterää tuotehallintaa:
http://crankypm.com/
http://agileproductowner.com/
http://scalingsoftwareagility.wordpress.com/
http://www.gilb.com/Site+Content+Overview
Terve Toni,
Scrum tosiaan sisältää enemmän kalustoa kehitystiimeille kuin tuotehallintoon.
Rajapinta tuotekehityksen ja tuotehallinnon välillä määritellään yksinkertaisen tehokkaasti (esim. product backlogin ja tuoteomistajan roolin avulla), mutta tuotehallinto joutuu sisäisesti ratkaisemaan, kuinka he ohjaavat kokonaisuutta strategian näkökulmasta. Tähän tuotekehityksen johtoryhmä on toimiva ja usein tarpeellinen ratkaisu. Samalla voidaan synkronoida hankkeita myynnin ja markkinoinnin kanssa.
Seuraavassa artikkelissa voitaisiin avata tarkemmin ketterää tiekarttaa.
Pitkäjänteinen tuoteportfolion hallinta on tosiaan edelleen pahasti erillään nykyisistä Scrum-käytännöistä, ja kun mukaan sotketaan tuotemarkkinoinnin aikataulut, tuotteiden tekniset riippuvuudet, partnerit, tekniset velat, arkkitehtuurit ja markkitehtuurit, soppa on melkoinen.
Oma kokemukseni on, että hyvillä tuotepäälliköillä on omat lempimenetelmänsä portfolion hallintaan. Tiimin ja tuotejohdon väliin tarvitaan kokenut “tuonelan lautturi”, joka osaa viestiä molempien maailmojen kanssa. Kun tuotteita, tuotepäälliköitä ja kehitystiimejä on useita, PO:n (tai mieluummin tietysti PO-tiimin) vastuulle jää ohjata hommaa tuotestrategia ja tuotejohtoryhmä selkänojanaan. Haasteena on toteuttaa tämä niin, ettei PO:ta koeta pullonkaulaksi, ja löytää organisaatiolle sopivan skaala ja rytmi.
Scrum ottaa hyvin vähän kantaa itseasiassa mihinkään. Olimme taannoin Ari Tannisen kanssa puhumassa tästä aiheesta Tampereen yliopistolla oliopäivillä, jossa kerroimme kolmesta “puutteesta”, jotka sivuavat osittain artikkeliasi.
Esitys:
http://huitale.blogspot.com/2009/12/oo-day-2009-presentation-scrum-is-not.html
Kiitos Marko erinomaisesta presentaatiosta ja tervetuloa!
Todellakin, Scrum ei ota suoraan kantaa firman liiketoimintaan ja antaa vain niukasti neuvoja ohjelmistokehityksen menetelmiin (iteratiivisuus ja inkrementaalisuus, säännölliset potentiaaliset julkaisut, definition of done) sekä tuotekehityksen organisointiin (pienet alle 12 hlö tiimit, mieluiten dedikoitu PO ja SM, jne.).
Hyvistä huomiostanne voisi epäsuorasti mieltää, että nämä puutteet olisivat Scrumin “ongelma”. Onneksi meillä on kokemusta RUP:n kaltaisista järkäleistä, joista pitää ensin poistaa puolet ennenkuin menetelmää voi hyödyntää. Tällaista kaikenkattavaa, muttei mihinkään sopivaa ohjeistusta kukaan tuskin halajaa.
Scrum on siitä loistava, että se määrittelee puitteet, joissa voi yhdistellä ja hyödyntää useampia omaan tekemiseen parhaiten sopivia menetelmiä, kuten XP, TDD ja Lean Development.
Kuten esityksenne ansiokkaasti tuo esiin, on lisäksi tärkeää ymmärtää ettei Scrum todellakaan ratkaise yhtiön liiketoimintaa tai tuotekehityksen kaikkia ongelmia, vaan tekee niistä näkyvämpiä, jotta asiat voidaan korjata.