Agiilne mõtteviis ja müüdid selle ümber

Mõistet “agiilne” on ilmselt paljud inimesed kuulnud erinevates kontekstides – nii koerte treeningutest rääkides, IT ja tarkvaraarenduse juttudes, organisatsiooni juhtimise teemades, ja mujal. Agiilne mõtteviis keskendub ümbritseva keskkonna uurimisele ja välja nuputamisele, kuidas võimalikult vähese pingutusega oma eesmärgid maksimaalselt hästi ellu viia.
Kirjutan lahti 9 müüti, mis mõiste “agiilne” ümber ringlevad ja mida olen oma töö käigus tihti kohanud.

Müüt nr 1: Agiilne tähendab kiiret ja ülejala tegemist

Seda müüti olen Eestis kõige sagedamini kohanud, näiteks vestluskatked stiilis: “No meil ei ole siin suureks planeerimiseks aega, teeme käbe ära, agiilselt noh” või “See lahendus on jah päris vigane, aga no me agiilselt tegime”. Nendes lausetes pole paraku ühtki tõetera.
Agiilsed tiimid peavad edu saavutamiseks olema kõva distsipliiniga. Planeerimine on agiilses lähenemises kriitilise tähtsusega, aga erinevus on selles, et ei planeerite KÕIKE detailselt ette ära vaid ainult väike lähituleviku lõik ja kui on vaja midagi muuta, siis tehakse kiirelt plaan ringi. Kui teha agiilset arendust õigesti ja testida pidevalt iga tööd vahetult pärast valmimist, siis on vigade arv projektis minimaalne.

Müüdi põhjuseks on ilmselt agiilsete arendusmetoodikate poolik rakendamine ja vähene teadlikkus agiilsuse tegelikust olemusest.

Agiilsuse printsiip nr 9 ütleb, et “Tehnilist täiuslikkust ja head disaini pideva tähelepanu all hoides tagatakse tarkvaraarenduse kiirus ja paindlikkus.”

Müüt nr 2: Agiilne on sama mis Scrum

Kui keegi ütleb, et ta kasutab agiilset metoodikat, siis palun tal alati täpsustada, et millist täpsemalt? Agiilsus on oma olemuselt mõtteviis, mille alla kuulub rida erinevaid metoodikaid nagu Scrum, Kanban, XP, jne. Metoodika annab sulle konkreetse juhendi, kuidas midagi teha. Agiilsus tähendab aga väärtuseid ja põhimõtteid, millele saab baseeruda palju erinevaid metoodikaid.

Müüdi põhjused peituvad asjaolus, et Scrum on maailmas kõige enam levinud agiilne arendusmetoodika, uuringute järgi kasutavad seda üle poole agiilsetest tiimidest (allikas: State of Agile Report 2020).

Müüt nr 3: Agiilne on alati parim valik

Agiilsus ei ole alati toimiv imerohi, ta on kasulik eelkõige neis keskkondades ja olukordades, mis on ebakindlad ja võivad muutuda. Muutused võivad tuleneda näiteks sellest, et veel ei ole täpselt teada, mida kasutajad kõige rohkem vajavad või sellest, et ümbritsev keskkond võib ootamatult muutuda või hoopis mõnest muust välisest faktorist. Igal juhul on agiilsuse tugevuseks hakkamasaamine igal ajahetkel juhtuvate muudatustega.

On olukordi, kus agiilsus ei anna mingit olulist eelist – näiteks projekt, kus iga detail on juba ette 100% kindlusega paigas ja fikseeritud või projekt ei ole eriti suur, uudne ja keerukas või sul lihtsalt puuduvad agiilsuseks vajalikud ressursid – professionaalne tiim ja teadmised agiilsusest.
Olen kohanud selliseid olukordi, aga neid on olnud vähe – tavaliselt elame ikkagi pidevate muutuste keerises.

Müüt nr 4: Agiilses arenduses ei ole planeerimist

Üks müüt, mida olen samuti sageli kohanud – agiilsuses eriti ei planeerita, hakatakse lihtsalt kohe otsast tegema.
Juhul kui sa ei ole seni kuulnud midagi agiilse planeerimise sibulast (Agile Planning Onion), siis siin see on:

Agiilne planeerimine koosneb 6 eri astmest – päris palju, kas pole?
Esimesed kolm (Päev, Tsükkel, Reliis) tehakse agiilse tiimi poolt, järgmised kaks (Toode, Portfoolio) on tooteomaniku töölaual ja viimane (Strateegia) viiakse läbi juhtkonna tasemel.

Nagu varasemalt jutuks oli, on kõik agiilsed plaanid avatud muutustele ja midagi ei ole kivisse raiutud, aga plaanid on alati olemas. Seega, agiilsus tähendab planeerimist, aga mitte jäiga plaani koostamist.

Agiilsuse printsiip nr 2 ütleb, et: “Mõistame muutuvaid olusid, isegi kui need ilmnevad arenduse lõppjärgus. Agiilsed meetodid pööravad sellised muutused meie kliendi konkurentsieeliseks.”

Müüt nr 5: Agiilses arenduses ei ole dokumentatsiooni

