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ílSpolečný cíl

Jasně definovaný leaderKaž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.

Scrum Eventy: Daily Scrum

Daily Scrum je nejkratší Scrum event který máme. Funguje jako zpětná vazba na spolupráci v týmu a probíhá každý den. Často se mu říká Standup nebo Daily. Aby fungoval musíte mít tým co má společný cíl, ne jen skupinu jednotlivců, co si rozdá úlohy a pak na nich samostatně pracuje.

Cíl: Cílem Daily Scrumu je podívat se, jak jsme pokročili vzhledem ke Sprint Goalu.

Délka: Jestliže vám Daily Scrum pravidelně trvá víc než 5 min, pravděpodobně tam řešíte věci, které na Daily Scrum nepatří.

Jak: Daily Scrum je reflexí týmu na self-management. I když jde vše dobře, je dobré se čas od času zastavit a podívat se, jestli vše ještě stihneme podle plánu anebo se musíme zorganizovat jinak.

  • Daily Scrum by měl být každý den ve stejný čas. Tedy nikde není řečeno, že by měl být ráno.
  • Sprint Goal není status jednotlivce a ani by neměl sklouznout k detailním konverzacím o řešení.
  • S problémy by členové týmu neměli čekat až na Daily Scrum, ale měli by je řešit v průběhu Sprintu.
  • Daily Scrum by neměl být jedinou příležitostí kdy se tým vidí. Scrum tým musí aktivně spolupracovat v průběhu celého Sprintu.
  • Daily Scrum je dobrou příležitostí se na chvíli zastavit a přeorganizovat, jak spolupracujeme.
  • Daily Scrum je pro Developery, nikoliv pro ScrumMastera nebo Product Ownera.
  • Jednotlivé položky Sprint Backlogu nevlastní jednotlivci, ale vždy celý tým.
  • V průběhu Sprintu je vhodné minimalizovat work in progress, tedy jako tým pracovat jen na jedné položce Sprint Backlogu v jeden čas, a dokončovat je tak postupně (Swarming). Tým pak má větší focus, pocit vlastnictví, a také zodpovědnost za dokončení.
  • Je doporučené nejen v rámci týmu spolupracovat na jedné položce backlogu ale i na jednotlivých táskách (Pairing, Mobbing).
  • Daily Scrum je nejen o reflexi ale i pomáhání si navzájem. Jednotlivé tásky nikomu nepatří, a tedy se často přesouvají mezi jednotlivými členy, aby tým optimalizoval práci, která je potřeba dokončit.

Přijďte na konferenci Agile Prague

Jako každý rok, chystáme v září konferenci Agile Prague. Agile Prague je každoročně největší událostí Agilního světa a stejně jako poslední roky má bohatý program. Takže na co se můžete těšit? Každý den začínáme dvěma keynotes, dále pak program kombinuje krátké 30 min talky které jdou vždy do hloubko konkrétního tématu, praktické odpolední workshopy a case-studies z agilních organizací.

Jako již tradičně poledne není jen čas oběda, ale i možnost zapojit se do openspace, kde program vzniká na místě a kdokoli z vás může nabídnout jakékoli téma o které se chce podělit nebo se o něm něco dozvědět. Věnovat se budeme velkým transformacím, leadershipu, modernímu managementu, kultuře týmů, produktům a scalingu, agilitě na úrovni organizace. Nechte se inspirovat.

Po oba dva dny zároveň běží Coaches Clinic, tedy místo, kde vám zkušení koučové poradí s čímkoli budete potřebovat.

Letos se můžete těšit na skvělé řečníky, například Mirko Kleinera, leadera v oblasti Lean-Agile Procurement, Romana Pichlera, předního odborníka na produktový management, a Pera Beininga, jediného autorizovaného školitele FaST v Evropě. A tak bych mohla pokračovat.

Ostatně posuďte sami a podívejte se na program konference.

Jako obvykle je konference v okolních dnech doplněna několika 2 denními  workshopy:

  • ICAgile Certified Professional in Agile Coaching s Johnem Barrattem 18.–19. září 2024,
  • Business Resilience s Angel Diaz Maroto 18.–19. září 2024,
  • Org Topologies™ Practitioner s Alexey Krivitskym a Rolandem Flemmem 12.–13. září 2024.

Září je veskrze agilní měsíc. Hned po AgilePrague která se koná 16.-17. září je 18. září přes ulici konference Women In Agile. A jako rozehřátí si můžete 9.-10. září ještě před Agile Prague zajet do Stockholmu na Regional Scrum Gathering.

Myslím, že se je na co těšit. Doufám, že se tam v září potkáme.  Registrujte se včas, míváme vyprodáno. 

Scrum Eventy: Sprint Planning

