Tag: agilni

Agile není další metoda řízení projektů

Agile není o nových praktikách, procesech ani nástrojích. Je to jiný způsob myšlení a přístupu k věcem. Být flexibilní, adaptivní. Pokud postoupíme na další úroveň, je to iterativní customer-centric, value-driven týmový přístup vhodný pro řešení komplexních problémů. Potřebujete mít odvahu dělat věci jinak, být otevřený a transparentní, spolupracovat, ale myslím, že to všechno už víte.

Implementace Agilu na úrovni projektů může být drobným krokem na vaší cestě k Agilu. Dává vám relativně omezený prostor pro experimenty, takže minimalizujete riziko toho, že se váš první pokus nepovede. Ale dříve či později, pokud chcete dosáhnout reálných business cílů, musíte posunout agilitu na úroveň produktů a organizace, kde se projekty stanou zbytečnými. Překvapení? Vraťme se tedy o krok zpět. V tradičním světě je projekt kontejnerem pro řízení celé dodávky a projektový manažer ten kdo projekt řídí. Ve Scrumu ale máme Product Backlog, který obsahuje, co je třeba udělat, a Product Ownera, který se postará o to, aby vše bylo dodáno dle priorit. A místo projektu máme jednoduše položku backlogu. Můžete jí nazvat Epic, ale žádný projekt na to není potřeba, práce z Backlogu se postupně dokončuje, Sprint po Sprintu.

Takže jako malý rychlý experiment je asi ok Agile aplikovat na konkrétní projekt, ale být agilní znamená mnohem víc. Čím více organizací rozumí agilitě, tím méně projektů a projektových manažerů ve firmách uvidíte. Možná se vám to nelíbí, můžete se se mnou hádat či rovnou bojovat s celým Agilem argumentací, že to je od začátku celé špatný nápad, který nikdy nemůže fungovat, anebo můžete naskočit do již jedoucího (agilního) vlaku, zůstat konkurenceschopní a udržet si relevantní práci, protože poptávka po projektových manažerech klesá. Pomalu ale jistě.

Tribe firmu agilní neudělá

Všechny české organizace asi v poslední době napadl virus ‘fake Agile & Scrum’. Jak se virus pozná? Přesvědčil jinak docela rozumně uvažující organizace, že když department přejmenují na tribe, bude všechno lepší. Inspiraci jde asi hledat ve Spotify (která se sama svým “modelem“, co nikdy model nebyl, neřídí), nebo v holandské ING, která terminologii v rámci své transformace použila a znovu zpropagovala. Obě zmiňované case-study mají jedno společné. Obě organizace prošly zásadní transformací hodnot, přístupu, kultury. Ti, co je slepě aplikují však nejdou cestou změny mindsetu, ale přelabelováním existujícího. Nové šaty ale člověka samy o sobě nezmění. A tak tyto organizace docela bolestivě failují. Jedna nejmenovaná korporace, co přešla na ‘Spotify model’ po roce musela v podstatě zahodit všechno co udělala a vrátit se v produktech o rok zpět.

Však ono těm organizacím o žádnou změnu ani nejde. Stejně jako u SAFe se jen snažíme chytře umožnit firmám, aby si odškrtli agile jako ‘done‘, a nemuseli se měnit. SAFe na to jde chytře a generuje tisíce naprosto nesmyslných rolí a názvů jako train, release train engineer a pak jakási ‘kolečka‘, asi od toho vlaku :). Naopak ‘Triby‘ jsou tu pro ty co jsou cool a nějaké vlaky jim přijdou v 21. století trochu nemoderní. Ale vyjde to nastejno. Škoda. Jedna velká americká organizace nedávno začala svou v pořadí třináctou Agilní transformaci. Nojo, fakt. Prý se jim to tentokrát už možná povede. Už pochopili, že Agile není jen o terminologii, ale je to změna myšlení, přístupu, mindsetu. Tak jestli se vás tento virus ‘fake Agile & Scrum’ týká, nesmutněte. Ještě tak 5 pokusů a ono to vyjde. Není to těžké, chce to jen přestat předstírat, že se měnit nemusíte a pohlédnout pravdě do očí :).

