Jak měřit úspěch agilní transformace

Tradiční organizace často hodnotí úspěch na základě výstupů, jako je počet dokončených úkolů a funkcionalit. V Agilním světě se naopak klade důraz na dodanou business hodnotu, kterou přinášíme zákazníkům a organizaci. Používají se na to metriky jako je Customer Satisfaction (CSAT), tedy jak jsou zákazníci spokojeni s výsledky vaší práce, Net Promoter Score (NPS), tedy jaká je pravděpodobnost že váš produkt nebo službu budou zákazníci doporučovat, Time to Market, tedy jak rychle trvá nasadit požadavek, a v samozřejmě i klasické business metriky jako jsou vyšší příjmy, snížení nákladů a získání nových uživatelů.

Jedním z klíčových ukazatelů úspěšného agilního týmu je jeho schopnost efektivně doručovat práci. Je tedy dobré se podívat na fungování týmů ze systémového pohledu a vizualizovat překážky a optimalizovat jejich fungování. Agile a Lean jsou si velice blízko, a tak běžné Lean metriky se často hodí i v agilním světě. Například Cycle Time, tedy doba od zahájení práce na úkolu po jeho dokončení, Lead Time, tedy celková doba od vzniku požadavku po jeho doručení, Throughput, tedy počet dokončených úkolů za určitý časový úsek, nebo Flow Efficiency, tedy procento uvádějící poměr času práce vs. čekání. Na různých Kanban boardech pak práci vizualizujeme a hledáme, jak zlepšit naše fungování.

Dalším zajímavým ukazatelem je spokojenost a motivovace týmu. Týmy, které cítí podporu a smysluplnost své práce jsou produktivnější a odolnější vůči stresu. Měřit můžete například Team Satisfaction, tedy spokojenost týmu, Employee Net Promoter Score (eNPS), tedy jaká je pravděpodobnost, že členové týmu doporučí práci v této organizaci, Psychological Safety Score, tedy jak bezpečné je prostředí v organizaci a nakolik jsou členové týmu ochotni sdílet své názory a nápady.

Agilní týmy by se měly starat také o udržitelnost a kvalitu produktu. V tomto kontextu se pak často měří metriky jako je Defect Rate, tedy počet chyb reportovaných po dokončení, Code Coverage, tedy procento kódu pokrytého testy, Technical Debt, tedy hodnota technického dluhu a Release Frequency tedy jak často je produkt nasazován do produkce. Pravidelné code reviews, automatické testy, continuous integration, a refactoring v průběhu Sprintů by měly být v dnešním době už standardem.

Je dobré si ve firmě nastavit vyvážený mix toho co měříte, kombinovat metriky z různých oblastí a sledovat je v kontextu, aby se vám nestalo, že přílišný fokus na jednu konkrétní metriku zabije všechno ostatní. Ale hlavně, měřte jen to, na jehož základě jste ochotni něco změnit. Metriky, které vám nepomáhají se zlepšit jenom zbytečně berou čas.

Organizational Topologies

Jeden ze zajímavých je konceptů, který mě poslední době zaujal je Org Topologies. Je to způsob, jak se dívat na strukturu organizace a její schopnost doručovat hodnotu v komplexním prostředí. Není to další framework ani žádná pevně daná pravidla nebo procesy. Jde spíše o takový mentální model, který pomáhá identifikovat, jak struktura organizace ovlivňuje její schopnost inovovat, adaptovat se a doručovat hodnotu, a jak propojit strategii, komunikaci a synchronizaci mezi týmy.

Scaling frameworky často přicházejí s definovanými patterny, strukturami a procesy. To není samo o sobě špatně, ale dost často to vede k situaci, kdy firmy slepě implementují framework, aniž by řešily skutečné problémy, které mají. Základem Org Topologies konceptu je porozumění kontextu vaší organizace. Org Topologies nepředepisují jednotný recept, ale nabízejí principy, jak odhalit, co ve vaší situaci funguje nejlépe, kladou důraz na optimalizaci business hodnoty a adaptabilitu před rigidní strukturou. Je to jako když máte kompas namísto mapy. Kompas vám řekne, kde je sever, ale zbytek cesty musíte najít sami.

