Retrospektiva není pro stížnosti

Jednou z nejdůležitějších věcí, které Scrum zavádí do firem je Retrospektiva. Učí nás brát chyby a neúspěchy jako dobrou věc, tedy jako příležitost ke zlepšení. Co když se nám nepovede dobře se zorganizovat a nic na konci Sprintu nedodáme? Nevadí. Na konci Sprintu si dáme Retrospektivu, a zamyslíme se nad tím, co příště uděláme jinak, aby se nám to už nestalo. Co když toho tři Sprinty za sebou naplánujeme moc a pokaždé dodáme jen část? Dáme si Retrospektivu a zamyslíme se nad tím, jak změníme plánování Sprintů tak, aby odhad více odpovídal realitě. Některé věci jsou akutní a bolestivé a dostanou se na retrospektivu hned, jiným to chvíli trvá. Ale když se budou dít pravidelně, dříve či později je někdo bude považovat za tak otravné, že je zmíní. Retrospektiva ale není o tom si postěžovat a odejít, ale příležitost pro zlepšení. Proto každá Retrospektiva věnuje většinu času nikoliv stížnostem, co všechno nefunguje, ale hledání příčin proč se to děje a následně možností, co bychom s tím jako tým mohli udělat příští Sprint. Každá Retrospektiva proto musí končit alespoň jedním konkrétním krokem co tým udělá příští Sprint jinak, aby se daná oblast zlepšila. Nemusí se hned vyřešit, ale každé zlepšení se počítá. Obecně platí, že když máte takových akcí moc, často se tým rozptýlí a neudělá nic. Proto by takových akčních kroků nemělo být příliš. Vyberte si jen to nejdůležitější a s tím pohněte. Jednu dvě, maximálně tři akce. Příští retrospektivu si zase můžete vybrat něco jiného, nebo v tom stejném tématu pokračovat, podle důležitosti.

Kdyby vás retrospektiva zajímala, můžete si pustit mé video. Je starší, ale stále platné 🙂

Sprint Goal – příklad

Jedna z častých otázek je, jak má správně vypadat Sprint Goal. Pojďme se ale nejdřív podívat, co to je. Sprint Goal dává Sprintu smysl. Definuje, čeho chceme dosáhnout. Dává dostatečně silný důvod jeho existence. Proč by měl Product Owner do Sprintu investovat (čas i peníze). Vyplatí se to? Sprint Goal je nedílnou součástí prioritizace Backlogu. Sprint totiž není o dodání jednotlivých položek Backlogu, ale o dosáhnutí cíle Sprintu, tedy Sprint Goalu.

Sprint GoalJak by mohl takový Sprint Goal vypadat? Když o něm slyšíte úplně poprvé, můžete začít třeba Sprint Goalem, který je implementací větší položky Backlogu. Jako je třeba:

Ve Sprint Backlogu potom budou různé položky Backlogu, které tvoří jednotlivé části Dashboardu.

Sprint Goal: “Dashboard“ 

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, seznam nezaplacených faktur.“

Když budete chtít v pochopení Sprint Goalu pokračovat, tak o trochu lepším cílem sprintu je podívat se na to z pohledu business hodnoty a zákazníka a identifikovat tak potřebu, například:

Jednotlivými položkami Backlogu, které pak tým následně vybere z Backlogu budou nejen položky tvořící Dashboard, ale například notifikace, které užitečnosti přehledu o financích můžou přispět i více než samotný dashboard.

Spring Goal: “Zvýšit přehled o financích“

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, notifikace o překročených limitech, notifikace o fakturách po splatnosti“.

Na závěr už zbývá jen přidat příklad, jak by takový Sprint Goal nikdy vypadat neměl. “Dokončit PBI1, PBI2, PBI4 a PBI6 podle definice“. Takový Sprint Goal je příkladem tradičního mindsetu a naprostého nepochopení toho o čem Scrum je. Tedy zaměňuje Sprint Goal za konkrétní specifikaci, a Backlog za ToDo list. Ale ani jedno není Scrum. Scrum je takzvaně ‘purpose driven‘. Tedy řízený nějakým vyšším smyslem, něčím, co přináší hodnotu pro zákazníka. Něčím, do čeho byste byli ochotni investovat svoje peníze, abyste další Sprint zaplatili. A pak další, a další. Něco, čemu věříte natolik, že byste do toho šli.

Na které věci můžete v Agilním prostředí zapomenout

Specifikace

