Mõned päevad tagasi pöördus meie poole ettevõte juht, kes uuris, millised on võimalused suurendamaks meeskonnaliikmete motivatsiooni ja kaasatust uute lahenduste väljatöötamiseks ning nende elluviimiseks. Kui inimese motivatsioon on madal, siis puudub tal igasugune soov uurida ning testida uusi lahendusi. Olla uudishimulik. Järjepideva arengu puudumisel väheneb kliendi jaoks ettevõtte poolt pakutava teenuse atraktiivsus (kvaliteet, hind) ning ta on aldis otsima alternatiive. Tihti me unustame, et lisaks kliendile pakutavale teenusele on organisatsioon ka teenuspakkujaks nendele inimestele, kes kliendile selle väärtuse loovad. Inimesed ühinevad organisatsioonidega selleks, et ellu viia oma isiklikke ideid ja unistusi. Olgu selleks siis kas võimalus selles töökohas professionaalselt areneda või teenida rahalised vahendid.

Nii peabki juht otsima pidevalt vastust kahele olulisele küsimusele:

  • milline peaks olema ettevõtte poolt pakutav teenus tulevikus, et see selgelt eristuks konkurentidest ning tagaks organisatsioonile positiivse rahavoo;
  • millise võimekuse ehk organisatsioon on vaja luua, et selline teenus saaks reaalsuseks ning et seda suudetakse kliendile suurepärasel moel pakkuda.

Mõlema küsimuse puhul tuleb teha otsuseid, millel on pikaajaline mõju. Tulevikku ette ennustada on väga keeruline ning enamus valikuid peab juht langetama olukorras, kus me omame vaid 10% vajalikust infost.

Analoogne olukord on omane ka tarkvara arendusprotsessile. Paljud meist on kogenud olukorda, kus tarkvara lahendust tellides ei saa see kokkulepitud tähtajaks valmis kokkulepitud eelarve piires. Kui asi valmis saab, siis ei näe ta tihti välja selline, kui tellimuse koostamise hetkel algselt ette kujutati. Põhjus on lihtne ja seda on tõendanud praktika. Ei arendaja ega tellija ei oska ega suuda protsessi alguses 100%-lt ette kujutada, milline saab tulemus olema. Praktika näitab, et ettearvatus on 10-20% vahel. Oluline on mõista, kuidas loodav lahendus kliendile väärtust loob ning millised on edukriteeriumid. Teenus ise areneb nn evolutsioonilisel meetodil, läbi lühikeste arengutsüklite ning vahetulemuste pideva testimise vastu klienti. Nii välistatakse aja ja raha raiskamine asjadele, mis kliendi jaoks tegelikult väärtust ei loo.

Kui ettearvatuse tase on tavamajanduses sama kõrge kui tarkvara arenduses, siis miks mitte kasutada organisatsioonide ja nende teenuste arendamises samasugust arendusprotsessi, mis on oma efektiivsust juba paar aastakümmet edukalt tõestanud. See protsess on oma olemuselt lihtne ning selle üks guru’sid, Jeff Sutherland, on kirjutanud raamatu “Scrum: Kuidas 2 korda vähemaga saavutada 2 korda rohkem”.

Kõige keerulisem on siin mõtteviisi muutus. Kuidas lahti lasta oma vanadest planeerimise harjumustavadest. Püüda ette ennustada detailselt kogu projekti elluviimise tegevusplaan, vajalikud ressursid ning nende omavahelised sõltuvused. Niipea kui selline plaan on saanud valmis, siis avastame, et maailm on vahepeal muutnud ning nii võibki fookus liikuda väärtuse loomiselt pidevale plaani ja kokkulepete uuendamisele. Tegelikult me ei vaja tegevusplaani, meil on vaja tulemust.

