Počas svojho niekoľkoročného pôsobenia v IT som sa stretol s rôznymi podobami agilného a pseudo-agilného vývoja softvéru. Pracoval som v stredne veľkej firme, ktorá sa zrovna nachádzala v období prechodu zo startupovej kultúry do korporátu. Pracoval som v korporáte, kde sa s agilným vývojom zrovna začínali pohrávať. A aktuálne pracujem vo firme, ktorá svojou veľkosťou a kultúrou splňuje definíciu startupu. Počas tohoto obdobia som sa stretol s rôznymi uchopeniami slova agile, z ktorých mnohé sa viac, či menej vzdialili od toho, čo bolo autormi tohoto slova pôvodne zamýšľané. V tomto článku by som preto chcel zhrnúť a vysvetliť bežné nepochopenia a zneužitia slova agile a to, ako sa tomu snažíme u nás v Rogerovi vyhnúť.

Scrum Guide ako Sväté Písmo

Ďalším úskalím, ktoré sa môže vyskytnúť aj vo firmách, ktoré majú už dlhšie zavedený agile, je až prílišné dlenie na pravidlách agilných metód. Ako som už písal u scrumu, zatiaľčo filozofia agile je založená na hodnotách, existujú viaceré agilné metodológie [4], ktoré nám pomáhajú implementovať agile v praxi.

Agilná metodológia je prakticky zoznam pravidiel, ktoré by mal team dodržiavať, aby dosiahol želaného výsledku. Problém je v tom, že žiadna agilná metodológia nie je dokonalá a často nesedí úplne presne na to, čo daný team potrebuje. Preto sa môže stať, že po čase určitá sada pravidiel už teamu nebude vyhovovať. Jednoducho z nej môže “vyrásť”, tak ako dieťa časom prerastie pravidlá nastavené svojimi rodičmi (nutnosť poobedného spánku v škôlke tiež už na základnej škole prestáva dávať zmysel). Agilný kouč by mal vedieť rozoznať, kedy nastáva potreba zavedené procesy upraviť tak, aby zodpovedali aktuálnej dospelosti teamu. Stretol som sa však s tým, že dodržiavanie pravidiel scrumu bolo samo o sebe hodnotou. Vedenie požadovalo, aby sa vo vývojových tímoch dodržiavali do bodky a do písmena pravidlá popísané v Scrum Guide [3]. Výsledkom bola otvorená rebélia v odvážnejších a skryté porušovanie pravidiel v menej odvážnych tímoch. 

Bol to nielen nekonštruktívny prístup k agile, ale aj protiklad voči jeho hodnotám (spomeňme prvý bod agilného manifesta: Ľudia a ľudské interakcie sú dôležitejšie ako procesy a nástroje). Agilný framework je stále len nástroj, ktorý je menej dôležitý ako ľudia a ich potreby v tíme. V Roger Technology sme si prispôsobili agile tak, aby nám čo najviac vyhovoval k našej spokojnosti a efektivite. Preto nepoužívame ani čistý Scrum, ani čistý Kanban ani čistý Extreme Programming, ale z každého sme si vybrali (a postupne vyberáme) to, čo nám dáva zmysel v aktuálnej vyspelosti a spôsobe práce teamu. Nástroje by sme si vždy mali hľadať podľa cieľa, ktorý chceme dosiahnuť. Ako mi raz povedal jeden profesor z mojej univerzity: “Nehľadaj vhodný klinec pre svoje kladivo, ale vhodné kladivo pre klinec, ktorý chceš zatĺcť”.

Agilný kouč ako preučený projekťák

Na záver si dovolím jeden mierne kontroverzný názor. Bežne sa stretávam s tým, že za správnu implementáciu agile sa považuje len taká, kde agilný kouč robí 100% času iba agilný koučing. Preložené do jazyku najčastejšej implementácie agile: taká, kde Scrum Master je samostatná a plne dedikovaná pracovná pozícia venujúca sa výhradne udržovaniu Scrumu. Nutno podotknúť, že v predošlej vete myslím Agilný kouč jednoducho ako generalizáciu role Scrum master rozšírenú o znalosti a flexibilitu aplikácie ostatných agilných metód vo vývojovom tíme.

Nedávno som však čítal knižku, ktorá môj názor celkom zásadne ovplyvnila. Jedná sa o knižku Clean Agile [5], v ktorej jej autor Robert Martin, signatár Agile Manifesta [1],  reflektuje čo sa stalo s Agile za posledných 20 rokov od jeho deklarácie. Hovorí, že agile vznikol ako protest softvérových inžinierov a je určený pre inžinierov a mal by byť riadený inžiniermi. Aj rola Scrum Mastra/agilného kouča je teda rola skúseného inžiniera, pretože problémy, ktoré má tento kouč pomáhať prekonávať sú technické problémy.

Business svet však potreboval túto rolu kategorizovať. Vyvinula sa teda certifikácia pre Scrum Mastra, ktorú mohol bežný projekťák za dva dni absolvovať, čím sa stal z neho agilný kouč. Pôvodný zámer Agile Manifesta bol však agilný kouč, ktorý povstane z role inžiniera, ktorý prijal za svoj agilný mindset a nadchne preň ostatných inžinierov. Táto rola tak nijako nemusí byť naviazaná na jednu osobu a môže v rámci tímu rotovať. Netechnický projekťák s certifikáciou agilného kouča nemá potrebné znalosti na riešenie problémov teamu. Agile sa tak stáva len pozlátkom nad naďalej nevyriešenými technickými problémami tímu.

Keď som začínal ako Scrum Master v mojej prvej práci, nemal som žiadne technické skúsenosti. Moja rola bola čisto formálna. Organizoval som a moderoval som stretnutia, dbal som na dodržiavanie pravidiel Scrumu, ale nerozumel som problémom teamu, pretože boli technické. Aj keď som mal za sebou štúdium informatiky, nemal som žiadnu praktickú skúsenosť s vývojom softvéru, ktorá by mi umožňovala poskytnúť teamu potrebnú oporu pri riešení problémov na retrospektíve, prípadne referenciu pri procesných rozhodnutiach. Bol to nefungujúci systém, a ja som upadol do rutinného vykonávania svojho povolania bez pocitu zmysluplnosti a onedlho som vyhorel. Našťastie moja druhá práca bola čisto technická a dnes môžem čerpať z obidvoch týchto skúsenosti ako softvérový inžinier, ktorý má rolu agilného kouča. Neviem si predstaviť robiť svoju rolu dobre ako preučený projekťák, a myslím si, že moja kombinovaná rola zvyšuje môj vhľad a kvalitu rozhodnutí ako agilný kouč. Napriek tomu, neustále dostávam pracovné ponuky na rolu “čistého” Scrum Mastra, od ktorého sa nevyžaduje žiaden vhľad do technických znalostí tímu, ktorý robí vývoj.

Čo si o tom myslíš ty? Súhlasíš so mnou v tom, že agilný kouč je rola softvérového inžiniera alebo si myslíš, že agilný kouč (či Scrum Master) môže svoju rolu robiť dobre, len ak popri tom nerobí žiadny vývoj? Zanechaj nám svoj názor v komentári!

[1] https://agilemanifesto.org/

[2] https://stateofagile.com/#ufh-i-661275008-15th-state-of-agile-report/7027494

[3] https://scrumguides.org/scrum-guide.html

[4] https://www.xpand-it.com/blog/top-5-agile-methodologies/

[5] Robert C. Martin: Clean Agile: Back to Basics, 2019