Specifikace v takovém tom klasickém slova smyslu je mrtvá. Agilní prostředí se daleko více zajímá o to co je to minimum, které musíme implementovat abychom dodali maximum business value, než co všechno musíme naimplementovat abychom se do nějaké té business hodnoty trefili. Jak říkal jeden můj známý ScrumMaster, klasické organizace často se zavázanýma očima střílí na kachny. A protože střílí hodně, občas nějakou trefí. Agilní organizace pochopily, že méně je někdy více, a přestali trávit hodiny času specifikací toho co všechno bychom taky mohli udělat. Na místo toho se v rámci Inspect and Adapt principu a časté zpětné vazby snaží pochopit co přináší nejvyšší business hodnotu a na tu se soustředí. Ano, je to změna, a bude to těžké, ale o tom Agile právě je.

Častým nepochopením je že organizace mají pocit, že v rámci UserStory musí psát detailní popis, jak danou potřebu adresovat například formou Akceptačních kritérií. To ale vůbec nepatří do UserStory. Ta by měla pouze definovat potřebu konkrétního uživatele/persony, ‘jak’ji budeme řešit je na dohodě týmu v rámci Sprintu. Ano, pre-rekvizitou je pochopení toho co děláme celým týmem, tedy dobrý Product Owner a Backlog Refinement. Jinak vám ale Scrum ani Agile fungovat nebude. Agile i Scrum je customer centric, business driven. Takže zapomeňte na specifikaci, zkuste se zcítit do zákazníků a pochopte jejich potřeby. Jen tak dosáhnete lepších výsledků.

Projekty

Další věcí, která se dříve či později octne na smetišti dějin, jsou projekty. Stejně jako role project managera. Ale o tom třeba zase příště. Projekt je totiž jen kontejner, v jehož rámci řídíme a zpracováváme práci v klasickém světě. V agilním světě nám stejnou službu dělá Product Backlog, jeho položky a krátké Sprinty/iterace se zpětnou vazbou. Product Backlog je navíc daleko lépe optimalizovaný na vysokou adaptivnost systému, reakce na změny a obecně práci v komplexním prostředí. A tak důležitost světa produktů postupně uvadá. Že jste projektovými managery? Určitě se pro vás najde uplatnění. Project manageři se nejčastěji stávají stakeholdery, kteří pomáhají týmům pochopit kontext zákazníků, častá bývá i změna na Product Ownera, výjimečně ScrumMastera. Většinou platí, že když jste byli potřeba v předchozí neagilní struktuře, budete potřeba i v té nové. Jen vaše role a práce se změní. Ale to platí nejen pro projektové managery, ale i developery, testery, analytiky, a managery. V agilním světě je všechno jinak a jednoduchý mapping neexistuje. Agile je změna mindsetu, a ta začíná ve vaší hlavě. 🙂

Jak řešit chyby ve Scrumu?

Jedním z častých dotazů, které dostávám, je jak řešit ve Scrumu chyby. Je lepší mít separátní tým na chyby a separátní tým na nový development, nebo cross-functional týmy co pracují na tom, co je zrovna potřeba, tedy chybách i nových funkcionalitách. Odpověď je snadná. Scrum optimalizuje business value. Definuje proto týmy jako cross-functional, které dokáží udělat jakoukoli změnu produktu, co přináší business value. Tedy chceme tým (týmy) co pracují na tom, co je zrovna v produktu potřeba. Ať už je to chyba, nebo nová feature.

První, co je třeba si uvědomit je, že chyba je zase jen změna funkcionality, takže není sebemenší důvod, proč by chyby nemohly jít do Backlogu jako jakékoli jiné věci, které chcete ve vašem produktu změnit. Jsou to prostě obyčejné položky Backlogu, které by měl Product Owner prioritizovat podle business value. Když dám příklad, představte si, že máte hru, kde si hráči můžou nastavovat vlastní avatary. A jedním z možných nastavení je i barva vlasů. A co čert nechtěl, pokaždé když se odhlásíte, váš avatar barvu vlasů ztratí a je zase blond. Otrava, že? Jasná chyba, řekli byste. Takže ji musíme dát do Backlogu a opravit. Dokonce na to klidně můžete použít formát User Story a napsat:

Jako hráč,

chci, aby si můj avatar pamatoval barvu vlasů,

abych ji nemusel nastavovat pokaždé znova.