Agiilne tarkvaraarendusprotsess oma olemuselt ei ole midagi keerulist ja seda on võimalik rakendada kiiresti (lühijuhendi leiad siit). See on loomulik protsess, kuidas me igapäevaelus asju teeme. Siin on kolm olulist elementi:

  1. kuidas me eesmärke seame, kuidas me suure tüki väiksemateks osadeks kirjeldame ja nende teostamise järjekorra otsustame. Plaani detailsus kasvab tulenevalt sellest, mida lähemale konkreetne osa teenuse loomest jõuab. Teenuse arendamisel lähtutakse sellest, et esmalt viiakse ellu asjad, mis loovad kliendi jaoks suurimat väärtust ja meeskond fokuseerib korraga ainult ühe asja elluviimisele.
  2. kuidas me otsuseid teeme, lihtsate kindla struktuuriga koosolekute käigus planeeritakse tegevusi, võetakse vastu tulemid ning otsitakse võimalusi, kuidas meeskonna koostöö tulemuslikkust kasvatada. Kui koosolekutele kulub üle 20% inimese tööajast, siis ei toimi efektiivselt organisatsiooni kommunikatsiooni arhitektuur. Tihti soovivad inimesed kokku kutsuda koosolekuid selleks, et nad ei saa ise oma tööga iseseisvalt hakkama. Koosolek ei ole sellisel juhul efektiivne lahendus.
  3. loodud on selged rollid ja vastutused, et kokkumäng tulemuslikult toimiks. Rollid on suures plaanis jaotatud kolmeks:
    1. tooteomanik – kelle vastutus on, et kliendile luuakse toode, mis vastaks just tema ootustele kõige efektiivsemal moel. Tema ülesanne on hoida teostatavate asjade loetelu pidevalt (iganädalaselt) uuena ning seda järjestada tulenevalt olulisusest ja arenduse käigus selgunud uutest asjaoludest. Mis iseloomustab head tooteomanikku, leiad siit.
    2. arendusmeeskond – meeskond, kelle ülesandeks on välja mõelda, kuidas vajalikud asjad saavad ära tehtud ning siis ellu viidud. Meeskond otsustab kui mitu asja järjestatud loetelust suudetakse nädala jooksul ära teha ning millisel moel sisemiselt oma tööd korraldatakse.
    3. scrum master – kelle ülesandeks on tagada et meeskonnas peetakse kinni kokkulepitud kommunikatsiooni arhitektuurist, toimivad kokkulepitud koosolekud kokkulepitud moel. Vajadusel modereerib neid.

      Tehnoloogiamaailmast teame – selleks, et kaks seadet (näiteks arvuti ja printer) koos töötaksid (paberile trükitud tekst), peavad nad olema ühendatud, s.t. edastatud sõnum peab olema kindlas formaadis ja edastatud kindla sagedusega. Kui kommunikatsiooni protokoll on paigas, siis võib ühendada ühte võrgustikku n+1 seadet.

      Sama kehtib ka organisatsioonide puhul – kui hoida suhtlusprotokoll hoida lihtne ja standardne, siis saab organisatsioon kiiresti kasvada. Iga meeskond on autonoomne teenus, mis loob kindlat väärtust ning organisatsiooni võrgustikuga toimib ühtse protokolli alusel. Kõik toimib sama lihtsalt, kui wifi võrguga ühildumine või näiteks seadme elektrivõrku ühendamine. Kui protokollid ei ühildu, siis teame, millist pinget ebaõnnestunud liitumine meis tekitab.

Minnes nüüd oma loo alguse juurde tagasi, siis kuidas saab juht oma probleemi edukalt lahendatud? Universaalset lahendust konkreetsele probleemile ei ole. Iga organisatsioon on eriline ja kuidas konkreetne probleem organisatsioonis ilmneb, on ainulaadne. Kuid kui mõelda, et organisatsioon pakub seal töötavatele inimestele eneseaarengu teenust, siis saab juht organisatsiooni arendamisel edukalt kasutada eelpoolkirjeldatud põhimõtteid.

  • Esiteks on vaja defineerida põhjus (miks inimesed ei ole motiveeritud) ning sõnastada, milles probleem väljendub. Viimaste teadmisel on meil võimalus hinnata ka probleemi rahalist mõju organisatsioonile viimasel 12 kuul. Raha on universaalne ekvivalent, mis aitab meil määratleda probleemi olulisust. Ei ole mõtet tegeleda probleemi lahendamisega, kui te ei suuda hinnata selle mõju.
  • Järgnevalt sõnastage, milline võiks olla soovitud lahendus ning mis on tõendused, et see lahendus hästi toimib. Iga tõendus püüdke kirjeldada mõõdetava tulemusena ning hinnake selle rahalist mõju järgneva 12 kuu perspektiivis. Kui te ei suuda rahalist mõju hinnata, siis võib-olla ei ole see asi, mis tegelikult on oluline.
  • Alustage sellest, millel on kõige suurem mõju ning seadke meeskonnas eesmärgiks, et see saab tehtud 30 päevaga. Eesmärgi saavutamiseks määratlege  3-5 võtmetegevust, läbi mille eesmärk on saavutatav. Et hinnata, kas võtmetegevus saab hästi tehtud, siis seadke talle mõõdik, mis selle täitumist kõige paremini iseloomustab ning mis on see tulemus, mida te soovite saavutada. Et asjad saaksid tehtud, määrake igale võtmetulemusele omanik (product owner). Tema ülesandeks jääb hallata ärategemist vajavate asjade loetelu ning neid olulisuse põhimõttel prioritiseerida. Kõigi meeskonnaliikmete ideed on teretulnud, kuid neid järjestab võtmetulemuse omanik.
  • Kord nädalas hinnake meeskonna koosolekul iga võtmetulemuse täitumise tõenäosust ning leppige kokku, mis saab nädalaga tehtud, et võtmetulemuse täitumise tõenäosus suureneks. Planeerimisest pelgalt ei piisa, vaid asjad on vaja väikeste arendustsüklitega ära teha.
  • Ja kõige tähtsam on iga tsükli (nädala, kuu) lõpus hinnata, kuidas meeskonna koostöö toimib, mis vajab siin parendamist. Vaid nii õpib meeskond tulemuslikumalt toimima.

Organisatsiooni loomisel täidab juht enamasti tootejuhi rolli, kuna esmalt on vaja luua kliendi jaoks atraktiivne teenus. Kui plaan on elustiili äri kasvatada suureks, siis liigub juhi tegevusfookus aina rohkem organisatsiooni arendusele (scrum master).

  • Nädala raamat – Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland. Raamatus leiad hulga värvikaid näiteid, kuidas selline protsessi juhtimisele lähenemine aitab saavutada tulemusi kordades efektiivsemalt.
  • Nädala film – Le Mans ’66 – olenemata organisatsiooni tavadest ning juhtide poolt loodud takistustest, suudab meeskond saavutada suurepärased tulemused. Mõnikord me ise ei panegi tähele, et me just nii käitume. Hollywood tuleb appi ning võimendatult näitab kõik sellised situatsioonid ette.

 

Andres Haavel