Dobrá zpráva je, že v zahraničí už “Spotify model” nefrčí. Když jsem to zmínila na Agile2018 v SanDiegu, všichni se divili proč by to kdo kopíroval. Takže ta dobrá zpráva je, že tato móda přejde, stejně jako móda džínů do zvonu. Občas se vrátí, ale už nikdy to nebude hýbat světem. Takže stačí počkat a možná za pár let budeme opravdu řešit otázky, které jsou strategické a mají smysl. Hodně mě překvapilo kam se konference posunula of roku 2012, kdy jsem tam mluvila naposledy. K lepšímu. Takže když příští rok budete chtít vidět co se opravdu děje v Agilním světě, Agile Alliance Agile 2019 je to správné místo. Jen musíte trochu našetřit do kasičky 🙂

Top 5 bodů co dělá Agilní transformaci úspěšnou

1.    Proč?

Asi úplně nejdůležitější je mít cíl. Proč byste se vůbec měli měnit. Protože jestli vše funguje dobře, firma prospívá a je businesově úspěšná, možná si nechte to, co máte. Ne každý musí být Agilní. Když najdete dostatečně kritický důvod pro změnu, určitě se vám to podaří. Důvody pro Agilní transformaci tedy musejí být strategické z pohledu organizace.

2.    Postoj a pochopení managementu

Druhým střípkem do mozaiky úspěšné Agilní transformace je pochopení managementu. Co tedy management musí pochopit? V první řadě že Agile je změna mindsetu – tedy kultury, přístupu k věcem, myšlení. Není to jen další proces, který bezmyšlenkovitě implementujete a je to. Bude to stát hodně energie na všech vrstvách firmy. Aby se transformace podařila, musíte ve firmě musíte budovat silný Agile Leadership a pomoci managementu se do transformace zapojit, být její součástí a řídit její směr.

3.    Definice Produktu

Dalším důležitým bodem je vědět co děláme. Agilní svět opouští tolik oblíbené projekty a plánuje práci pomocí Product Backlogu. Staví na dobrých Product Ownerech, kteří mají vizi a vědí čeho chceme jako firma dosáhnout.

4.    Experimenty

Dalším bodem, který je pro úspěch Agilní transformace nutný je ochota experimentovat. Určitě si říkáte, že na tom nic není. Ale kolik z vás je ochotno přijmout, že hodně experimentů se nepodaří a jsou tak dobrou příležitostí pro zlepšení? Kolik z vás bere chybu jako příležitost k poučení se? To vše je vlastně Inspect and Adapt princip, který je podstatou celého Scrumu. Experimentujete a hledáte cestu? V produktu i vlastním fungování? Pak jste Agilní. Odmítáte takovou možnost jen připustit a hledáte jednoduché recepty? V Agilní transformaci nic takového nenajdete.

5.    Trpělivost a odvaha

V neposlední řadě je to trpělivost a odvaha. Trpělivost proto, že taková změna se nestane přes noc a pro velkou korporaci je Agile cesta která trvá několik let a vlastně nikdy úplně nekončí. Agile je o neustálém hledání lepší cesty, neustálém zlepšování. Dobrá zpráva je, že výsledky přijdou hned jak se na cestu dáte, tedy už po pár Sprintech. Odvahu proto, že budete dělat věci jinak než dřív, a dost možná i jinak než ostatní kolem vás. A to odvahy vyžaduje docela dost. Budu vám držet palce 🙂

Design Thinking

Nedávno se mě někdo ptal co má společného Agile a Design Thinking, tak se na to pojďme podívat. Takže co to je Design Thinking? Framework pro řešení komplexních problémů. Přišel z oblasti designu a primárně cílil na designové týmy a firmy a návrhy produktů, ale je obecně použitelný nejen na návrh nových hmotných věcí, ale i služeb a obecně všeho, co zákazník požaduje. Vhodný pro rychlé hledání inovativních řešení.