Když to uděláte, stane se zajímavá věc. Z něčeho co se musí opravit, se stane něco, co má business value (abych ji nemusel nastavovat pokaždé znova) a lze prioritizovat relativně vzhledem k ostatním položkám Product Backlogu. V tomto konkrétním případě nás to donutí zjistit, kolik hráčů tuto funkcionalitu s chybou kdy použilo, ale hlavně kolika z nich vadilo, že se přes noc stali blond. A když zjistíte, že existuje jediný hráč, kterému vadí, že nemá barevné vlasy, tak možná položka do Backlogu bude úplně jiná a bude naopak znamenat odstranění funkcionality jako takové.

Co když ale chyba není takhle nedůležitá, ale je kritická? Stojí vám produkce, uživatelé nemůžou produkt používat? No tak ji opravte. Že vám to narušuje Sprint? Je to výjimečná situace, a výjimky se dějí. Když celý tým onemocní, taky to berete jako výjimku a moc to neřešíte. Je třeba si uvědomit, na co klademe důraz. V tradičním světě waterfallu bylo hlavní chybu co nejrychleji opravit. Tím jsme problém považovali za vyřešený. V Agilním světě ji opravíme, a klidně i hned jestli je tak kritická, že nepočká do dalšího Sprintu. Pak si odpočineme, a zamyslíme se, co uděláme příště pro to, aby se nám to už nestalo. Najdeme rootcause, změníme své procesy, refactorujeme, prostě uděláme cokoli, aby se takovéhle kritické chyby neobjevovaly, a ty, které nám přeci jen utečou, jsme mohli v pohodě považovat za výjimky. Protože výjimečné věci se dějí výjimečně, moc nám nevadí. Dokážeme se z toho otřepat. Stejně jako když celý tým onemocní. Naopak obvyklé věci se dějí obvykle a mohou být pěkně vyčerpávající.

Jak naplánovat Sprint bez odhadů?

Jeden z nejčastějších nešvarů Scrum implementací je odhadování tásků v hodinách a jejich následné poměřování vůči kapacitě týmu. Je to krásná myšlenka, ale v praxi je to nesmysl, který trvá zbytečně dlouho a nic nepřináší. Snad jen to, že můžete nakreslit další zbytečnost – Sprint Burndown.

Myšlenka vychází z nepochopení Scrumu. Je to pozůstatek tradičního myšlení Organizace 1.0 kde jsme věřili, že lidi alias zdroje jsou stejně jen líná banda individuí, kteří když je nebudeme hlídat, tak nic neudělají. Scrum dává práci mnohdy ztracený smysl a tak generuje daleko motivovanější lidi, kteří se sami zlepšují a vymýšlejí jak dělat věci lépe. A kteří toho udělají víc i bez mikromanagementu a detailního vykazování.

Když tedy přestaneme odhadovat kvůli kontrole lidí v týmu, zbývá se podívat, jestli mohou být takhle detailní odhady přínosné týmu samotnému. Podívejme se nejprve na reálnou přesnost takových odhadů. V podstatě, každý odhad je jen jakási předpověď. Slovní spojení ‘přesný odhad‘ je oxymoron. Nemůže nastat. Proto také ve Scrumu neodhadujeme, kdy bude jedna konkrétní věc hotová, ale kolik Product Backlog Items se nám vejde do Sprintu. Nečekané vlivy, které se týmu za Sprint stanou, se tím zprůměrují. Každá individuální story může být výrazně jiná, než jsme čekali, ale v globálu to vyjde. Jedna bude náročnější, jiná snazší, někde se zasekneme, jinde to půjde lépe, než jsme čekali a obavy se nenaplní. Jediné, co je pro plánování Sprintu potřeba, je dobré porozumění Backlogu a jednotlivým Stories. Nikdy bychom neměli do Sprintu plánovat věci, kterým nerozumíme – ale v takovém případě ani pokus o odhady tásků nepomůže.

