Tämä blogi on jatkoa Cynefin mallin yleisesti esitelleelle blogilleni.
Cynefin mallissa ei ole oikeaa tai väärää tilaa. Kaikille viidelle tilalle on tarkoituksensa. Mallin arvo muodostuu tilojen välisistä siirtymistä.
Kuvassa 1 avataan ohjelmistoprojekteista tuttuja prosesseja Cynefin mallin avulla. Ketterissä menetelmissä löydetään kokeilemalla kompleksisessa ympäristössä uusia, muotoutuvia toimintamalleja. Näitä toimintamalleja rajoitetaan ja kontrolloidaan toistettaviksi, niin että niitä voidaan siirtää vaikean ympäristön hyviksi käytännöiksi. Hyviä käytäntöjä on mahdollista skaalata laajempaan käyttöön. Suosituimmat käytännöt standardoidaan yksinkertaisen ympäristön parhaiksi käytännöiksi. Ympäristön muuttuessa toistetaan yhä sokeasti yksinkertaisen ympäristön parhaita käytäntöjä ja ajaudutaan kaoottiseen ympäristöön, jolloin kovalla työllä joudutaan selvittämään mikä on muuttunut ja ketju alkaa alusta.
Nopea muutos vaatii enemmän ketteryyttä
Muutos nopeutuu nykyajan maailmassa ja osa järjestelmistä on jo jatkuvassa muutoksessa, jolloin ympäristön toimintaa ei voida lainkaan standardoida. Karrikoiden Cynefin mallin vasen puoli luo näkemyksiä ja oikea puoli tuotteita. Vasen puoli vaatii leadershippia ja oikea puoli managementtia. Kuvassa 2 hahmotellaan projektityölle tuttuja pullonkauloja Cynefin mallin avulla.
- Esimerkki 1 mallintaa projektin epävarmuuden kasvamista. Siirtymä Cynefin mallissa tapahtuu usein henkilöiden välisessä kommunikaatiossa. Tehtävän tilaaja voi olla siinä ymmärryksessä, että tehtävä on yksinkertainen ja suoraviivainen suorittaa. ”Yhdistät vaan kaikki metroa valvovat järjestelmät keskitettyyn turvallisuusjärjestelmään.” Tehtävän toteuttajan saadessa tehtävän pöydälleen, ilmenee että kyseessä onkin pikemminkin laaja ja kartoittamaton projekti, kuin suoraviivainen toteutustehtävä. Koska tehtävä kuitenkin on annettu, niin sitä lähdetään jostain kulmasta työstämään kohti kuviteltua ”valmista”-tilaa. Tässä tapahtuu Cynefin mallin siirtymä yksinkertaisesta kompleksiseen.
- Esimerkki 2 mallintaa projektin monimutkaisuuden kasvamista. Esimerkiksi olemassa olevaan legacy-järjestelmään lähdetään toteuttamaan uutta ominaisuutta. Paperilla uuden ominaisuuden toteutus vaikuttaa suoraviivaiselta, mutta koodissa joudutaankin tekemään paljon refaktorointia, mikä Cynefin mallissa kuvastuu siirtymänä yksinkertaisesta vaikeaan.
- Esimerkki 3 kuvastaa monitoimittajaympäristöstä, missä toimittajat pimittävät kilpailullisista syistä tietoa toisiltaan. Laaja projekti näyttää paperilla työläältä mutta loogiselta. Työn edetessä osapuolet pimittävät tekemiään teknisiä ratkaisuja, jolloin projektin tila siirtyy vaikeasta kaoottiseen, koska kukaan ei enää tunne kokonaistilannetta.
- Esimerkki 4 kuvaa liian yksinkertaisesta (one sliders) kommunikaatiosta johdon kanssa aiheutuvaa tilanteen epäselkeyttä. Yleisesti projektinjohdossa ja varsinkin projektiliiketoiminnassa vaaditaan selkeyttä ja itsevarmuutta projektin tilasta. Usein kukaan ei uskalla todeta tilaajalle tai ostajalle, että projekti on todellisuudessa kompleksinen, eli sen etenemisen polusta ei voida olla varmoja. Vasta kun sopimukset on kirjoitettu ja työt aloitettu, alkaa bisneslogiikan tai teknologian muodostama kompleksisuus avautua myös tilaajalle.
Ketteryyttä vai vesiputouksia
Vesiputousmalli sopii erinomaisesti tilanteeseen missä tiedetään tarkalleen mitä halutaan tehdä. Määrittely, suunnittelu, toteutus ja testaus voivat olla työläitä ja aikaa vieviä, mutta eivät sisällä epävarmuustekijöitä. Joidenkin osa-alueiden suunnittelu ja toteutus voi vaatia asiantuntijoiden apua, mutta nämäkään tehtävät eivät sisällä epävarmuutta. Tällöin toimitaan yksinkertaisen ja vaikean toimintaympäristön välillä toimivalla maaperällä. Kuva 3 avaa näitä ohjelmistonkehitykselle tyypillisiä tilasyklejä.
- Vesiputousmallissa projektin vaatimus-hinta-aika kolmio suunnitellaan jo etukäteen. Tämä johtaa mammuttimaisiin suunnitelmiin, koska vaatimustenkeräysvaiheessa on tärkeää pyrkiä listaamaan jokainen mahdollisesti tarvittava ominaisuus. Tämä johtaa myös lähes aina aikataulun ja budjetin venymiseen. Tähän on syynä se että etukäteen on mahdotonta arvioida työmäärää realistisesti, jolloin kilpailullisista syistä hinta poljetaan alas. Teoriassa suunnitelmia päivitetään projektin edetessä, mutta todellisuudessa suunnitelmat ovat niin raskaita, ettei niitä ole enää aikaa päivittää projektin käynnistyttyä. Cynefin-mallissa vesiputous soveltuu yksinkertaiseen ja mutkikkaaseen ympäristöön, missä ennustettavuus on tarkkaa.
- Lean pyrkii minimoimaan turhuuden ja lyhentämään tuotannon läpimenoaikoja. Six Sigma pyrkii laadun ja ennustettavuuden kehittämiseen tilastollisten välineiden avulla. Six Sigma kehityshankkeet perustuvat Demingin syklin ympärille rakennetun työkaluvalikoiman hyödyntämiseen. Näistä tunnetuimpia 5 Whys ja Root-Cause-Analysis. Lean Six Sigma perustuu Six Sigman hyödyntämään Demingin sykliin mutta lisää työkaluvalikoimaan myös kaikki Leanista tutut turhuuden vähentämisen työkalut. Nämä kehitysvälineet toimivat parhaiten yksinkertaisessa tai mutkikkaassa ympäristössä, missä nykyistä toimintaa mittaamalla ja kehittämällä voidaan parantaa projektin tulevaisuuden toimintaa. Kompleksisessa ympäristössä työvaiheet taas eivät etene ennustettavasti, mikä vie pohjan tämän kaltaiselta systeemin optimoinnilta. Ohjelmistonkehityksessä Leania käytetään usein synonyymina imuohjaukselle, missä Kanban taulun avulla aloitetaan uusia tehtäviä hyvin kontrolloidusti. Todellisuudessa Lean työkaluja käytetään paljon ketterien projektien kehittämiseen, samoin kuin ketterää ideologiaa hyödynnetään Kanban mallissa.
- Ketterät menetelmät pyrkivät tuottamaan jotain valmista usein ja oppimaan sitten asiakkaalta järjestelmästä saadusta palautteesta. Ideologia painottaa vahvasti avointa kommunikaatiota ja jatkuvaa parantamista. Ketterässä ideologiassa ei stressata niin paljon aika- tai rahabudjetista. Oletus on, että aikaisin ja usein julkaisemalla tiimi toimii niin tehokkaasti kuin mahdollista. Ketterän projektin lopputuotteesta tulee yleensä yksinkertaisempi ja halvempi. Yksinkertaisuuteen päästään sillä että iteratiivisesti toteutetaan asiakkaan vaatimuksia sprintin luoman aikapaineen alla, jolloin monista vähemmän tärkeistä ominaisuuksista ollaan valmiita luopumaan. Halvemmaksi ketterä projekti muodostuu, koska se voidaan lopettaa heti kun järjestelmä on riittävän hyvä. Toisaalta, ketterän projektin lopullista kestoa tai hintaa on alussa ihan yhtä vaikea arvioida kuin vesiputousmallissakin. Näkyvyys projektin kokonaiskestoon paranee sprintti sprintiltä. Cynefin-mallissa ketterä kehitys sopii mutkikkaaseen ja jossain määrin kompleksiseen ympäristöön. Mitä enemmän etukäteissuunnittelua tehdään tulevien sprinttien osalta, sitä haastavampaa siirtyminen kompleksiseen ympäristöön on.
- Tuotehallinnan tai vaatimustenhallinnan suurin haaste on, ellei tiedetä mitä ollaan tekemässä. Sovellusalue on yleensä tiedossa, mutta kenellekään ei ole selvää millainen lähestymiskulma tulisi ottaa. Perinteinen käyttöliittymä vai jotain uutta. Kaikki perinteiset ominaisuudet vai jotain erilaista. Natiivia vai webbiä. Jokainen päätös vaikuttaa muihin päätöksiin. Ollaan kompleksisessa ympäristössä. Cynefin ratkaisee ongelman pienillä rinnakkaisilla ”safe-fail” kokeiluilla. Lean Startup mallissa kokeiluja kutsutaan nimellä ”minimum viable product”, MVP. Reis määrittää MVP:n olevan pienin mahdollinen työpanos bisneshypoteesin testaamiseen asiakkailla. Lean Startup malli siis seuraa Cynefin mallin kompleksisen ympäristön prosessia: kokeile-havainnoi-reagoi.
Ketteryys on mielentila
Hyvin harva projekti uskaltaa aloittaa alusta. Päätä hakataan seinään usein pitkään, koska pelätään tuntematonta. Jos jokin ominaisuus ei useamman sprintin aikana toimi halutulla tavalla, olisi usein viisainta aloittaa ihan tyhjältä pöydältä; Pysähdytään, brainstormataan ja protoillaan, miten asian voisi toteuttaa fiksummin.
If we keep doing what we’re doing, we’re going to keep getting what we’re getting. -Stephen R. Covey
Kokeilevassa kehityksessä on tärkeää pyrkiä ymmärtämään toimintaympäristöä jatkuvasti paremmin. Kun ympäristö muuttuu, niin ymmärrys auttaa selittämään mihin kaikkeen muutos vaikuttaa. Pitää ymmärtää miksi jokin toimii, jos sitä haluaa muokata tai skaalata. Cynefin malli ei tarjoa tähän oikoteitä. Tarvitaan sekä teoreettista että käytännön osaamista, ja myös nöyryyttä toimia aina analyyttisesti. Ketteryys tarkoittaa nopeaa suunnanmuutoskykyä.
Projektinjohtomallia käytetään avuksi projektin edistämisessä. Sekä prosessia, organisaatiota että lopputuotetta voidaan muuttaa, jos asiakkaan etu tätä vaatii. Projekti on ainutkertainen hanke, joka kokoaa yhteen useita organisaatioita ja järjestelmiä. Projektia johdettaessa tulee jatkuvasti eteen uusia tilanteita. On tärkeää suhtautua joka tilanteeseen älykkäästi, ja käydä läpi ajatusketju siitä millainen tilanne on, millainen ratkaisumalli sopii kyseiseen tilanteeseen ja vasta sitten perehtyä itse tilanteeseen. Jos etenemme tottumusten ohjaamana, niin yritämme ratkaista kaikki eteen tulevat ongelmat meille tutuilla toimintamalleilla.
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. -Abraham H. Maslow
Käytännössä ympäristön tilanteen tunnistaminen ei aina ole helppoa ja sen vuoksi ajelehditaan epäjärjestyksen tilassa. Avoimuus, rohkeus ja kanavat käydä keskustelua tilanteen luonteesta puuttuvat usein. Osa ihmisistä pyrkii ratkaisemaan tilanteen valmiilla, yksinkertaisella mallilla. Asiantuntijat väittävät tuntevansa tilanteen ja ehdottavat toista ratkaisua. Lopulta tilanne kehittyy yllättävästi saaden osan tarkkailijoista puhumaan kaaoksesta.
Juurisyy epäonnistumiselle piilee yleensä jäykissä toimintamalleissa ja avoimuuden puutteessa. Ei uskalleta myöntää nöyrästi ettei tunneta tilannetta. Ajetaan jäykkää prosessia väkisin niin pitkään, että huomataan olevamme kaaoksessa. Osapuolien tulee käydä avointa keskustelua projektin etenemisestä säännöllisesti. Kuvia ei saa kumarrella, vaan keskustelun tulee haastaa vallitseva näkemys nykytilasta. Koskaan ei saa tuudittautua siihen, että projektin sponsori oikeasti tietäisi mitä järjestelmän tulee tehdä. Loppukäyttäjät päättävät onnistuuko projekti vai ei. Toimintatapoja tulee muuttaa riippuen vallitsevasta tilanteesta ja toimia joustavasti kohti käyttäjien toivomuksia.
Principles are timeless, universal laws that empower people. -Stephen R. Covey
Prosessin jäykälle seuraamiselle kehityshankkeessa ei ole perustetta, koska ei ole mahdollista monistaa reseptiä menestykselle. Menestys seuraa samoja periaatteita, mutta käytännön tilanne on aina erilainen. Hyviksi ohjelmistotuotannon menestyksen periaatteiksi sopivat esimerkiksi Agile Manifesto tai SAFe periaatteet. Kokemuksen myötä karttuu viisautta toimia oikealla tavalla oikeassa tilanteessa, mutta perusperiaatteita tulee silti aina väsymättä noudattaa.
Lopuksi
Tämä päättää kaksiosaisen Cynefin blogaukseni, missä tutustuttiin lyhyesti Cynefin malliin ja sen soveltamiseen projektinhallinnassa. Suosittelen David Snowdenin Yuotube-taltiointeja lämpimästi kaikille kompleksisuudesta, projektinhallinnasta, kyynisestä brittihuumorista ja kauniista walesilaisaksentista kiinnostuneille.
