Kedy zaviesť Agile. Cynefin pomôže s rozhodnutím

Kedy zaviesť Agile? V článku priblížime, ako sa rozhodnúť, v akých situáciách má zmysel zavádzať Agile. Článok poskytne návod s pomocou prístupu Cynefin na otázky, kedy je lepší Scrum, kedy Kanban a kedy pomôžu aj len vybrané agilné praktiky. Zároveň sa aj v akých sitáciách, alebo typoch problémov Agile nie je vhodné.

Agile už je zavedené v mnohých firmách, ba dokonca nielen IT oblosti. Dnes už zvyknem vravieť,  že Agile už ani nie je moderným prístupom. Agilné prístupy sa stali de-facto normou k tvorbe produktov.

Je Agile vhodné pre všetkých?

Táto otázka, na základe našich skúseností z Agile mentoringu, nebola klientmi zvážená pri zavádzaní vo väčšine prípadov kde sme boli pozvaní do už rozbehnutej Agile transformácie.

Agile potom prirodzene v sebe nesie pre mnohých aj pachuť. Násilné zavedenie Agile praktík klientom bez konzultácie aspoň s inými, ktorí sa o to už pokúšali, spôsobuje viac škody ako úžitku.

Ľuďom takáto zmena skomplikovala život, nie zjednodušila a urýchlila. Násilné zavedenie Agile pre všetko a pre všetkých spôsobí zlyhanie a akákoľvek náprava je potom skoro nemožná.

Osobne mi to pripomína socializmus s jeho normalizáciou. Skvelo to vyjadruje hudobná skupina Bez Ladu a Skladu v skladbe ‚Píšte všetci modrým perom‘. Stačí zameniť ‚modré pero‘ za slovo Agile :).

Agilné princípy a praktiky boli vymyslené, aby umožnili prispôsobivosť, adaptáciu. Aby nemuseli všetci byť rovnakí v každej situácii. Aby mohli prispôsobiť prístup.

Na zmysluplnejší, pragmatický. A aj neagilný ak treba.

Zaviesť Agile vo vašom produktovom tíme?

Správnou odpoveďou je zamyslieť sa aké typy problémov rieši tím. Nezavádzať hneď „hotové“ rámce ako napr. Scrum, alebo sa vrhnúť na Kanban, lebo je v ňom ‚menej byrokracie‘.

Je nutné vybrať si praktiku, prístup, proces, podľa situácie firmy a tímu. Jednoducho zvoliť správny nástroj na daný problém.

Skrutka sa tiež dá zaskrutkovať aj nožom, ale nie je to efektívne. A taký je aj výsledok. Skrutka nie je dotiahnutá dostatočne a časom spôsobí problém. Porieši, ale nevyrieši.

Zaviesť Agile, keď vieme, ako na problém?

Problémy typu ‚Vieme, že vieme‘ nepotrebujú Agile prístup. Sú jednoduché.

Príkladom je varenie čaju. Kopírovanie súborov. Zálohovanie. Formulár pre Jednoduchý vstup údajov. Dizajn takého formulára. Štýlovanie. Logovanie. Fakturácia. Rozbehnutie microsite. Napísanie článku. Aktualizácia metrík. Prepojenie na Google Analytics. jednoduchý export z databázy cez SQL jazyk a administračné rozhranie.

Vlastnosti, funkčnosť, tohto typu problému ste už asi programovali, alebo robili, viackrát. Vo väčšine prípadov už aj máte knižnice, vzory, šablóny, ktoré stačí skopírovať. A vie to aj junior. Stačí poznať čo má ako zreplikovať a môže ‚rúbať a rezať‘.

Cynefin kategorizuje tieto problémy ako jednoduché. Zaviesť Agile v jeho celej šírke a hĺbke je zbytočné. Nemá zmysel zaviesť Scrum, dokonca ani Kanban.

Napriek tomu, ak je veľká väčšina vašich požiadaviek tohto typu, agilné prístupy stále môžu pomôcť. Napr. Kanban tabuľa pre lepšie sledovanie stavu, alebo jednoduchý checklist. Alebo denný standup pre koordináciu.

Viem, čo neviem

Máte pocit, ze síce ešte neviete ako presne zrealizujete požiadavku, ale viete, že sa to podarí? Cítite, že máte vedomosti a skúsenosti v tíme? Že sa stačí iba zamyslieť, dohodnúť, skúsiť a spraviť? Možno vopred s premysleným a dohodnutým  postupom?

Jednoducho, je to ‚komplikovaný‚ problém?

Zaviesť Agile pre takéto situácie má veľký zmysel. Predovšetkým ak takýchto typopv problémov je pomerovo veľa.

Tu vám môže pomôcť Scrum s plánovaním, standupom a review. Scrum je založený na spolupráci timu a spoločnom postupe. Neskôr sa takéto typy problémom možno stanu banalitou a v podstate problémom Viem, že viem spomenutým vyššie.

Scrum možno bude neskôr, vďaka vypestovaným návykom, už zbytočne komplikovaným a spomaľujúcim a môžete prejsť na Kanban.

Neviem, čo neviem