Praktika, která týmům pomůže porozumět položkám Backlogu a na základě toho je naplánovat do Sprintu je rozpadnout Stories na tásky/aktivity, o kterých věří, že je dokáží dokončit za maximálně den (tedy od Standupu do Standupu). Některé takové tásky budou trvat třeba i tři, čtyři dny, jiné tým dokončí za pár hodin. Není důležité zkoumat tyto výjimky, ty se stanou, ať budete dělat, co budete dělat. A jestli to nejsou výjimky a všechny tásky se ukázaly být příliš malé nebo příliš velké, příští Sprint to napravte tak, aby byly v průměru dokončitelné za den. Je to zdánlivě to samé, také odhadujeme, ale je ohromný rozdíl, jestli na takovou tásku napíšete 8h a nebo se jen každý Standup z odstupu podíváte na vaší Scrum tabuli a zhodnotíte celková posun týmu. Není třeba nic počítat. Scrum je empirický proces, koriguje se sám. Někde začněte a uvidíte. Obecně je nejlepším odhadem včerejší počasí. Stačí naplánovat tolik položek Backlogu, kolik jste dokončili minule. Co se tásků týče, když vám rozpadlé aktivity vyjdou na tak cca na polovinu dní, bude to tak akorát. Obvykle se totiž některé tásky v průběhu rozpadnou na menší kousky a jiné vzniknou. To je zcela normální, neboť řešení vniká teprve v průběhu Sprintu. Zkuste to a uvidíte, jak to půjde. Příští Sprint můžete cokoli změnit tak, abyste našli správný balanc a rytmus.

Sprint Review

Sprint Review je jednoduchý meeting, který ale většina firem nepochopila. Jak se jako Agilní Coach chodím dívat na různé Scrum týmy, nejčastější chybou je, že Sprint Review považují za Sprint nebo Release status. A tak se tenhle zajímavý meeting stává pro spoustu firem noční můrou. Rozhoduje se zde, jestli byl tým úspěšný, kolik slíbil a kolik dodal. Ale to je zcela mimo definici toho, co by se tu mělo dít.

Jestli jste si oddychli, že takhle to u vás není, mám pro vás druhou nejčastější chybu, a to že na Sprint Review prezentuje tým Product Ownerovi co dokončil. Je to asi o chlup lepší, ale pořád úplně vedle. Product Owner je součást Scrum týmu a tedy dokončenou funkcionalitu akceptuje hned jak je hotová, tedy v průběhu Sprintu. Tedy na review už ji dávno viděl a dal na ni zpětnou vazbu.

Další chybou v pořadí je, že neprezentuje tým, ale Product Owner. Tým je přeci banda introvertů co nerozumí businessu, tak jak by mohli předstoupit před zákazníka, že? No alespoň oproti předchozím variantám něco ukazujete zákazníkovi a dostáváte zpětnou vazbu. O tu jde totiž na Sprint Review především.

Ideálním stavem je, že tým prezentuje zákazníkovi, co dokončil. A na oplátku získá zpětnou vazbu od zákazníka. Není to žádná technická prezentace jak je to naimplementované, ani přehlídka jednotlivých User Stories, ale souhrnná prezentace toho, jak jsme doručili za daný Sprint hodnotu definovanou cílem Sprintu.  Jak již jsem naznačila, prezentuje tým. Kdo konkrétně? No to je snadné, kdokoli. Z výborně fungujících týmů je schopný hodnotu Sprintu prezentovat kdokoli. Jak to vypadá v praxi? Přijdete na Sprint Review, tým vylosuje jednoho člena a ten prezentuje. Že to není možné? Když tým spolupracuje v rámci Sprintu vždy na jedné UserStory (viz praktika “One UserStory at a time“), není to problém. Je důležité si uvědomit, že neprezentujeme detailní řešení, ale Sprint Goal, tedy hodnotu dodanou v daném Sprintu.

Proč je Backlog Refinement aktivita a ne meeting

Backlog Grooming se stal postupně velmi častou praktikou jak udržovat Product Backlog a rozumět jednotlivým User Stories. Týmy takový Backlog Grooming pořádají pravidelně jednou až dvakrát za Sprint, a trvá něco kolem 1-2 hodin. Když se ale podíváte na Scrum Guide, nikde se o takovém meetingu nic nedočtete. Jak tedy zajistit, že máme kvalitní Backlog a rozumíme mu bez Backlog Groomingu? Scrum Guide definuje pro tyto účely průběžně probíhající Backlog Refinement. Proč to není meeting? Protože všechny meetingy, kde musí být celý tým, jsou drahé. A když jsou dlouhé, obvykle nejsou ani moc efektivní.