U Design Thinkingu je základem orientace na zákazníka a porozumění jeho potřeb. Nehledáme řešení pro sebe, či jak to vidíme my, ale pro zákazníka. Dalším prvkem je iterativní způsob práce, nejedná se tedy o lineární proces. Definice frameworku se občas nepatrně liší, ale obecně by měla obsahovat v nějaké podobě následující kroky:

  • Empathise – vcítění se do zákazníka a porozumění jeho potřeba. Bez porozumění toho, co zákazník chce, nemá smysl pokračovat.
  • Define – když víme, co zákazník chce, měli bychom si problém, který chceme řešit, definovat. Takže popsání problému.
  • Ideate – hledáme řešení, vlastní „myslící fáze“. Snažíme se najít desítky řešení, je snaha řešení hledat i v iracionální zóně či “out-of-the-box” (např. pohledem dítěte) a snažíme se brainstormovat a najít co nejvíc možností.
  • Prototype – vyberme několik (doporučuje se do tří) nejsilnějších myšlenek z předchozí fáze a udělejte prototyp.
  • Test – otestujte prototyp na zákaznících. Ověřte si výsledek své práce.

Jak již bylo zmíněné, proces je iterativní. Z libovolné fáze se můžete vrátit, pokud se ukáže, že nerozumíte potřebám zákazníka. Nejviditelnější je to po testování, ale pokud se ukáže ve fázi Define, že definujete jiný problém, než jste načetli ve fázi Empathise, vraťte se i zde. Fáze se mohou také prolínat.

Implementace Design Thinkingu ale nemusí skončit jen u návrhu nových produktů, pokud se aplikuje dovnitř organizace, může pomoci nastartovat organizační změnu a změnu firemní kultury. Cílem je kolaborativní forma spolupráce a orientace na zákazníka. Můžeme pak hovořit o design-thinking orientované společnosti. A pár příkladů společností, které Design Thinking používají: Nike, Apple, IBM, GE, Samsung.

Takže zpět k úvodní otázce. Co má společného Agile a Design Thinking? Řekla bych že mindset a filosofii. Design Thinking je totiž Agilní metoda. Takže nepřináší nic převratně nového, o čem bychom v Agilní komunitě nevěděli. To ale neznamená, že by se na některé typy problémů nehodil, ba právě naopak. Zařadila bych ho do kategorie šikovných nástrojů jako je Lean Startup, Impact Mapping a podobně.

 

Agilní a Scrum Transformace

Agilní transformace většinou není vůbec snadná. Agile je jednoduchá filosofie, která do našeho života vrací selský rozum. Scrum jako takový má jen pár pravidel, rolí a artefaktů. Ale to pravé, co dělá Scrum Scrumem, je skryto v pochopení mindsetu, který je jednoduchý když o něm čtete, ale zdaleka není snadný aplikovat. Proto doporučujeme pro start balíček Agilního Coachingu, kdy vás zkušený coach provede tím, co to je opravdový Scrum a ušetří vám spoustu energie a času, kdy se to budete snažit bez zkušenosti pochopit a aplikovat sami.

Technický Scrum

Proto firmy často začínají takzvaným ‘Technickým Scrumem‘. A hned v začátku upozorním, že Technický Scrum není Scrum. Jak ho poznáte? Poměrně snadno. Je to procesní implementace všeho, o čem se ve Scrum Guideu píše, často až dogmatická. Ale když dva dělají totéž, není to vždy totéž. Těmto implementacím totiž chybí mindset. A tak je to pouze zdánlivě správně, tedy můžeme si odškrtnout, že máme v kalendáři naplánované všechny meetingy, které Scrum definuje, requirementy přejmenujeme na Backlog a máme tři role, ale často je vykonávané stejně jako předchozí pozice. Předstíráme změnu, ale v hloubi duše se zuby nehty snažíme dělat vše jako doposud. Řeší se tu individuální zodpovědnost, efektivita, reporting, přesné odhady. Kreslí se burndowny a mikromanaguje se. Většinou to není nijak příjemný stav. Meetingy jsou zbytečnými dlouhotrvajícími statusy a Sprinty jen otravným přerušováním práce, která se stejně musí všechna udělat. Prostě ‘dělají‘ Scrum, protože to tak někdo rozhodl. Není to Scrum, ale v některých organizacích je to nutný první krok ke změně.

Scrum Mindset