Na začátku každého Sprintu tým říká, co si myslí že dokončí, tedy vybírá Sprint Backlog. Je to taková předpověď toho, co asi budou dělat, tedy je možné ji kdykoliv v průběhu Sprintu změnit. Tým se ale zavazuje, že udělá maximum pro dosažení cíle Sprintu, který se naopak v průběhu Sprintu nemění.

Cíl: Na Sprint Planning přichází Product Owner se Sprint Goalem na základě kterého potom členové týmu (Developers) vybírají Sprint Backlog a domlouvají se, jak budou jako tým spolupracovat.

Délka: Když tým rozumí Product Backlogu, business hodnotě jednotlivých položek backlogu a prioritám je Sprint Planning je poměrně jednoduchý a netrvá déle než dvacet minut. Když ovšem tým dělá Backlog Refinement až na planningu, takový Sprint Planning trvá klidně i několik dní.

Jak na to: Prerequisitou Sprint Planningu je dobré porozumění Backlogu. Prioritní položky Backlogu by měly být připravené v takové kvalitě, aby tým rozuměl dané potřebě zákazníka a věděl, jak jí bude řešit.

  • Sprint Planning je dobré vizualizovat například na Scrum Boardu, aby všichni členové týmu viděli, co plánují dělat.
  • Začínající týmy si většinou na planningu rozpadnou vybrané položky Backlogu na konkrétní tásky aby každý člen týmu rozuměl konkrétním činnostem a lépe se jim plánovalo, jak na dané položce backlogu budou spolupracovat.
  • Sprint Goal se během Sprintu nemění, položky Sprint Backlogu a tásky se mohou měnit kdykoliv existuje lepší cesta, jak maximalizovat hodnotu vzhledem ke Sprint Goalu.
  • Sprint Goal je pro Sprint jenom jeden, aby určoval směr, položek Sprint Backlogu může být více. Obvykle týmy plánují 3-5 položek backlogu na Sprint, kde ta největší by měla být týmem dokončitelná maximálně za půl Sprintu.
  • Sprint Goal je řízený potřebou zákazníka, Sprint Backlog naopak definuje, co můžeme udělat my abychom potřebu zákazníka naplnili. Tásky potom reprezentují konkrétní činnosti například business analýzu, změnu backendu, frontendu, testování apod.

Scrum Eventy: Sprint

Sprint je největší event, který ve Scrumu máme. Je to takový kontejner na všechno ostatní. Mezi jednotlivými Sprinty není žádná mezera, když jeden skončí, další začíná.

Cíl: Cílem Sprintu je dodat co nejvíce business hodnoty zákazníkovi. Tato hodnota je definovaná Sprint Goalem.

Délka: Nejčastější délka Sprintu je 2 týdny, ale v dnešní době týmy často přechází na týdenní Sprinty, aby byly flexibilnější. Obecně platí, že čím kratší, tím lepší. Cokoli delší než 2 týdny se v současné době nepovažuje za dostatečně adaptivní, nebo chcete-li agilní. Sprint je fixní časový úsek, tedy jeho délka by se neměla měnit. Pravidelnost totiž přináší předvídatelnost. Všichni si zvyknou, tým i zákazníci.

Jak na to: Scrum nedefinuje kdy má Sprint začínat, ale ukazuje se, že začínat v pondělí a končit v pátek není moc praktické. Proto týmy začátek obvykle posouvají, aby běžel například od středy do úterý.

  • Business hodnota je ve Sprintu definovaná takzvaným Sprint Goalem, tedy cílem Sprintu. Cíl Sprintu se v průběhu Sprintu nemění a určuje tak pro tým směr, kterým se daný Sprint mají ubírat. Vybrané položky Sprint Backlogu se naopak v rámci Sprintu můžou změnit, kdykoliv existuje lepší cesta jak maximalizovat hodnotu vzhledem ke Sprint Goalu.
  • Sprint Goal se v rámci Sprintu nemění. Když ale Sprint Goal přestane být relevantní, může Product Owner Sprint zrušit. V takovém případě se všechna práce vrátí na začátek a naplánuje se nový Sprint. Je to poměrně nepříjemná a drahá situace, takže se to v praxi děje poměrně výjimečně například při akvizici nebo zásadní změně na trhu.
  • Sprint Goal definuje směr, kterým v rámci Sprintu směřujeme. Product Owner může definovat i produktové cíle (Product Goals) ve formě businessových KPIs nebo OKRs, které by naopak měly být konkrétní a dlouhodobé. Většinou trvá několik Sprintů, než se týmu podaří jich dosáhnout.
  • Sprint Goal definuje směr, ne co konkrétně se má dokončit.

Každý Sprint má obvykle jiný Sprint Goal.