See müüt pärineb ilmselt nelja agiilse väärtuse lause hulgast, mis ütleb, et “Me hindame töötavat tarkvara rohkem, kui kõikehõlmavat dokumentatsiooni”.

Agiilne lähenemine ei väärtusta enne projekti kirjutatud kümnete ja sadade lehekülgede pikkust dokumentatsiooni, kus püütakse kogu funktsionaalsus kuni viimse koma ja nupu paigutuseni paika panna. See ei tähenda, et korralik analüüs ei oleks enne projekti vajalik. Lihtsalt inimeste vahetut suhtlust väärtustatakse rohkem kui paberil kirjasõna.

Agiilses projektis ei nõua tellija arendustiimilt täht-tähelt detailse lähteülesande dokumendi järgimist nagu vanasti waterfall-projektide korral, selle asemel täpsustatakse detailid enne iga arendustsükli algust ja kirjutatakse Product Backlogi (mis on oma olemuselt samuti dokumentatsiooni osa). Selline lähenemine annab võimaluse jooksvalt kohaneda uute muudatustega ja luua lõppkokkuvõttes suuremat väärtust.

Dokumentatsioon on agiilses arenduses nagu tavaline tarnitav töö, sellises ulatuses ja mahus nagu tellijaga kokku lepitakse.

Agiilsuse printsiip nr 6 ütleb, et: “Kõige tõhusam ja tulemuslikum viis info jagamiseks arendusmeeskonnas on näost näkku vestlus.”

Müüt nr 6: Agiilses arenduses ei ole projekti tähtaega ja eelarvet

Seda konkreetset müüti või õigemini hirmu kohtab just äriinimeste hulgas, nt “Agiilne arendus ei lõppe ju kunagi” või “Agiilse projekti lõplikku hinda on võimatu öelda”.

Kõik minu agiilsed projektid on olnud konkreetse eelarve piiriga ja veel konkreetsemate tähtaegadega. Võti seisneb selles, et projekti jooksul on tellija tooteomanikul võimalik vabalt otsustada, mida selle raha ja ajaga ära teha ehk skoop ei ole detailideni fikseeritud.
Agiilsetes projektides hinnatakse ALATI eelnevalt arendusmahtu ja keerukust, selle põhjal teeb tooteomanik otsuse, kas saadava ärilise väärtuse ja teostamise kulu suhe ehk ROI on piisavalt hea, et arendus ära teha.

Agiilsuse printsiip nr 1 ütleb, et: “Kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti.”

Müüt nr 7: Agiilsus sobib ainult väikestele projektidele või ettevõtetele ja ei skaleeru

On tõsi, et agiilsed tiimid on väikesed, kuni 10 inimest. See aga ei tähenda, et see ei sobiks suuremate projektide jaoks, sest sellisel juhul töötavad mitmed agiilsed tiimid koordineeritult sama toote või teenusega.

Samuti ei ole õige väide “Meil on 500 inimesega ettevõtte, agiilsus pole meie jaoks.” Agiilsed organisatsioonid on meie tulevik, aga agiilsust ei saa rakendada korraga tervele suurettevõttele, see on võimatu. Seda tehakse sammhaaval väiksemate projektide kaupa kuni kogu ärikultuur ja protsessid lähtuvad agiilsest mõtteviisist. See teekond on pikaajaline, aga tulemused on äriliselt väga väärtuslikud.

On olemas konkreetsed agiilsed metoodikad, mille abil agiilsust skaleeritakse, nt Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Scrum of Scrum (SoS), jt.

Agiilsuse printsiip nr 8 ütleb, et: Agiilse tarkvaraarenduse protsessid soodustavad jätkusuutlikku arendust. See tähendab, et projektiga saab samas tempos jätkata määramata aja jooksul. 

Müüt nr 8: Agiilsus on mingi uus ja nišikas asi

Maailma suurimas agiilsuse uuringus “State of Agile Report 2020” on kasutatud üle 40 000 ettevõtte andmeid eri tegevusvaldkondadest. Uuringu põhjal kasutavad 95% ettevõtetest agiilseid meetodeid. Tõsi, samas on vaid 18% ettevõtetel kõik meeskonnad agiilsed.

Seega on agiilsus väga laialt levinud, aga endiselt on ka arenguruumi – seda just agiilse mõtteviisi täielikul mõistmisel.

Müüt nr 9: Agiilsus on ainult IT teema

Tänaseks on agiilsed põhimõtted levinud tarkvaraarendusest palju kaugemale, peamiselt organisatsiooni juhtimise ja toimimise suunda – tõenäoliselt oled kuulnud termineid “agiilne juhtimine” või “agiilne organisatsioon”.
Enam ei tähenda agiilsus ainult tootearendust, see hõlmab kogu ettevõtte arenguprotsessi, sealhulgas juhtkonna, finants-, personali-, turundus-, IT- jt osakondade tööd eesmärgiga, et kõik toimiksid ühtselt ja muutustele kohanduvalt nagu üks suur agiilne organism. Agiilse transformatsiooni protsessi aitavad ettevõtetes läbi viia agile coach-id, kellel on vähemalt 5+ aastane kogemuse erinevate agiilsete metoodikatega.