Celý Backlog Refinement tedy můžete dělat jen jako sérii workshopů, kterých se účastní ti, pro které to zrovna dává smysl. Někdy je to jen malá skupinka složená z členů týmu, někdy se přidá Product Owner, jindy stakeholdeři. Vyjímečně se zúčastní všichni. Tyto workshopy děláme tak často jak je potřeba, abychom v každou chvíli měli připravený kvalitní Backlog na cca 2-3 Sprinty dopředu. Když tato aktivita probíhá dobře, tak všichni rozumí vizi produktu, vědí, jak se definuje business hodnota, mají přehled o velkých funkčnostech, které se chystají v budoucnu, a mají detailní porozumění toho, na čem budou pracovat v následujících Sprintech, jak co se týče business hodnoty tak představě o řešení problému. Jak poznáte, že je Backlog Refinement dobrý? Sprint Planning je potom jen rychlým checkem že víte, co v rámci Sprintu dokončíte, akceptace dokončených funkcionalit v rámci Sprintu Product Ownerem je formalitou, protože nevznikají nedorozumění a zákazníci jsou produktem, který na Sprint Review prezentujete spokojeni, a dávají zpětnou vazbu, která produkt zlepšuje, nikoli shazuje ze stolu.

Jako včerejší počasí

Na jednoduchý problém existuje jednoduchá pomoc. Tým neustále overcommituje. Tedy slíbí sedm User Stories a dodá čtyři. Příští Sprint slíbí osm a dodá jen tři, další se zaváže dodat sedm a dodá pět. A tak to pokračuje Sprint po Sprintu. Když se zeptáte co s tím tým dělal, obvykle odpoví, že to řešili na retrospektivě a že příště už se to povede.

Jak dobře odhadovat, kolik se nám toho vejde do Sprintu? Tak předně věřte tomu, že obvyklé věci se dějí obvykle a výjimečné jen výjimečně. Tedy, že když několik sprintů za sebou dodáváte méně, než plánujete, tak se tak asi bude dít i v budoucnu. Důvody pro to se mohou různit, ale na úrovni týmu a Sprintu to vždycky vyjde.

Existuje rychlá medicína. Příští Sprint si do Sprint Backlog vezměte přesně tolik, kolik jste minule stihli dokončit. Takzvaně “včerejší počasí“. Ostatně říká se, že kdyby předpověď počasí byla dělaná podle včerejšího dne, že bude přesnější, než když se ji snažíme odhadovat. Nevím, jak s počasím, ale tady to funguje a výsledek se dostaví okamžitě. A teď, když už to umíme, tak se můžeme pozvolna zaměřit na to, jak rychlost týmu zvednout. Je to první úspěch a na tom se dá stavět. A můžete začít tím, že ho společně zajdete oslavit.

Backlog Grooming

Také se ptáte k čemu je Backlog Grooming? Cílem tohoto meetingu je zajistit, aby tým rozuměl celému Backlogu. Proto na úplně prvním Groomingu začínáme tím, že Product Owner v 15ti minutách představí vizi produktu /releasu a všechny Epicy. V druhých 15ti minutách představí střední vrstvu Backlogu, tzv. Super User Stories – tedy předpřipravené funkcionality, které přijdou na řadu za několik Sprintů. Nejsou ještě dostatečně malé ani úplně konkrétní, ale už mají obvykle formu User Story. Takových Super User Stories by mělo být připraveno na 5-10 sprintů. A zbývající čas Backlog Groomingu věnuje Product Owner konkrétním User Stories na vrcholu Backlogu. Ty už musí být INVEST, tedy jasné, konkrétní a dostatečně malé, aby se daly kdykoliv naplánovat a v rámci Sprintu dokončit. Takových User Stories potřebujeme v Backlogu na cca 2-3 Sprinty.
Backlog Grooming

Každý další Grooming už většinou Product Owner spolu s týmem prochází User Story podle priorit tak, aby měli pokaždé připraveno dostatek práce pro další Sprinty. Grooming se obvykle dělá v půlce Sprintu, aby v případě potřeby bylo dost času si danou funkcionalitu promyslet a to jak ze strany Product Ownera, tak týmu. Obvyklou součástí Backlog Groomingu je i ohodnocení User Stories Story Pointy, aby se Product Owner mohl rozhodnout na základě komplexity o prioritě, tým si ověřil, že to všichni chápou stejně a společně ev. dodefinovali akceptační kritéria, či User Story rozdělili.
Jak dlouho takový Backlog Grooming trvá? To záleží na přípravě, kterou tým jednotlivým User Stories věnuje, na připravenosti a kvalitě jednotlivých User Stories, a schopnosti efektivně komunikovat. První Groomingy obecně trvají dlouho, další mohou běžně trvat kolem 30-60minut.