Když to nevzdáte, po čase přijdete na to, že pravý Scrum je o spolupráci a self-organizaci a začnou vám fungovat týmy, které se samy zlepšují a hledají lepší cestu, jak dodat hodnotu. Bude to kreativní a inovativní prostředí, kde nebudete jen ‘dělat‘ Scrum ale ‘žít‘ Scrum. Scrum se stane vaší nedílnou součástí, přejde vám do morku kostí a stane se součástí vaší DNA. První krok je obvykle ‘Týmový Scrum‘, kde se vám podaří postavit tým spolupracujících lidí, co mají jeden společný cíl. Je to kousek organizace, který přitahuje pozornost. Je lepší než jiné části, má větší energii. Vystupuje z běžného průměru. Často působí takovou silou, že nabaluje ostatní části. Týmy, které zkouší být taky takové, produkty které udělají ze zákazníka centrální bod a místo optimalizace rychlosti práce jednotlivců na technických úlohách začínáme optimalizovat dodanou business hodnotu. V momentě, kdy se na tento styl práce nabalí kritické množství týmů a produktů, vzniká takzvaný ‘Organizational Scrum‘ a mění se to, jak celá firma funguje, počínaje portfolio managementem, prioritizací, zapojením zákazníka, a konče prací s lidmi.

Abyste uspěli, potřebujete jen dvě věci. Dostatečný důvod se změnit a kuráž. Obojí je těžší, než se zdá, ale z mé zkušenosti výsledek rozhodně stojí za to.

Scrum Transformation

Role testera v agilním týmu

Jedním z nejčastějších problémů, na které týmy při agilní transformaci narazí, je rozdílné vnímání rolí. V tradičním světě analytik dělá dopředu analýzu, vývojář to podle ní nakóduje a tester následně hledá chyby. O tom, že analýzy dopředu nepotřebujeme, neboť můžou vznikat klidně za běhu, se mluví často. O tom, že vývojáři mohou pomoci s testováním taky, ač tato praktika již obvykle není přijímána s takovým nadšením a slýcháme k ní spousty výmluv typu vývojáři to nemůžou testovat protože to neumí. No proto také říkáme, že testerům s testováním mohou pomoct. Ne že je mají nahradit. Hned druhá výmluva v pořadí je, že berou větší plat než testeři a tak že by se to nevyplatilo. A tak nám tato spolupráce obvykle zpočátku trochu skřípe.

Dříve nebo později tak týmy dojdou do stavu, kdy testeři na začátku Sprintu nemají co dělat a na konci nestíhají. User Stories jsou hotové – tedy nakódované – a přesto je nesmíme uznat jako výsledek Sprintu. Chybí přeci testy. Týmy v takové situaci přichází s různými legračními nápady jako např. že by bylo potřeba testery od týmu oddělit a udělat jim separátní posunutý Sprint. Tedy to, co vývojáři v jednom Sprintu napíšou, testeři v druhem Sprintu otestují a je to. Ale to jsme pořád mentálně ve waterfallu. Nikam blíže k agilnímu Scrum týmu jsme se v pochopení ani implementaci neposunuli. Bez ohledu na to, jestli máme tabuli a děláme standupy.

Jak by tedy taková spolupráce měla vypadat? Analytik, vývojář a tester si vezmou User Story, a začnou si o ní povídat. Analytik vymýšlí, jak by se daná funkcionalita měla chovat, vývojář to hned implementuje a tester upozorňuje, na co vše si musí dát pozor. Co uděláte když nepřijdou data? Co když nebudou validní? Nezapomeňte, že v akceptačních kriteriích je i to či ono. A v neposlední řadě připomíná business value (proč) definovanou v poslední části formule User Story, abychom v plném zapojení do implementace funkcionality nezapomněli, proč to vlastně celé děláme a v návrhu to zohlednili. Tedy v podstatě místo aby chyby chytal na konci (kdy už je pozdě), chceme aby chybám předcházel. Chceme, aby chyby vůbec nevznikaly a vývojář se tedy nemusel k již ‘hotovému’ kódu vracet. Spolu s tím, že testera zapojíme do návrhu řešení funkcionalit, chceme, aby vývojářům pomáhal již v průběhu a testoval jednotlivé části. V některých případech pak klidně pracují v páru, jinde jde jen o úzkou spolupráci. Honí-li se vám hlavou, že to nebude efektivní, protože tester to musí testovat pořád dokola, není tomu tak. Opravy chyb se také testují dokola a k tomu tam máme ještě multitasking vývojářů a jejich čas strávený opravou již hotových funkčností. A říkáte-li si, že to vaši testeři nezvládnou, protože co mají testovat pochopí až z hotové funkcionality, zkuste se podívat na to, jak dobře definované User Story máte. Jestli dobře, včetně akceptačních kriterií, je to snadné. Když ne, není to chyba testerů, ale pravděpodobně tomu nerozumí ani ostatní členové týmu.