A jak to použít v praxi?

  1. **Začněte s popsáním business hodnoty**: Podívejte se na to, kudy proudí hodnota ve vaší organizaci. Kde jsou bottlenecky? Jak spolu komunikují jednotlivé týmy?
  2. **Zmapujte vaši topologii**: Jaké vzorce a spolupráci mezi týmy vidíte? Kde to drhne? Kde jsou dependence?
  3. **Experimentujte**: Zkuste malé změny, sledujte jejich dopad a iterujte.
  4. **Zapojte lidi**: To nejlepší na Org Topologies je, že zapojují lidi napříč organizací, protože komunikace a vztahy jsou klíčové.
  5. **Nezapomínejte na adaptaci**: Vaše topologie se bude muset měnit s tím, jak roste organizace nebo se mění trh. Dívejte se na to jako na nikdy nekončící cestu.

Organizational Topologies jsou skvělým nástrojem, který vám pomůže pochopit, proč vaše organizace funguje tak, jak funguje. Nejde o kopírování nějakého frameworku, ale o hledání těch správných odpovědí pro vaše specifické podmínky a kontext. Je čas skončit s nefunkčním „Dark Scrumem“ a „fake agilem“ a je čas začít měnit fungování organizace. Organization Topologies přináší dobrý koncept, jak takovou změna nastartovat.

Řešení konfliktů v agilních týmech

Konflikty nemusí být vždycky špatné. Konflikt je nevyhnutelnou součástí týmové dynamiky. Ale zatímco některé konflikty jsou zdravé a užitečné pro otevření různých perspektiv, jiné budou tým brzdit a negativně ovlivňovat energii, motivaci a produktivitu týmu. Prvním krokem k jejich efektivnímu řešení je pochopení jejich povahy. Jde o věcnou neshodu ohledně dat, informací nebo interpretace skutečností, nebo nesouhlas se způsobem jakým tým pracuje, nebo jde o rozdíly v hodnotách, osobních cílech nebo přístupu a nebo v neposlední řadě o konflikty v osobní rovině, založené na vztazích, emocích nebo nedostatku důvěry. Většinou je dobré se podívat na příčinu a udělat si root cause analýzu dané situace. Je konflikt důsledkem povrchového problému jako je špatná komunikace, nebo hlubší systémové příčiny jako jsou nejasné cíle. V některých situacích můžete komplexní situaci příčin a následků vizualizovat nástroji jako jsou causal loop diagrams které slouží k mapování komplexní dynamiky týmu.

Obecně se dá říct, že týmy, které se cítí bezpečně při vyjadřování nesouhlasu nebo sdílení odlišných názorů, mají menší tendenci upadat do destruktivních konfliktů. Proto se vyplatí investovat do takzvané psychologické bezpečnosti a pozitivity v rámci týmu třeba tím, že budete podporovat otevřenou komunikaci a povzbuzovat tým k vyjadřování názorů, i když nejsou úplně ve shodě s ostatními. Naučíte se respektovat rozdílné perspektivy a aktivně oceňovat různé přístupy a nápady a hlavně budete mít dobrého facilitátora který je garantem bezpečného prostředí. Takovou roli v aktuálním světě často zastává ScrumMaster, který by měl být nestranný, a dbát na to, aby dialog zůstal konstruktivní. Konflikty se často eskalují, protože účastníci diskuse necítí zájem ostatních. V takové situaci pomáhají praktiky jako je Active listening, tedy aktivní naslouchání, kde používáme kladení otevřených otázek nebo parafrázování k ověření pochopení (např. “Pokud tě správně chápu, myslíš, že…”).

Konflikty v týmech nejsou selháním, ale přirozenou součástí spolupráce. Klíčem je naučit se je včas rozeznat, najít příčinu, a dostat je facilitací do konstruktivní roviny. A to je právě skill který by správní ScrumMasteři měli mít.

No a jestli máte pocit, že vám v týmu chybí energie, a že lidi chodí do práce jen proto že musí, tak dejte vědět a něco s tím uděláme 🙂

Online prostředí v Agilu