Backlog Grooming

Chcete-li Grooming krátký, a navíc nemáte rádi meetingy, můžete zvážit jako tým na fotce ho dělat u tabule ve stoje. Určitě se omezí dlouhé nikam nevedoucí diskuse a posílí příprava týmu. Zároveň fyzická reprezentace umožňuje se zapojit do dodefinování User Stories každému, a nečekáte na Product Ownera až to dopíše do systému. Takže rozhodně doporučuju. Určitě to zkuste.

Jaké to je když vám vyjde kniha

První pocit? Překvapení. Přijde tlustý balíček se třemi autorskými výtisky. Jen tak, z ničeho nic. Jeeeee už je to tady! Ta je pěkná 🙂 a pak se vám začne honit hlavou, jak to celé bylo. Já v podstatě knihu psala v nejrůznějších koutech světa. Doma prostě nebyl čas se zastavit a přemýšlet. Proto tak ráda cestuju. Je to osvěžující. Kde to celé začalo? Já myslím, že v Indii. Seděli jsme u bazénu při konferenci a říkali si, že by bylo fajn napsat knihu. A vymysleli osnovu. A pak osnova pak dlouho ležela u ledu… A pak jsme začali pomalu psát. Kousek po kousku. Ale jak říkám doma mi to moc nešlo. Psát knihu je děsně práce. Trvá to nekonečně dlouho. Pořád to není hotové.

A tak jsem se rozhodla s tím pohnout a první rozumně velký kus jsem napsala v Indonésii. Bangka Island. Každý den po odpoledním ponoru, až do večeře. Jsou tam úžasné soft korály. Jedny z nejhezčích na světě. To je stejně můj sen, pracovat někde pod palmičkou. Pak bylo po dovolené. Pak další části vznikaly v letadlech a při čekání na letištích do Kalifornie – v San Fransicsu je úžasně, taky je tam moře. Pak cestou do Kieva, Rigy, Barcelony, Talinu, Kodaně, Krakova, Moskvy, New Yorku, v Las Vegas – nic jsem v casinech nevyhrála. Škoda, pár miliónů by se mi ke splnění snu sedět pod palmičku hodilo.

Další velký kus jsem napsala na Filipínách. Zase potápění. Odpolední dvě hodinky po ponorech na Moalboalu, pak v thajské restauraci na pláži v Boholu a finální části v Coronu, kde mají Japonské vraky plné podmořského života. Nádhera. Ale pořád to tak nějak nebylo hotové. Už mi to začínalo vadit, nemám ráda dlouho nekonečnou práci… a tak jsem poslední kusy dopsala ve Vietnamu v Saigonu nebo Ho Chi Minh City chcete-li. Hodina taxíkem do práce, hodina zpět do hotelu. Tam jsem ve finále četla i celou knihu ještě jednou v rámci finálního review. To si teprve uvědomíte, kolik jste toho napsali. To už bylo povzbudivé. Skoro hotovo. A jsem moc ráda, že jsem na knihu nebyla sama. Vždycky je daleko větší zábava s někým spolupracovat.

A pak nastal ten největší problém, kde sehnat vydavatele. Nakonec to šlo celkem snadno. A tak děkujeme nakladatelství Computer Press za vydání naší knihy “Agilní metody řízení projektů“ a doufáme, že se vám bude líbit. Co se dočtete?

„Snažili jsme se čtivou formou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na Agilní metody mohou potkat. Kniha nepopisuje jen teorii, co to Agilní metody jsou, jak funguje Scrum Proces a Kanban, a jak by jednotlivé artefakty těchto procesů měly správně vypadat, ale primárně se snaží vysvětlit filozofii Agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení co dělat a čeho se naopak vyvarovat.

Kniha se zabývá Agilními metodikami vývoje software v různých typech společností, od malých firem až po nadnárodní korporace. V první části knihy jsou popsány základní stavební prvky Agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Čtenář se dozví všechny potřebné informace k adopci Agilních metodik, kulturní odlišnosti Agilních firem a další základní stavební kameny nutné pro úspěšnou adopci Agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky vyskytují v Agilně řízených firmách. Vedle těchto popisů obsahuje kniha i “kuchařky”, resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy firem.“

Dejte nám prosím vědět, jak se vám kniha líbila, co vás zaujalo, nebo co byste viděli příště raději jinak. Hezké čtení. Naší knihu Agilní metody řízení projektů můžete získat zde.