S3-kokemuksia belgialaisessa nunnaluostarissa

Ensimmäinen Sociocracy 3.0 Practitioner Course Level 2 -koulutus järjestettiin syyskuussa Belgiassa, alkuperäisten Sosiokratia 3.0 -mallin kehittäjien järjestämänä. Codentolaisille Anu Takalalle ja Karoliina Luodolle jatkotason koulutus tarjosi paitsi kauniita luostarimaisemia keskellä belgialaista maaseutua, myös välineitä S3-päätöksenteon fasilitointiin sekä tukun uusia oivalluksia. Tarjolla iltamietinnöille oli myös olutta, luostarissahan sitä oltiin.

Kaikilla koulutukseen osallistuneilla oli jo kokemusta mallin toteuttamisesta omissa organisaatioissaan, joten pelkän Sosiokratia 3.0:en liittyvien perustermien ja käytänteiden kertaamisen sijaan päästiin vaihtamaan aitoja käytännön kokemuksia ja pohtimaan ratkaisuja koettuihin haasteisiin.

Sosiokratia 3.0 -mallin alunperin kehittäneet Bernhard Bockelbrink ja James Priest olivat mukana koulutuksessa. Oli todella hienoa päästä heijastelemaan ajatuksia molempien mallin kehittäjien kanssa – perustajista Bockelbrink ei itse kouluta mallia, joten hänen osallistumisensa ylipäänsä oli harvinaista herkkua. Lisäksi kolmantena kouluttajana toimi niin ikään mallin kehittämisestä vastuussa oleva Liliana David.

Kokemuksien jakaminen tärkeä anti

Koulutukseen osallistui paljon Lean- & ketterien menetelmien parissa yleisestikin työskenteleviä konsultteja ja asiantuntijoita. Vaikka nämä menetelmät ja itseohjautuvuus ovat usein nimenomaan ohjelmistoprojektien keskiössä, koulutuksen osallistujissa ei ollut pelkästään ohjelmistoalan yrityksiä, vaan joukkoon mahtui monipuolinen kattaus eri toimialojen organisaatioita.

Kansainvälisen osallistujakunnan joukossa oli ohjelmistokehityskonkarien ja Agile-konsulttien lisäksi mm. terveydenhoitoalan edustajia sekä asukasyhdistysten kanssa työskenteleviä toimijoita. Ja kaikilla oli kuitenkin yhteinen tarve mahdollistaa osallistavaa päätöksentekoa sekä viedä toimijoita itseohjautuvampaan suuntaan.

Codentolla S3-mallia on harjoiteltu kohta jo pari vuotta, ja muiden organisaatioiden kokemusten kanssa löytyi paljonkin yhteneväisyyksiä. Workshopeissa vaihdettiin ajatuksia ja käytännön esimerkkejä erilaisten organisaatioiden Sosiokratia 3.0 -hankkeista, ja pohdittiin ratkaisuja kohtiin, joissa kompastelua tapahtuu. Lisäksi mietittiin miten vaikkapa päätöksentekoa kannattaisi fasilitoida, jotta S3-mallin peruselementeistä mm. suostumuspohjaisuus, läpinäkyvyys, jatkuva parantaminen ja tehokkuus toteutuisivat – oli kyse sitten espanjalaisesta, venäläisen tai hollantilaisesta työkulttuurista muilta osin.

S3 ei ole pelkkiä ulkoisia sääntöjä

Monet osallistujista olivat kokeneet S3-termistön hankalahkoksi omaksua ja päätöksenteon erilaiset käytännöt haasteelliseksi selittää yleisöille, jotka ovat tottuneet perinteisen mallin kokouskulttuuriin ja  valta-asetelmiin. Codentollakin ensimmäiset S3-mallin mukaiset palaverit kuluivat monesti esimerkiksi sen pohdintaan, missä järjestyksessä palaveriin kuuluva check in -kierros tulisi tehdä. Toisinaan toki kuuluu vieläkin huokauksia, kun työtuolien hankintaan paneudutaan S3-mallisella pieteetillä.

Koulutuksen suurimmaksi anniksi nousikin oivallus siitä, että oikeaoppisten sanaston ja S3-käytäntöjen sijaan tärkeämpää on ymmärtää, miksi mallissa toimitaan sosiokratian määrittelemällä eikä ns. perinteisellä tavalla. Termien oikeellisuuden pohtimisen sijaan olisi olennaisempaa miettiä, mikä on se ongelma tai jännite päätöstarpeen taustalla, ja miksi esimerkiksi ollaan keräännytty tietyn päätöksen ääreen ja että asiaa ovat ratkaisemassa ne, joita asia koskee.