Základním stavebním kamenem agilního prostředí je spolupráce jak v rámci týmu, tak se zákazníky a stakeholdery.  A to není v dnešním často distribuovaném prostředí snadné. Práce na dálku přináší specifické komunikační bariéry, kde nedostatek osobních setkání často vede k nedorozuměním. Příčinou je obvykle to, že se lidé neznají a pak daleko častěji řeší problémy raději sami, než aby se zeptali kolegů na radu. Taková prostředí pak mají nízkou kreativitu a lidé se nerozvíjejí a nerostou. Asynchronní práce přes několik časových pásem a kulturní rozdíly různých prostředí tomu samozřejmě nijak nepomáhají. A tak se stává, že bez ohledu na nástroje, které týmovou spolupráci ve virtuálním světě umožňují, přestáváme spolupracovat a vracíme se k individuální práci jednotlivců. Distribuované prostředí nesmí znamenat ztrátu týmové kultury. Věnujte proto pozornost vztahům mezi lidmi, vytvořte prostor pro neformální interakce, kde se lidé můžou navzájem poznat. Kreativita není lineární proces, nevzniká v izolaci, ale ve spolupráci s ostatními. A bez inovací v dnešním světě dlouho nepřežijete.

Takže jaké nástroje vám můžou v online prostředí pomoct?

Google Drive nabízí poměrně komplexní sadu nástrojů pro spolupráci ať už pro sdílení a psaní dokumentů, spreadsheetů, prezentací, kalendářů a mailů.

Mural nebo Miro nabízí praktickou společnou plochu, kde můžete brainstormovat User Story v rámci  Backlog Refinementů, facilitovat týmovou Retrospektivu, nebo libovolnou diskuzi.

Trello implementuje Kanbanovou tabuli, kde vidíte aktuální workflow a stav práce.

Slack je dnes daleko populárnější než posílání emailů. Je to dobrý komunikační kanál pro sdílení informací v rámci týmu. V různých kanálech pak mohou probíhat diskuse na různá témata. Vše je transparentní pro všechny, ale podle konkrétní potřeby si můžete určitá témata filtrovat.

Zoom, Google Meet nebo Teams jsou dobré nástroje pro komunikaci. V klasickém světě jste lidi posadili do jedné místnosti, aby komunikovali a spolupracovali, ve virtuálním světě vytváříte společný virtuální prostor, kde probíhá v průběhu dne veškerá komunikace a spolupráce v rámci týmu. Nepodceňujte sílu obrazového vjemu. Je daleko těžší spolupracovat s někým koho nevidíte než s někým, kdo je face to face, chcete-li, nebo video to video.

Distribuované týmy by měly minimalizovat manuální procesy. Automatizované testování je snad již dnes běžné, a jestli ne, nástroje jako Selenium, Cypress nebo Jenkins pro rychlou validaci kódu a CI/CD platformy jako GitLab nebo CircleCI pro flexibilní nasazení jsou dobrým začátkem.

Agilita a práce na dálku nejsou protiklady. Ve virtuální světě se vlastně pro agilní týmy nic moc nemění, jen nástroje – z lepítek k Muralu a Miru, z místnosti do virtuálního video prostoru. To, co je těžké udržet jsou vztahy, důvěra a spolupráce a nenechat lidi sklouznout k individuální práci. Individualismus zabíjí kulturu i inovace. A to asi v dnešním dynamicky se měnícím světě nechcete.

Pořád je co zlepšovat

Jedna z takových technik, která je v agilním světě často opomíjena, je pravidelná změna. Základem je uvědomit si, že ideální nikdy nebudete. Ideální stav neexistuje, ale je potřeba mu rozumět. Je to taková hvězda na horizontu, ke které se v pravidelných krátkých iteracích ohlížíme a hledáme cesty jak se k ní dostat blíž. Manageři, ale i ScrumMasteři se mě často ptají, kdy bude taková transformace hotová. Ale ona vlastně nikdy hotová nebude, protože v agilním světě pořád existuje lepší cesta. Takže paradoxně agilní transformace je u konce tehdy, když ten konec přestanete hledat a zvyknete si naopak neustále challengovat svůj styl práce, svoje procesy, svoje praktiky. Neustále hledat zlepšení.

Jak to celé funguje? Pracujeme v krátkých iteracích, a to ať už Sprintech nebo dnech, kde se učíme, zlepšujeme a měníme. Na konci každého Sprintu máme Retrospektivu, kde se díváme na to, co by šlo zlepšit v našem fungování abychom mohli lépe spolupracovat jako tým. Současně na konci každého Sprintu máme Sprint Review, kde se díváme na to, co by šlo zlepšit v našem produktu na základě zpětné vazby od zákazníků, a nakonec na denní bázi máme Daily Scrum, kde se díváme na to, jak bychom se mohli lépe zorganizovat, abychom maximalizovali hodnotu vzhledem k cíli Sprintu a dodali zákazníkům co nejvíce hodnoty. Takže Scrum není o ničem jiném než neustálém zlepšování.