‚Neviem čo neviem‘ v dnešnej dobe vôbec nie neobvyklé. Technológie sa menia veľmi rýchlo. Požiadavky klientov tiež. Aj legislatíva. Produkty a biznis sú závislé na množstve faktorov, ktoré ani nemusíte vopred poznať.

Tieto typy problémov sú ‚komplexné‚. Prístup k nim musí byť iný.

Zaviesť Agile aj v týchto prípadoch má zmysel. Musíte však vybrať správne prístupy.

Potrebujete najprv zmenšiť množstvo neznámeho napr. výzkumom, hypotézou, experimentom. Ich výsledkom bude v podstate naplnený backlog produktu, ktorý ďalej môžete riešiť v rámci Scrum ako samostatné epiky a user stories.

Rozdeliť komplexné problémy na dve časti. Analýzu a neskôr implementáciu user stories, ktoré ste identifikovali v analýze.

Mne sa najviac páčia experimenty. Analýza je fajn , noe experiment hoci len vo forme hacku, alebo prototypu poskytnú presnejšie a hodnotnejšie odpovede.

Do oblasti experimentov patrí aj nastavenie Business modelu, Lean Startup prístup, customer experience,  Design Thinking, performance pri weboch,  SEO, SEM, hľadanie správneho dizajnu webu.

Aj tu je vhodný Scrum, možno ešte vhodnejší Kanban. Ak sa rozhodnete pre Scrum, stačí mať podúlohu (task) s názvom Analýza, a ďalšiu Review výsledkov.

Aplikujte iteratívny prístup. Princíp Set-Based prístup je jeden z princípov Scaled Agile Framework, ktorý sa v praxi veľmi oplatí. Vytvárajte paralelne viacero verzií. Pýtajte si spätnú väzbu. Merajte. Takto rýchlejšie dosiahnete výsledok. A podstatne viac poučení.

Point-Based prístup nájdete aj u seba. Je bežný, no menej efektívny z pohľadu rýchlosti dosiahnutia správneho výsledku. Pri tomto postupe vytvoríte jeden výsledok, v ďalšom sprinte ho zlepšíte, v ďalšom upravíte. Zdá sa dokonca ekonomickejší, ale keď si uvedomíte koľko času ste strávili na hľadaní správneho výsledku a o koľko ste možno prišli, stratili, ekonomika vyzerá už inak.

Zaviesť Agile, keď neviem, kde mi hlava stojí?

Chaos. Horí, potrebujeme hasiť, padol server, máme bezpečnostný incident.

Tu nie je priestor na plánovanie, na odhadovanie. Je jasné, že treba konať okamžite.

Predstavte si, že by počas kritickej vojnovej situácie si mala čata vojakov sadnúť a radiť sa, čakať na veliteľa, ktorý rozhodne.

Príprava má svoj priestor pred samotnou akciou, ale keď akcia beží, členovia tímu už musia využívať návyky, a nie plánovať.

Na chaos sa pripravujte pred chaosom. Podobne ako členovia Navy Blue Angels sa pripravujú na svoje riskantné lety. Neustále drilujú, dokonca memorujú svoje akcie tak (viď minúta 1:22), aby počas letu už len využívali návyky a inštinkty.

Aj tímy sa môžu pripravovať na krízu vopred. Vedeli ste, že Netflix aktívne zhadzuje svoju produkciu pomocou Chaos Monkey princípu? Zaujalo vás to? Chaos a iné monkeys vysvetľujeme v tréningu Základy DevOps.

Keď sa chaos skončí, potom si možno treba sadnúť, spraviť retrospektívu s root cause analýzou. Predídete podobným problémom a spravíte z nich rutinu ako v prvom bode, alebo aspoň komplikovaný problém ako v druhom bode.

Vo veľkých tímoch je ťažké mať prehľad o zmenách. Komplexný systém má tendenciu sa správať chaoticky. Aj tu platí entropia.

Preto sú tak dôležité retrospektívy aj na celofiremnej úrovni, alebo úrovni business unit. ScrumDesk mentori pomáhajú workshopmi Inspect & Adapt, ktorých sa zúčastnia všetci členovia tímu a manažment, spolu so Scrum Mastrami, sa následne musia zaoberať zlepšeniami systému.

Zvažujete Agile? Použite Cynefin

Popísané prístupy ku kategorizácii problémov výrazne pomáhajú so správnym výberom Agile rámcov a agilných praktík a ich nastaveniu v pravidlách tímu.

Vymyslel ho Dave Snowden a dal mu nazov Cynefin, čítaj kynefin.

Cynefin v praxi

Reálne situácie však nie sú kategorizovateľné iba do jednej kategórie. Realita Agile tímu prináša problémy všetkých typov, súčasne v jednom týždni.

Benefit Agile však je v tom, že si tím vie prispôsobiť pravidlá nie firme, ale tímovej realite, ktorú rieši.

Neobávajte sa mať iné prístupy podľa typu úlohy. Dohodnite si ako k danému typu pristúpiť a nezabudnite informovať o tom aj Product ownera a stakeholderov.

Tak do kynefinovania, Scrum Mastri.