V tomto článku bych se chtěl detailněji podívat, jak se v kontextu událostí v posledních letech mění a vyvíjejí agilních metodiky – co je už je za zenitem a co je naopak stále aktuální. Nejprve odkážu na článek Jurgena Appela [https://unfix.com/blog/agile-is-undead-a-synthesis](Agile is undead). Článek, který vřele doporučuji si přečíst, popisuje soumrak agilních metodik a agilního hnutí jako celku i důvody, které k tomu vedou.
Pro ty co nemají čas číst celý článek od Jurgena, zde je souhrn od AI🙂
Úpadek Agile: Popularita Agile klesá, konferencí ubývá a agilní role jsou postupně rušeny. Kvůli nadměrným ceremoniím, módním slovům a pochybným certifikacím se agile stal zastaralým.
Klíčové faktory úpadku: K úpadku Agile přispělo několik faktorů, včetně rozšíření certifikací, přebujelých framworků, povrchního učení, agilního dogmatismu, módních výstřelků, pochybných rolí (Scrum Masters, Product Owners), zaměření na rychlost před výsledkem, chaotického řízení, nesouladu se strategií a zásadních problémů s Agilním manifestem.
Změna paradigmatu: Původní agilní hodnoty zastarávají tváří v tvář novým technologiím a měnícím se obchodním požadavkům. Hodnoty Agilního manifestu již neodpovídají dnešním požadavkům byznysu.
Potřeba nových hodnot a principů: byznysové prostředí vyžaduje nové hodnoty a principy, které vyvažují vedení a řízení, upřednostňují zákaznickou zkušenost před produktem, řeší potřeby všech zúčastněných stran a využívají moderní technologie.
Agile jako „nemrtvý“: Termín „Agile“ se rozplývá a stává se ambientním, což znamená, že je stále přítomen a vlivný, ale není takto výslovně označován nebo prodáván. Potřeba agility je větší než kdykoli předtím, ale značka Agile ztratila svou sílu. Organizace potřebují agilitu více než kdy jindy, ale nebudou platit za nic, co se nazývá „Agile“.
Ve svém článku bych chtěl volně navázat a podívat se, co dle naší zkušenosti zůstává “undead” a co by každá organizace, která chce v dnešním světě uspět, měla minimálně zvažovat.
Malé vývojové týmy
Základem moderního vývoje jsou malé týmy. Trendem, který zvýraznil dopad umělé inteligence na vývoj softwaru jako takový, je zmenšování vývojových týmů na velikost 2 až 4 lidí. Tito členové jsou do velké míry zastupitelní, samoorganizují se, pracují s velkou mírou autonomie a odpovědnosti a mají velký kontext byznysu firmy i zákazníka. Společně s produktovým manažerem se účastní Product Discovery. Díky těmto vlastnostem jsou schopni prioritizovat, hledat minimální produkty a dělat dennodenní rozhodnutí o scopu a výrazně tím zefektivnit end-to-end doručování hodnoty pro zákazníka. Alternativně existuje kolektiv lidí a v rámci nej dynamicky vznikají týmy, viz. náš nedávný článek o FaST Agile.
Vlastní metodiky
Kontext každého businessu je dle mého pozorování více specifický, než by se mohlo zdát. Proto vnímám, že správný přístup pro většinu organizací je stavět si vlastní metodiky a procesy vývoje. Samozřejmě na základě pochopení principů konkrétních agilních metodik a přístupů a s přihlédnutím k antipatternům. Parametrů, které ovlivňují to, co je vhodný přístup pro vás, a které musíte zvážit, je spoustu, např.
- Typ businessu, ve kterém se pohybujete a váš zákazník
- Firemní kultura
- Připravenost organizace na změny
- Produkt a jeho struktura
- Struktura a velikost organizace
- Zkušenosti s metodikami
Nejdříve pojmenujte (vzhledem k aktuálnímu stavu světa) to, co vám nyní funguje a co naopak skřípe a udělejte průzkum možných přístupů, klidně s využitím AI. Začněte u základů v Lean Software developmentu, znovu se podívejte na dnes již tradiční přístupy jako Scrum nebo Kanban, doplňte je o moderní metodiky jako ShapeUP nebo FaST. Vhodné je i pochopení škálovacích frameworků a moderního produktového managementu včetně The Lean Startup.
Výsledek může vypadat tak, že týmy budete organizovat pomocí FaST přístupu, budete po kolektivu chtít, aby dělal předprioritizaci pomocí WSJF ze SAFe a omezíte délku vývoje featur pomocí konceptu Appetite ze ShapeUpu. Celé to doplníte retrospektivami ze Scrumu a omezíte počet dynamických týmů limitováním množství práce známým z Kanbanu.
Vyspělý produktový management
Stále platí, že největším typem plýtvání v oblasti vývoje softwaru je funkcionalita, kterou nikdo nepoužívá /neplatí za ni. Někdo ji musel navrhnout, vyvinout, otestovat, nasadit, supportovat, vytvořit dokumentaci a kromě toho vyžaduje údržbu a zvyšuje komplexitu kódu. Ta se poté negativně projevuje na každé další vyvíjené funkcionalitě.
Nejen z tohoto důvodu hraje kvalita produktového managementu a správné určení, co bude organizace vyvíjet a co naopak ne, klíčovou roli. Pro tato rozhodnutí je třeba:
- Mít dobře uchopenou produktovou vizi a strategii
- Pravidelně komunikovat vizi a strategii do celé organizace
- Správně komunikovat se všemi relevantními stakeholdery např. pomocí outcome-based roadmap (roadmapa, která komunikuje, jaká hodnota bude doručena; narozdíl od tradičních roadmap komunikujících output typicky ve formě plánovaných vlastností produktu.
- V úzké spolupráci s vývojovými týmy a případně designéry pochopit reálné potřeby zákazníka a navrhnout vhodné řešení (např. za pomoci nástrojů a technik z Design thinkingu, The Lean Startupu a kontinuální product discovery)
- Efektivně pracovat s daty a využívat je pro rozhodování
O tom jak tyhle věci podpořit a budovat v organizaci jsme nedávno psaly v našem článku o rozvoji produktových roli.
Jeden backlog
Škálovací agile frameworky, jako například LeSS nebo SAFe nás učí, že firma by měla mít stanovené produktové priority v rámci jednoho seznamu (backlogu). Dle komplexity organizace jich v praxi může být víc, ale vždy musí být zachována jejich hierarchie – jinými slovy, že backlog níže v hierarchie je přiblížení obecnějšího backlogu a respektuje jeho priority.
Dodržováním tohoto principu zajistíte, že týmy ve vaší organizaci vždy budou pracovat na tom, co je prioritní. V opačném případě, kdy existuje více nezávislých backlogů, se vystavujete riziku suboptimalizace – některé týmy mohou např. pracovat na tom, v čem jsou nejefektivnější, ale co vůbec není prioritou.
V praxi můžete dojít k tomu, že budete nuceni uspořádat workshop se stakeholdery, jehož cílem bude je (v dobrém slova smyslu) donutit, aby společně shodli na prioritách pro vývoj. Dále vás bude tento přístup tlačit k budování zastupitelných feature týmů. To je sice často vnímáno od týmů s nelibostí (týmy jsou specializované na jednu oblast / produkt / feature a jiné oblasti nechtějí zasahovat – byla by to změna / museli by se něco učit), ale má to velký přínos pro flexibilitu vývoje a tím pádem dopad na zákazníka a byznys organizace.
Více se o škálování agilního vývoje můžete dozvědět na našem zážitkovém workshopu Jak škálovat agile.
Change agents
Změna, změna, změna…je v dnešních organizacích slyšet na každém rohu. Organizace potřebují měnit způsob fungování a procesy, role a odpovědnosti, byznys modely, způsob práce produktového managementu, podpůrné nástroje ve vývoji, zavést nové technologie a mnoho dalších oblastí. Pro podporu řízení změn existuje mnoho přístupů, procesů a best practices, ale vždy je nutné aby změna byla aktivně prosazování a řízena.
Vzhledem k množství změn v organizacích (a jejich naléhavosti dané dobou) a častému přetíženosti lídrů firem je proto vhodné mít tým lidí, kteří jsou pro řízení změn dedikovaní a mají pro tuto práci potřebnou kvalifikaci. Jednou z možností, kterou osobně doporučuji, je změnit původní Scrumem definovanou roli Scrum Masterů právě na change agenty.
Způsob, jak to reálně může fungovat tak, aby byl viditelný byznysový přínos takto postavené role, na v článku o redefinici role Scrum Mastera.
Závěr
Jurgen Appelo ve svém článku píše: “Agile se rozpadá… ale my musíme být agilnější než kdy jindy, aniž bychom tento termín používali.”
K dosažení opravdové agility je třeba přestat uvažovat o agilních metodikách jako uceleném návodu, jak řešit určitý typ problému. Je třeba je rozdrobit na jednotlivé principy, myšlenky a techniky a k těm přistupovat jako když dítě tvoří z Lega – postavit to nejlepší možné vzhledem k cílům a kontextu. Pozor ale na zásadní rozdíl mezi stavěním své metodiky na základě porozumění principům a ohýbáním agilních principů protože “My jsme přece jiní!”.
