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.

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.