Spoustu týmů po čase napadne, že by možná nemuseli dělat Scrum a že by bylo jednodušší zkusit Kanban. Kanban vlastně říká, že “Na začátku se nemusíte měnit, stačí vizualizovat jak pracujete a …”. Bohužel tam právě většina týmů skončí číst a jediné, co si pamatuje je, že se nemusí měnit. To je ale jen začátek věty. Ta druhá polovina říká “… pomocí neustálých drobných zlepšení a změn ve vašem fungování hledat efektivnější a lepší proces.” Takže se měnit musíte, a často velice radikálně. Ale to už jaksi většinou zapadne. A protože nejste dostatečně agilní, tedy nemáte rádi změny, chcete stabilitu a jistotu, tak takový Kanban často nic nezmění a zbyde z něj jen tabule, na kterou se nikdo nedívá. Ale všichni jsou spokojeni, protože se nemusí měnit.

Kaizen, tedy změna k lepšímu, se jako filozofie stal populární v Japonsku po druhé světové válce, kde výrazně ovlivnil řízení a kvalitu výroby. A z Japonska se tak dostal do celého světa. Agilní svět má Kaizen jako jeden ze základních principů. Je to jednoduché. Když se neměníte, nejste agilní.

Checklist Agilní organizace

Často se mě lidi ptají, jak poznám, že je organizace agilní. Tak jsem sepsala sedm bodů, na které se dívám já:

  1. Pracujeme týmově (tedy není to skupina samostatně pracujících jednotlivců)
  2. Neustále se zlepšujeme (nástroje, procesy a praktiky jsou téma k diskusi)
  3. Zákazník spolupracuje s týmem jako rovnocenný partner (není schovaný ani za manažera ani za smlouvu)
  4. Dodáváme business hodnotu (tedy nejen práci, ale něco co funguje end-to-end)
  5. Soustředíme se na hodnotu, měříme dopad na business (nikoliv effort, velocity a odhady)
  6. Týmy mají autonomii se samy rozhodovat a organizovat
  7. Vysoká transparentnost a dostupnost informací

Určitě by se toho našlo víc, ale tohle obvykle stačí. Druhá otázka z podobného spektra je, jestli můžeme někde vidět dobrou agilní transformaci. Problém ale není v tom něco vidět, problém je v tom, že lidé na začátku agilní cesty často hledají něco, co by mohli zkopírovat. Rádi by dostali checklist nástrojů a praktik. Agile ale není o praktikách, nástrojích ani procesech, a tak je v podstatě úplně jedno kam je pošlete. Oni stejně řeknou “Ale oni neměli tohle a neměli tamto”. Ono totiž není podstatné, co měli a co neměli, ale jak k věcem přistupovali. A to z návštěvy nikdy není vidět. Je to zakódováno v kultuře, je to schováno pod povrchem a nikdo si to ani neuvědomuje. Když jsem já začínala se Scrumem, bylo to ve firmě, která hodně spolupracovala, lidé si pomáhali navzájem, měli jsme hodně otevřenou kulturu. Takže nám spousta věcí šla sama. A my to brali za normální. Když jsem ale pak pracovala v různých jiných organizacích, zjistila jsem, že to bylo vlastně docela neobvyklé a unikátní prostředí. Ale já ho brala za standard a nikdy by mě nenapadlo ho zmínit. Takže nehledejte, co byste okopírovali. Agilními se musíte stát. A to se dá jen tak, že začnete experimentovat, zkoušet nové věci a postupně se zlepšovat. Žádné zkratky tam nejsou.

Týmová spolupráce vs. skupina jednotlivců

Jedním ze základních pilířů agilního fungování je tým. Na rozdíl od skupiny jednotlivců má takový tým společný cíl a dělá všechno proto, aby ho dosáhl. Skupina jednotlivců pracuje samostatně a hlavním úkolem je dobrá koordinace mezi nimi. Rozdají si úkoly a ty pak synchronizují. Každý ví, co je jeho práce, a moc se nestará o to co dělají ostatní. Ostatně to, co dělají ostatní není jeho práce.