Käytännön harjoitustakin toki tarvitaan varsinkin tilanteessa, missä uusien rekryjen kautta saapuu väkeä, jotka ottavat vasta ensiaskeliaan mallin parissa. Kun S3 on ajettu osaksi organisaation normaalia arkea, on myös helpompi keskittyä niihin motiiveihin ja voimiin, joiden takia päätöksentekoa halutaan ylipäänsä tehdä S3-mallilla, sosiokratian meta-tasoon.

Sosiokraattisessa päätöksenteossa kaistaa halutaan erityisesti käyttää päätöksiin ajavien jännitteiden ja drivereiden tunnistamiseen. Käytännön fasilitoinnissa se tarkoittaa esimerkiksi sitä, että osataan tunnistaa, milloin asia on sellainen, että se oikeasti vaatii yhteistä päätöksentekoa ja milloin asian voi vain tehdä alta pois. Sama asia käytännössä: toimiston käytännönjärjestelyjen osalta on olennaista, että kaikilla on mahdollisuus olla mukana päätöksenteossa, mutta sen puhelimen varavirtalähteen voi vaikka hankkia ihan itse, sen kummemmin lupia kyselemättä. Mukava työkaveri toki kysyy siihen päälle, josko joku muukin tarvitsee samanlaista, niin hoituu sitten kerralla pelivermeet työkaverillekin.

S3 vaatii myös päätöksenteon perustyötä

Mallin omaksumisen ja toiminnan kannalta on erityisen tärkeää, että ne, jotka ovat organisaatiossa perehtyneet tarkemmin Sosiokratia 3.0 -malliin, vievät tietoa eteenpäin ja auttavat ihmisiä siinä kohtaa kun tukea kaivataan. Toinen koulutuksen tuoma tärkeä oivallus oli se, että S3-mallin päätöksenteko ei kaikesta toimivuudestaan huolimatta pelasta normaaleilta hyvän päätöksenteon arkiruutineilta.

Päätösten ja asioiden valmistelu on edelleen ja ehkä jopa entistäkin tärkeämpää. Kun yhteinen päätös tehdään esim. 40 ihmisen voimin, keskustelussa asiassa pitäytyminen on olennaista ihan puhtaan ajankäytön vinkkelistä. Jännitteiden havaitsemiseen ja analysointiin, drivereiden luontiin sekä haasteiden ratkaisuehdotuksiin pitää käyttää valmistelussa aikaa, jotta malli palvelisi tarkoitustaan ja ihmiset pääsisivät jo hyvin varhaisessa vaiheessa päätöksentekoon mukaan.

Harjoituksen tuloksena hyvin valmisteltu sosiokratian mukainen päätöksenteko voi sitten tapahtua nopeastikin. Tästä esimerkkinä vaikkapa eräs Codenton viikkopalaveri: normaalien agenda-asioiden (12 piirin kuulumiset) lisäksi päätettiin yhteisesti sekä yrityksen hallituksen uudesta organisoitumisesta, seuraavan vuoden kasvutavoitteista että Codenton mentorointimallista. Kestoa tällä koko henkilöstön palaverilla oli 49 minuuttia!

Sosiokratia 3.0 -mallia kehitetään edelleen niin kokemusten kuin organisaatioiden tarpeidenkin pohjalta. Koulutuksessa tuli uusina S3-asioina paljon sellaista, jonka avulla myös isommat organisaatiot pystyvät hyödyntämään mallia päätöksenteon välineenä. Näissä ollaan usein totuttu hierarkisiin rutiineihin, jolloin hyppääminen S3-malliin voi olla haasteellista – mutta myös varsin vapauttava kokemus kun kaikki, joilla on asioihin annettavaa ja joita päätös koskee pääsevät vaikuttamaan päätöksiin.

Koulutuksen jälkeen Codenton S3-arki jatkuu entistä turvallisemmissa puitteissa. Anu ja Karo pyrkivät osaltaan varmistamaan että ne Sosiokratia 3.0 -käytännöt, joita Codentolla käytetään, eivät lähde ilman syytä irtoamaan kehittäjien tarkoittamasta suunnasta vaan pysyvät ajan tasalla ja elinvoimaisena. Ja ensisijaisesti palvelemassa tarvetta organisoitua ihmisläheisten perusperiaatteidensa kautta.

 

Katso Codenton avoimet työpaikat

 

Projektin ei tarvitse olla painajainen