Takže summary na závěr. Úkolem testera není chyby hledat, ale předcházet jim. Dobrý tester v agilním týmu dosáhne toho, že ve finálním testování User Story se žádné chyby nenajdou. A tím jen tak mimochodem ušetří firmě spousty času potažmo peněz. Dobrý tester rozumí zákazníkovi a funkcionalitě a pomáhá s návrhem řešení. Umí se na User Story podívat očima uživatele. Je to plnoprávný člen týmu, který je pro jeho úspěch klíčový. A otázka na závěr… Opravdu si myslíte, že takový člen týmu má mít menší plat jen kvůli názvu jeho pozice?

Agilní praktiky XP – Kolektivní vlastnictví kódu

Chcete-li mít tým potažmo SW firmu opravdu efektivní, musíte se řídit pravidlem, že nikdo nevlastní kód ani jeho část. Narážíte-li na námitky vývojářů že to nejde, neboť jen oni opravdu rozumí dané části aplikace a ostatní by jim to jen zkazili, není to nikterak neobvyklé. Stačí věřit tomu, že to jde a mít schopnost zavést týmové metody spolupráce. Třeba Scrum proces nebo agilní metody řízení softwaru 🙂

Agilní praktiky XP – Kolektivní vlastnictví kódu

Abyste mi věřili, že to je možné i ve velmi složitých prostředích kritických na jakoukoli chybu, přikládám následující case study.

Case Study – “NENAHRADITELNÝ JAMES”

Prostředí
Mezinárodní firma operující v life critical oblasti, přes 50% světového trhu v daném sektoru. Vývojová centra v několika zemích.

Projekt
Migrace všech aplikací na novou platformu pro divizi A. Přes 60 aplikací, čtyři odlišné architektury. Několik sdílených knihoven a klíčových oblastí.
Současně s migrací probíhal vývoj nových funkcionalit v rámci původních aplikací na originální platformě.

Původní stav
Každá sdílená oblast měla jednoho vlastníka (skupinu vlastníků), který oblasti skvěle rozuměl, a nikdo jiný nebyl oprávněn oblast měnit.

Nejvíce kritická situace nastala v klíčové knihovně využívané všemi 60 aplikacemi. Tu měl na starosti James, který ji před mnoha lety navrhl, vymyslel, naimplementoval a celou dobu dělal všechny potřebné změny pro jednotlivé aplikační týmy.

Vzhledem k jeho unikátním znalostem a komplexitě problému bylo řešení v lokálním měřítku optimální, a jeho kapacita stačila požadavkům okolí.

Koncový stav
Po startu migrace, začal být velmi rychle James zahlcený požadavky na změnu knihovny, která byla sdílená přes nové i staré aplikace a v rámci migrace se musela výrazně měnit. Nepomohlo ani to, že některé týmy navrhovaly přímo konkrétní implementaci řešení, kterou stačilo zrevidovat a použít. Čekací doba na změnu kritickou pro migrační projekty byla několik měsíců, což ohrožovalo projekt jako celek.

Řešením byla změna přístupu k této sdílené knihovně a odstranění unikátního postavení Jamese, který už nadále nemohl knihovnu vlastnit a být jejím výhradním přispěvovatelem. Z knihovny se stal sdílený kód, ke kterému měly přístup všechny týmy. Nebyly zpočátku sice tak efektivní jako James, ale průchodnost systému jako celku se odblokovala. Změny samozřejmě probíhaly za Jamesova dohledu a podléhaly revizi Jamese i týmu architektů, aby se předešlo problémům s kvalitou.

Podobné oblasti jsou ve všech větších firmách s komplexnějším prostředím a udělat z nich sdílený kód obvykle pomůže systému jako celku.