Vznikají tak funkční sila, je to prostředí, které dobře funguje pro stabilní činnosti, které jsou naplánované dopředu. Je to prostředí, které nemá velkou zastupitelnost ani flexibilitu. Každý si hledí svého. Funguje dobře, dokud se priority moc nemění a dokud je business stabilní. Není moc kreativní ani inovativní. Dobře vytrénovaní jednotlivci jsou rychlí. Dodávají úkol za úkolem. Ale moc nepřemýšlí, jestli existuje lepší řešení, ani jestli to celé dohromady dává smysl. Prostě dělají svoje úlohy a o víc se nestarají.

Týmy naopak dokážou rychle najít kreativní řešení komplexních problémů. Jsou inovativnější a flexibilnější. Mají cíl a za tím jdou. Ve Scrumu je takovým Sprint Goal, který definuje business hodnotu, které chceme společně dosáhnout. Chvíli to trvá, než takový tým postavíte. Potřebujete, aby se lidi navzájem poznali, věřili si navzájem, byli ochotni diskutovat různé názory, spolupracovali, pomáhali si a přebírali zodpovědnost za společný cíl, nejen svoji část.

Takže jak na tom jste vy?

Skupina jednotlivců – Tým

Delegujeme zodpovědnost a pracujeme samostatně – Spolupracujeme na řešení

Individuální vlastnictví úkolů – Společné vlastnictví úkolů

Každý má vlastní cíl – Společný cíl

Jasně definovaný leader – Každý je leaderem v učité situaci

Fokus na efektivitu meetingů – Fokus na kvalitní diskusi a různé názory

Měříme efektivitu jednotlivců – Měříme dodanou hodnotu

Facilitace je klíč úspěchu

Posledních několik blog postů jsem tady psala o Scrum Eventech a Refinementu. Mají jedno společné. Jsou o spolupráci a vyžadují dobrou facilitaci. Když jsem začínala, myslela jsem si, že facilitace je o technikách. Vybrala jsem si pár a ty jsem se naučila. A že jich je. Dám vám pár příkladů na ukázku.

  • Checkin facilitační technika se hodí na začátek abyste zvedli energii v týmu, všichni promluvili. Použít můžete spoustu technik od klasického Weather checkin – kdybyste byli počasí/auto/filmová postava, jaké počasí/auta/filmové postavy byste byli až po různé hry. Základ je ale jednoduchost, rychlost a zábavná forma.
  • Round-robin facilitační technika – kde dáte týmu třeba míček, plyšáka, nebo fixu, a oni si sami určují kdo bude mluvit. Mluví jen ten, kdo má míček a až skončí, hodí ho dalšímu. Všichni tak mají možnost promluvit, ale tým si sám řídí, kdo bude další. Ve virtuálním světě tato technika funguje stejně. Jen přijdete o zábavu s házením vtipného předmětu a ten kdo mluví jen jednoduše řekne kdo je další.
  • Brainstorming facilitační technika se používá na sběr dat o dané oblasti. Sbírat můžete nápady, problémy, zlepšení, obavy,… Forma brainstormingu je flexibilní, můžete diskutovat, nápady zapisovat, generovat postit možnosti na zeď, tabuli, Miro/Mural board, můžete nechat lidi brainstormovat po skupinkách a pak výsledky prezentovat nebo to dělat ve skupině. Vše je možné.
  • Dot-voting je jednou z mnoha technik, kde potřebujete ze spousty nápadů udělat výběr důležitějších, kterým se pak budete věnovat v detailu. Každý má několik hlasů, řekněme tři, a ty může volně rozdat tématům. Klidně i všechny jednomu tématu které je pro něj nejdůležitější. Na papírové postity děláme tečky, odtud vznikl název dot-voting. Virtuální tabule jako je Mural a Miro vabízí dot-voting jako běžnou funkcionalitu.

A tak bych mohla pokračovat. Bez dobré facilitace se v agilním světě neobejde ani ScrumMaster ani Product Owner a ve finále nikdo kdo chce spolupracovat s ostatními. Je to nástroj, který v agilním prostředí potřebují umět manageři i členové týmu.

Ale to hlavní není o technikách. To, co dělá facilitátory úspěšnými, je umění vnímat co se ve skupině děje, pracovat s energií, předcházet konfliktům, utdžovat zdravé prostředí. A to je teprve to pravé umění.