Lähes jokainen voi hyvällä omallatunnolla sanoa olleensa mukana projektissa tavalla tai toisella. Ja ihan liian iso osa on kokenut myös projektityöhön liittyvää epäselvyyttä, aikataulupaineita ja projektiriippuvuuksien tuskaa, mistä syystä pahimmillaan projektista on tullut sallittu synonyymi painajaiselle. Projektin onnistumisen kannalta on tärkeää, että tavoite ja sen tekemiseksi tarvittavat resurssit ja aikataulu on ymmärretty oikein. Ketterien menetelmien käyttö puolestaan lyhentää palautesykliä ja mahdollistaa dynaamiset muutokset aikataulussa, tavoitteissa ja resursseissa.

Ohjelmistoprojektien monimutkaisuudesta

Neutraalisti katsottuna projekti on kokonaisuus, jolle on määritelty ajallinen alku, loppu ja selkeä päämäärä sekä tekijät, joilla päämäärä on saavutettavissa. Varsinkin isomman kokoluokan projekteissa kompleksisuutta lisäävät erilaiset riippuvuudet.

Ohjelmistopuolella kompleksisuus johtuu usein myös systeemien monimutkaisuudesta, olemassa olevan ympäristön perintönä saadusta vanhentuneesta koodista tai pysyvästi sementoiduista taaksepäin yhteensopivuus -vaatimuksista. Tai kun on otettu teknistä velkaa jättämällä koodin siivous kiireessä sivuun.

Ohjelmistoprojektien haasteet harvoin tekijöiden syytä

Harvoin ohjelmistoprojektien ongelmat liittyvät kuitenkaan tekijäporukkaan, joka yleensä koostuu asiantuntijoista ja alansa ammattilaisista. Heillä on tarvittava osaaminen ja halu oppia, joilla taklataan kiukkuisimmatkin riippuvuudet tai tekniset haasteet. He osaavat myös määrittää järkevät etenemisvaihtoehdot, kun törmätään isompaan siirtokivilohkareeseen.

Mikä ohjelmistoprojekteissa sitten mättää?

Mikä ohjelmistoprojekteista sitten tekee niin kiharaisia? Ja miksi asiakkaat saavat eteensä järjestelmiä tai käyttöliittymiä ymmärryksen tuolta puolen? Vastauksia lienee yhtä monta kuin on tuuliajolle menneitä projektejakin. Usein taustalla kuitenkin kytee tekemisen jäykkyys tai joku seuraavista perustavaa laatua olevista projektihelmasynneistä – perinteisen projektikolmion kautta katseltuna:

Puhun mielelläni ohjelmistokehityksessä ihmisistä resurssien sijaan ihan vaan siksi, että ihmiset ne käytännössä toteuttavat ohjelmistojen toiminnallisuudet. Muu resursointi tulee yleensä laiteinvestointien, jne. puolesta ja näillä katetaan pidemmän aikavälin tarpeita.

1. Epäselvä tai epärealistinen tavoite

Selkeys siitä, mitä on tarkoitus saada aikaiseksi näyttelee isoa roolia projektin onnistumisessa. Harmittavan usein (sisäinen/ulkoinen) asiakas tai arkkitehti lähtee harhailemaan tontiltaan ja päätyy kuvaamaan sitä, miten hänen haluamansa asia toteutetaan, kun se mitä oikeasti tarvittaisiin, olisi selkeä tarpeen kuvaus. Kehittäjät kyllä keksivät järkevimmän toteutustavan, kunhan heille kerrotaan mitä halutaan ja miksi. Speksailu vailla vastuuta kokonaisjärjestelmän toimivuudesta on tietysti jännää, mutta useimmiten se hidastaa ja hankaloittaa kehitystiimien työtä –  heille kun olennaisinta olisi saada ymmärrys siitä, mitä halutaan. Näennäisen valmiin ratkaisun ojentaminen kehittäjille alentaa heidät samalla puhtaiksi koodikirjureiksi, mikä myös syö tekijöiden motivaatiota.

Ajan käyttäminen siihen, että pystyy kertomaan selkeästi mikä on ratkaistava ongelma, missä asiayhteydessä ongelma esiintyy ja millainen vaikutus sillä on asiakkaan elämään on tärkein panostus, jonka tilaajapuoli voi kehitystyölle antaa. Lopusta huolehtivat asiansa osaavat ja systeemiä ylpeydellä ylläpitävät koodarit.

2. Riittämättömät resurssit tavoitteen saavuttamiseksi

Eli keksitään se Hillittömän Hieno Juttu, joka tarttis tehdä ja mielellään heti. Sitten ei kuitenkaan olla valmiita valitsemaan niitä asioita, mitä sitten jätetään tekemättä tai miettimään, mikä oikeasti on paras taho toteuttamaan haluttu toiminnallisuus ja mitä nämä tiimit parhaillaan tekevät. Tai kieltäydytään kuulemasta toteuttajien arviota siitä, millaisella työpanoksella toiminnallisuus on tehtävissä.