Chcete se stát skvělým facilitátorem a vyzkoušet si facilitaci na praktických ukázkách z agilního světa? Agile Facilitation workshop je tím pravým začátkem.

Jak dělat Backlog Refinement

Když už jsme prošli všechny Scrum Eventy, zbývá se ještě zastavit u Backlog Refinementu. Některé firmy mu říkají Grooming, ale na jménu nakonec nesejde. Cílem je vytvořit Product Backlog v rozumné granularitě aby byl vidět výhled a tým měl připravenou práci na dva až tři Sprinty dopředu. Víc není potřeba, nebylo by to přehledné. A protože kažný Sprint tým několik položek Backlogu dokončí, musí každý Sprint několik větších kusů rozpadnout na menší a důležitější. Backlog Refinement tedy běží průběžně, tak jak je potřeba.

Klíčem k úspěchu je si uvědomit že Refinement je hlavně o spolupráci. Položky backlogu by nikdy neměly vznikat v izolaci. Tedy nepíše je Product Owner a nepředává je hotové týmu jak si někteří často myslí, ale je to o spolupráci a spoluvytváření. Kdo tedy položky backlogu píše? Všichni. Product Owner, zákazníci, stakeholdeři a členové týmu kterým ve Scrumu říkáme developers – tedy business analytici, developeři, testeři, designéři, … . Refinement probíhá různě. Někdy pozvete všechny na workshop, kde společně rozmyslí a rozpadnou několik položek backlogu, někdy se sejde jen pár členů týmu a spolu se zákazníkem začnete nějakou oblast popoisovat, a přemýšlet o potřebách které musí pokrýt. Jindy menší skupinka nějakou část produktu rozpadne na menší a jasnější kousky. Není to ani pravidelně naplánovaná aktivita tedy Scrum Event, není ani centralizovaná. Naopak. Zůčastní se ti co se potřebují zúčastnit, v čase, kdy je to potřeba. Ad hoc. Velmi agilní. Nicméně na konci dne musí celý Scrum tým rozumět jednotlivým položkám backlogu v dané granularitě a chápat jejich priority. Refinement tedy potřebuje jako pre-requisitu self-managing cross-funcitional tým. Self-managing proto, aby převzal za refinemnt vlastnictví a zodpovědnost a cross-funcitional aby měl potřebné znalosti a skily.

Role Procuct Ownera tedy není jako zapisovatel, ale spočívá spíše ve výběru vhodných účastníků a facilitaci společné spolupráce než psaní samotných storek. Product Owner Je často facilitátorem spolupráce, dává konverzaci směr a smysl. Product Owner dle potřeby může vždy požádat o facilitaci ScrumMastera, ale umění facilitace dělá refinement významně snažší.

Scrum Eventy: Sprint Review

Sprint Review je klíčovým prvkem Scrumu. Probíhá na konci každého Sprintu, aby Scrum tým zjistil, jestli jde správným směrem. Nutnou podmínkou úspěchu je dodávat hodnotu, ne jen nahodilé technické tásky.

Cíl: Získat zpětnou vazbu od zákazníků, případně interních stakeholderů.

Délka: Podle počtu týmů a zákazníků bude Sprint Review trvat něco mezi 15 min a dvěmi hodinami (pro produkty dodávané více týmy).

Jak: Hlavní je si uvědomit, že cílem Sprint Review není akceptace, ale zpětná vazba od zákazníků.

  • Sprint Review není prezentace pro Product Ownera, ten je součástí Scrum týmu a na Sprint Review společně s Developery ukazují hodnotu zákazníkům.
  • Členové týmu prezentují zákazníkům hodnotu, kterou dodali, nikoliv technické řešení. Zákazníci dávají týmu zpětnou vazbu.
  • Na zpětnou vazbu není třeba nijak reagovat, jen ji pochopit. Co s danou funkcionalitou uděláme je součástí Backlog Refinementu.
  • Je vhodné, aby Product Owner neprezentoval, ale byl dobrým posluchačem a zaměřil se na získání zpětné vazby.
  • Sprint Review není o prezentaci, ale o zpětné vazbě. Často tedy místo ukazování funkcionality necháte zákazníky produkt používat a díváte se, jak s produktem pracují.
  • Na Sprint Review musíte pozvat ty stakeholdery a zákazníky kteří vám na danou funkcionalitu mohou dát relevantní zpětnou vazbu.