Taas kerran tullaan siis takaisin siihen, että pitäisi olla kyky ja halu miettiä, mikä nyt olikaan tekemisen tärkeysjärjestys ja mihin rahkeet riittävät. Tai pohtia, mitä se tarkoittaa, kun järjestelmään lähdetään lisäämään toiminnallisuutta ns. sankaritöinä. Valmis toiminnallisuus pitäisi kuitenkin nähdä myös ylläpidon, skaalautuvuuden, suorituskyvyn ja jatkokehityksen, jne. vinkkelistä. Puoliksi tai sinnepäin tehdyt toiminnallisuudet ja järjestelmät ovat ne kalleimmat toteutuksen puolesta, oli tekijä sitten omasta talosta haalittu iskujoukko tai ulkoinen konsultti.

Ohjelmistoprojektit harvoin onnistuvat sillä, että liiketoimintapuolen Excel saadaan näyttämään rivit nätisti. Ihmisten osaamisen taso, oppimiskäyrä tai vaikkapa koodaamisen nopeus eivät ole vakioita ja riippuvat paljolti esim. käytettävien teknologioiden tai kielten tuttuudesta. Kehittäjätkin ovat ihmisiä, joilla on oma työn ulkopuolinen elämä (vaikka legenda toisin väittääkin). Heillä on yhtä lailla perheitä, koiria, lomia ja tarpeita hoitaa ne samat pankkiasiat kuin tilaajillakin. Tällaiset pitää huomioida, kun mietitään missä ajassa lopputulos voi realistisesti valmistua.

3. Epärealistinen aikataulu

Yllämainittujen lisäksi projektin onnistumiseen voi helposti vaikuttaa asettamalla aikataulun, jossa on mahdotonta pysyä ottaen huomioon asetetut (epäselvät/ristiriitaiset) tavoitteet ja (puuttuvat) kehittäjät.

Epäonnistumista voi pedata sillä, että ei kysytä asiantuntijoilta, mitä toiminnallisuuden toteuttaminen aidosti vaatii ja neuvotella sen jälkeen riittävästä toteutuksen tasosta – aikataulu, haluttu laatutaso ja tekijöiden saatavuus huomioiden. Kun luullaan, että yhden valintaruudun toteutus hoituu yhtä sukkelaan kuin designerin  flash-animaationa toteuttama näkymä, vaikka taustajärjestelmiin saman toteuttaminen myös niiden ei-toivottujen käyttäjätarinoiden (ns. rainy day -skenaariot) ja lokituksen & auditoinnin kanssa on huomattavasti työläämpää. Ja näitähän tehdään, jotta käyttäjiä voidaan jatkossa myös tukea. Tästähän ei se flash-animaatio kerro mitään.

Lue lisää Pimeän agilen välttämisestä.

Ketterä toteutus kokonaisuudessaan edullisempi

Valittu tapa tehdä ohjelmistoprojekti on kunkin organisaation päätettävissä. Itse olen paketoinut projekteja sekä vesiputousmallilla että ketterillä menetelmillä, eikä menetelmä itsessään ole kynnyskysymys.

Jos valita saan, hoidan projektini ketterästi. En siksi, että se olisi jollain tapaa viileämpää jutella ketterästi Scrumia tai Kanbania, vaan siksi, että ketterä toteutustapa mahdollistaa käyttäjää paremmin palvelevan ja kokonaiskuvassa edullisemmaksi tulevan toteutuksen.

Nopeat muutokset, joita väistämättä tulee, ovat mahdollisia niin tavoitteissa, budjetoinnissa kuin aikataulussa – maailma harvoin pysähtyy odottamaan, että juuri minun edellisenä vuonna kerran määrittelemäni projekti valmistuu seuraavaksi jouluksi muuttumattomana.

Kullankallis käyttäjäpalaute

Mitä nopeammin aidot käyttäjät pääsevät testaamaan ominaisuuksia, sitä nopeammin saadaan palautetta kehitystyöhön sekä korjauksia takaisin ominaisuuksiin. Pienilläkin muutoksilla on toisinaan ratkaiseva merkitys käyttäjän kannalta – ketterässä kehityksessä nopea palautesykli ja jatkuva parantaminen kuuluvat tekemisen luonteeseen.

Minusta projekteja on aina ollut hauskaa tehdä, kiitos ässien kehitystiimien ja arvokkaan asiakaspalautteen. Projektit rullaavat varsinkin, jos ne on valmisteltu huomioiden kolme kulmakiveä:

  1. tavoite
  2. ihmiset + mahdolliset muut resurssit
  3. aikataulu.

Kaikki muu on sen jälkeen pienempää ratkottavaa.