Let's galvanise organizations Podcast

About Let's galvanise organizations Podcast

We galvanise companies, teams, and leaders turn the right ideas into valuable products. Rooted in first principles and proven practices, we focus on what works. Meaningfully. scrumdesk.substack.com (https://scrumdesk.substack.com?utm_medium=podcast)

Publisher

ScrumDesk Consultants

Category

business · technology

Language

sk

Explicit

No

First episode

16 Feb 2025

Latest episode

16 Feb 2025

Latest episodes

6 episodes in the feed.

1. 

   16 Feb 2025

   #6: Agilne. Otázky a odpovede?

   Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

2. 

   16 Feb 2025

   #5: Ako na tímové dysfunkcie?

   Patrik Lencioni (https://en.wikipedia.org/wiki/Patrick_Lencioni) v jeho knihe Päť dysfunkcií tímu definoval stupne, ktorými si tím pri svojom vývoji prechádza. Tieto stupne navyše sa veľmi jednoducho dajú identifikovať aj v agilnom tíme. Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

3. 

   16 Feb 2025

   #4: Inšpirácie zo sveta pre lepšie Agile na Slovensku

   Jedinečnosť tohto zdroja je v šírke záberu otázok, ktorý poskytuje vhľad nielen do toho aké nástroje a praktiky tímy používajú, ale aj prečo sa rozhodli pre Agile, čomu čelia, čo sa im podarilo dosiahnuť a ako prepojili biznis s IT vývojom. V štvrtom pokračovaní našich webinárov sme sa pozreli na to, aké inšpirácie by sme mohli nájsť v záveroch The State of Agile, ktoré by mohli pomôcť slovenským firmám v implementácii biznisovej agility. Čo sa dozviete? 🚀 Čo môže stav Agile vo svete ponúknuť agilným tímom na Slovenku v roku 2024? To je otázka, na ktorú sme sa v ScrumDesk tentokrát pozreli. Vychádzajúc zo 17-ročnej štúdie „The State of Agile“, ktorá sleduje vývoj agilných praktík a prístupov, odkryjeme, ako organizácie na Slovensku môžu čerpať inšpiráciu z globálnych trendov a poučiť sa z chýb, ktorými si už prešli iné organizácie. Témy, ktorých sme sa dotkli: * Miera adaptácie rôznych agilných metodík a prístupov v organizáciách. * Typické problémy pri zavádzaní Agile v organizáciách. * Dôvody, prečo organizácie implementujú agilné postupy. * Úspešnosť agilných transformácií. * Identifikácia príčin neúspešných transformácií. * Vplyv umelej inteligencie na rolu Scrum Mastera a Product Ownera. * Hybridné modely práce: Skúmanie hybridných pracovných modelov Porovnanie online vs. on-site tímov. Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

4. 

   16 Feb 2025

   #3: Čo šepká Kanban tabuľa

   Súvisí to aj s touto témou „Ako nefunovať agilne“, pretože to, akým spôsobom je Kanban tabuľa nastavená, spôsobuje neskôr problémy pri fungovaní Agile a je príčinou všelijakých pachutí ohľadom Agile. Prečo používate Kanban tabuľu? V praxi na tabuliach chýba “limituje rozpracovanosť”. Prečo by sme vlastne potrebovali limitovať rozpracovanosť? Veď mi predsa potrebujeme dodávať – dodávať viac, dodávať rýchlejšie. My potrebujeme využiť kapacity, my potrebujeme začať na tom ďalšom pracovať. A práve, paradoxne, tabuľa má napomáhať limitovať a maximalizovať efektivitu toku. V preklade, tabuľa by vám mala pomáhať úlohy čo najskôr dokončovať, nie rozpracovávať. Tak, ako tečie rieka, od prameňa až k moru, vy potrebujete urobiť dodávku, ten tok, čo najrýchlejšie, a preto by vám mala pomáhať zvyšovať efektivitu. Akékoľvek ďalšie obmedzenia, napríklad keď kvôli controlling potrebujete doplniť ďalšie položky a pri každej zmene potrebujete tie položky aktualizovať, vám spôsobuje zníženie efektivity toku. Takže treba sa zamyslieť nad tým, v akých momentoch akú informáciu budeme potrebovať. Elementy dobrej Kanban tabule Základné elementy dobrej Kanban tabule sú v podstate veľmi jednoduché. V prvom rade je prevláda nepochopenie na čo slúži Kanban tabuľa. Kanban tabuľa je mnohokrát nazývaná “Task Board”, čiže tabuľa úloh. Mali by ste si nastaviť, či na tabuli budete zobrazovať úlohy, teda aktivity, slovesá “robiť, vytvárať, nasadzovať, dizajnovať, kresliť analyzovať”, alebo tam budete ukladať výsledky, ktoré potrebujete dosiahnuť. Ak poznáte Agile Manifesto, tak viete, že v prvom rade je funkčný produkt, funkčný výsledok. Preto je vhodné mať na tabuli výsledky, alebo v angličtine ouputy. Niektoré agile tímy idú ešte dokonca oveľa ďalej – majú tam dokonca „outcomy“, to znamená nejaké medziciele, medzistavy, ktoré by to pomohli dosiahnúť a na tabuli si nesledujú len aktivity, ale naopak, tie vyššie a dôležitejšie veci. Signálka V neposlednom rade tabuľa, ak ju nevoláte iba task board, ale ju voláte Kanban tabuľa, tak vás privádza práve k tomu slovíčku Kanban, čo v japončine znamená kartička. Kartička je v podstate signál, ktorý môžete používať aj na to, aby ste videli stav, niečo si poznamenali, alebo, ak máte závislosti, mali signálku od iného tímu o stave tejto závislosti. Signálka môže indikovať problém V princípe taká dobrá Kanban tabuľa je pripomienkovací systém, ktorý vám umožňuje uvoľniť hlavu a tých povestných sedem zásuviek, ktoré máme v mozgu. Dovoľuje použiť tie zásuvky na niečo rozumné, nie len na sledovanie si svojich úloh. Ľudia, ktorí používajú Kanban tabuľu, sa vyjadrujú, že im Kanban tabuľa pomáha zabúdať na menej dôležité veci a nezabúdať na tie dôležité. Dobrá tabuľa má aj viacero stĺpcov. Je dôležité koľko má byť stĺpcov a čo stĺpce reprezentujú. V niektorých prípadoch je tých vizuálnych signálov tak veľa, že potrebujete mať tam plavecké dráhy – swimlanes. Vzhľadom na definíciu Kanban tabule, je prirodzené, že posledný element, ktorý nám chýba sú práve limity. Limity pomáhajú obmedziť počet úloh kariet v danom stave, čo nám pomôže dosiahnuť efektívnejší tok. To nám pomôže veci dokončovať a nezačínať. Ako lepšie, transparetnejšie? Veľmi dobrým zvykom Scrum Mastra je pýtať sa: „Ako môžem tento systém spraviť transparentnejší?“. Transparentnosť potrebujete pre rýchle preskúmanie, pre rýchlu adaptáciu, jednoducho potrebujete veci zbadať a nie len vidieť. Na fyzických tabuliach viete používať karty rôznych veľkostí, ktoré môžu reprezentovať rôzne typy informácií alebo môžu reprezentovať hierarchiu požiadaviek. Zároveň môžete používať aj rôzne tvary, takže ak v niektorých prípadoch máte chybu a budete používať nejaký tvar, tak veľmi rýchlo poodstúpením od tabule, spoznáte kde je chyba, v akom je stave a koľko tých chýb máte. Ďalším tipom sú farby. Napr. ak máte pre chyby karty červenej farby, tak veľmi jednoduchým spôsobom zistíte, bez toho, aby ste museli tie karty čítať, koľko vlastne máte chýb na danej tabuli v momentálne akom stave. Veľkosti, tvary a farby sú vynikajúce, ak používate predovšetkým fyzickú tabuľu. Ak máte workshopy, ktoré robíte spolu so svojimi zákazníkmi, tak je to absolútne vynikajúca vec. Ľudia sú sklr zladení, chápu oveľa viac bez toho, aby museli čítať detailné popisy, pretože čo si budeme klamať, ľudia málokedy naozaj čítajú. Ľudia ju skôr skenujú. Práve farby, tvary a veľkosti vám vedia veci opticky objasniť a vyjasniť oveľa rýchlejšie. Stĺpce tabule. Nie je menej viac? Sú dva možné prístupy k stĺpcom. Ani jeden nie je lepší, ani jeden nie je horší, je dobré sa nad tým zamyslieť ktorý z nich potrebujete a prečo. Začal by som možno menej násilným, evolučným prístupom k návrhu layoutu tabule. Je to častý spôsob ako zavádzame Agile v ScrumDesku v tímoch, pre ktoré je Agile pomerne veľkou revolúciou. Mapovanie aktuálneho stavu Prvý prístup je v tom, že stĺpce mapujú aktuálny proces. Od idey až po tú dodávku idey. Proces dodávky rozdeliť do jednotlivých stĺpcov na danej tabuli. Mapujem aktuálny stav systému. Po nejakých iteráciách, zvyčajne je to záležitosť 2-3 týždňov, sa zrazu začne tá tabuľa sama štruktúrovať, čistiť. Začnú vznikať dohody čo budeme dávať na túto tabuľu, či aktivity alebo výsledky. Začneme sa baviť o stĺpcoch, či potrebujeme mať podstavy, alebo nie. Začneme sa baviť ako sa tie stĺpce volajú. Možno prídeme k tomu, že pôvodne sme mali viacero stĺpcov, ktoré reprezentovali jeden stav. Napr. * na zváženie, * aktuálne zvažujem, * vec je zamietnutá alebo povolená Menej stavov je výsledok, ktorý je oveľa lepší. Čím menej stavov, tým rýchlejšie dôjdeme k výsledku. Zároveň, to neirituje toľko ľudí, pretože veľa stavov privádza ľudí k veľmi zásadnej otázke: „Čo vlastne tento stav znamená?“, „Kedy mám tu kartu do toho stavu dať a kedy nie?“. V začiatkoch v roku 2008 som ako mentor zažil aj to, že medzi jednotlivými stavmi boli ľudia nútení uviesť dôvod zmeny stavu. V princípe tie stredné stavy absolútne nenávideli, karty ostávali v stave „To-Do“ aj 250 dní a po 250 dňoch sa zrazu objavili v stave „Done“, ale medzitým museli preskákať cez všetko. Radikálne Druhý prístup k stĺpcom tabule je radikálnejší. Privádza však tím k lepším štandardom. Takýto layout tabule má iba tri stavy: „To-Do“, „In Progress“ a „Done“. Prirodzene to vedie k debatám typu „Ak je nejaká požiadavka v „In Progress“, znamená, že sa momentálne testuje? Znamená, že sa momentálne kreslí? Znamená, že sa momentálne nasadzuje alebo beží tam code review?“ Ako si všimnete, tak odpoveďami budú slovesá. Slovesá, aktivity, je nutné spraviť, aby ste mali výsledok. Zaujíma zákazníkov, používateľov, výsledok alebo ho zaujímajú práve tie jednotlivé aktivity?“ Ak ho zaujímajú aktivity, tak sa pravdepodobne bavíme o tom, že ten zákazník nemá dôveru v ten tím, a teda potrebuje mať mikromanažment, mikrokontrolu. Ak ho zaujímajú výsledky, potom úplne zbytočne zákazník číta o aktivitách, sú pre neho absolútne zbytočné, a on možno potrebuje mať takýto jednoduchší pohľad. A to nás privádza predovšetkým k ďalšiemu kroku, a to k tomu, že je dobré si vybrať layout tej tabule. Rozloženie tabule. Vidíte konzistenciu? Layouty tabule môžu byť v princípe dva. Prvý layout je Kanban tabuľa, kedy tie karty reprezentujú outputy, teda vlastnosti, požiadavky, ale nie sú na nich evidované tie jednotlivé aktivity. Aktivity sú na detaile karty alebo z druhej strany, vo forme či už nejakého kontrolného zoznamu, checklistu, alebo sú tam nejaké ďalšie subtasky, ale tie nevidíte na prednej strane karty. Pozretím sa na ľavú tabuľu teda vidíte, že požiadavka je v nejakom stave „In Progress“ ale neviete v akom stave a ak tá požiadavka je veľká, tak tá požiadavka bude v tom stave „In Progress“ pomerne dlho. To nás privádza k tomu, že nám začne klesať dôvera, začne nám stúpať mikromanažment, a to vedie k tomu, že budete potrebovať sa baviť viac o mítingoch, alebo po nejakom čase budete nepríjemne prekvapení. Bude vám chýbať transparentnosť. S novými tímami, s ktorými pracujeme v ScrumDesku, sa veľmi snažíme aplikovať Scrumban tabuľu. Scrumban tabuľa poskytuje viditeľnosť obidvom stranám. Klientovi aj tímu. Zákazníkom poskytuje viditeľnosť veľkej karty, ktorá je zvyčajne backlog item alebo požiadavka, vlastnosť. V tom istom riadku sú aktivity, ktoré je potrebné spraviť, aby ten výsledok bol doručený. Samozrejme, keď sú všetky aktivity hotové, tak potom tá veľká karta môže byť na fyzickej tabuli, dosť často je to aj takto robené – na fyzickej je celá karta presunutá do „Done“. ScrumBan tabuľa umožňuje tímu vidieť nekonzistnosti, veci, na ktoré zabudli, umožňuje im vidieť štandardy, Zo ScrumBan tabule môžete vydolovať štandardy. Tím s týmto systémom pomerne rýchlo funguje a pomerne jednoducho si dokáže nastaviť štandardy a namiesto toho, aby robil napríklad „Design Backendu“, „Design API“, „Vývoj API“, „Testovanie API“, „Code Review API“, tak časom, si to zjednoduší do karty „Backend“. Takto jednoducho sám zvýši kvalitu svojho fungovania. Kanban vs. ScrumBan layout Vďaka transparentnosti ľudia prekonávajú svoju rezistenciu a obavy pri spracovaní nejasných požiadaviek, požiadaviek, na ktorých v živote nerobili. Mne osobne sa stal prípad, že sme mali v našej aplikácii doplniť VISA platbu. Keď sme pridali kartičku s názvom „VISA platba“ v Kanban režime, nijaký vývojár to nechcel zobrať, pretože sa toho obávalii. Smrdelo to tým, že môže nastať niekde nejaký veľký problém ak platby neprejdú. Keď sme tú kartu rozbili na aktivity systémom Scrumban, tak objavili, že pre tú VISA platbu potrebujeme urobiť databázovú tabuľku transakcií a tú vie urobiť každý developer. V backendových službách vedia API urobiť už len niektorí z nich, frontendový formulár vedeli urobiť viacerí z nich a ostal nám jeden jediný Čierny Peter. Tým Čiernym Petrom bolo nakoniec napojenie na bankovú službu, ktorá nám tu VISA platbu umožní spracovať. Vzal si ho na seba senior. Zatiaľ čo on študoval, robil na tej karte „In Progress“, tak ostatní mu pripravovali celkové prostredie aj kód na to, aby vedel si API skúšať priamo v našej aplikácií ešte počas samotného vývoja. Layout Scrumban má obrovskú výhodu aj v tom, že veľmi ľahko vidíte úlohy, ktoré vám ostávajú. Pýtajú sa nás ako je to tam s poradím úloh. Princíp je veľmi jednoduchý – zľava doprava, zhora dole. Dohodnite si to takto jednoducho a nemusíte si všímať žiadne závislosti a zvyšovať mieru evidencie. Dráhy tabule Ďalším rozšírením Kanban tabule, predovšetkým v prípade, že tých úloh je veľmi veľa, je zavedenie „swimlanes“, plaveckých dráh. Najhoršie, čo môžete spraviť, a robí to 90% tímov, je nastavenie swimlanes podľa človeka v tíme. V princípe, má to aj nejaké rácio, ktoré je ale také „thinking fast“. Ráciom je: „Chcem vidieť svoje úlohy. Ja, Scrum Master, chcem pomôcť človeku zorientovať sa v množstve kariet aby si veľmi ľahko v tom množstve kariet našiel svoje úlohy.“ V skutočnosti však týmto režimom dostávate ľudí v tíme do spôsobu fungovania „Ja, moje úlohy, a ostatné úlohy“. Ľudia nespolupracujú, každý pozerá na svoj riadok, a tak sa vám to prejaví aj na dennom stand-upe, pretože každý odverklikuje svoj vlastný riadok. Na standupe je tak veľmi málo interakcie. Veľmi málo lepidla medzi členmi toho tímu. Predošlý príklad so Scrumban tabuľou vám umožňuje vytvárať práve to lepidlo a práve vám umožňuje v tom tíme vytvoriť tú mikroskupinu, ktorá pracuje na mikropožiadavke a spolupracujú na dodaní spoločného výsledku. Dávajte so pozor na to, aby sa vám tím vďaka Kanban tabuli nerozpadol na jednotlivcov. Swimlanes a priority Ďalšou nevýhodou swimlanes je otázka priorít. Bez swimlanes sú priority dané veľmi jednoducho, poradím kariet. Ak máte skupiny, objavuje sa otázka: * „Je táto skupina dôležitejšia ako druhá?“ * „V tej skupine, je táto karta dôležitejšia ako druhá?“ * „Z celkového pohľadu, nemala byť karta zo skupiny A pred inou kartou zo skupiny C, alebo naopak?“. Strácate pojem o celkových prioritách. Na druhej strane, mnohí z nás nepracujú v ideálnom svete, kde pracujú pre jedného zákazníka alebo na jednom projekte na 100%. V tomto prípade swimlanes môžu veľmi napomôcť zorientovať sa v projektoch. Predovšetkým ak nemáte v tíme multidisciplínnosť a zastupiteľnosť. Je ešte jedno použitie swimlanes, ktoré je veľmi zmysluplné. Je to predovšetkým v stave, keď potrebujete veľmi rýchlo reagovať a potrebujete kartu zbadať okamžite keď nastane problém. Vtedy je prvý riadok je vyhradený pre chyby, alebo pre supportné prípady, ktoré potrebujete podľa SLA spracovať okamžite. Ak sa ľudia naučia v tíme ťahať karty podľa poradia, tak okamžite natrafia práve na tú najdôležitejšiu vec. Niektorí robia spájanie do plaveckých dráh aj podľa typov požiadaviek. Tu by som bol pomerne opatrný, pretože to môže viesť práve k tomu „Ale veď to je len výskum“, „Ale veď, ale veď“. Detail na karte. Vidíte dôležité? Veľkou otázkou je koľko detailov chcete vidieť na karte. Až príliš často sa chce vidieť všetko a okamžite. V skutočnosti je na mieste otázka, či práve pre túto mieru detailu nestrácate dôležitú informáciu. Je veľmi dobré sa pýtať otázku: „Na čo využívame túto informáciu?“. Na kartách vídavame stavy, podstavy, spôsob riešenia, štítky, vidíme tam ľudí, ktorí sú priradení, časy a podobne. Nie v každom momente potrebujete mať všetky detaily. Možno si urobte v tom elektronickom nástroji aj tabule pre tieto rôzne situácie. Vidieť menej nemusí byť zlé, práve naopak, zbadáte tým viac. Popis karty. Vidíte hodnotné? Dôležitý je aj spôsob, akým sú informácie na karte napísané. A to je ďalší bod, v ktorom tímy zlyhávajú. Vidíme karty, ktoré majú informačnú hodnotu s absolútnou nulou, napríklad karta s názvom „Vývoj“. Vývoj čoho? Vývoj prečo? Vývoj na čom? Vývoj kde? Je lepšie, ak na kartách máte napísaný výsledok, napr. vo forme „Nový používateľ“. Je lepšie keď napísať „Príjem vs. Výdaj“. Slovesá „vyvíjať, vytvárať“ si nechajte na malé kartičky, pre aktivity. Nakoniec, tie slovesá ani nemusíte písať, pretože už len keď tam napíšem „Backend“, tak je jasné, že to sa bude vyvíjať, preferujte viac podstatné mená. Až príliš často sú na kartách zbytočnosti. Opakovanie zbytočných názvov, opakovanie user story formátov a podobne. Najhoršie, čo som zažil, boli karty na každého človeka v tíme pre denný stand-up. Na tabuli bolo 10 kariet „Denný Stand-Up“, ktoré sa neustále akutalizovali a zaevidovávali sa minúty Stand-upu. Prečo? Lebo to chce klient evidovať. V tomto prípade zmeňte kontrakt a nastavte Stand-Up na pol hodinu a malo by to zafungovať. Je otázne, či si tam chcete evidovať stretnutia, tu môžete použiť princíp karta ako signálka. Je dobré v tíme si zaevidovať, že stretnutie bolo, tým pádom sa členovia tímu vedia rozhodnúť, či budú pracovať na nejakej ďalšej veci alebo nie. Ak máte dohodnutý štandard, kde máte tie informácie zaznamenané, tak vedia, že môžu ďalej pokračovať. Niekedy by však stretnutia na tabuli nemali byť, napríklad v prípade denného Stand-Upu. Už vôbec nie je dobré, ak používate Kanban tabuľu namiesto vášho denného kalendára. To sú dva rôzne nástroje – tabuľa je signálna tabuľa na to, aby ľudia vedeli, že už môžu začať na niečom pracovať a predovšetkým čo dokončiť. Zbytočnosti typu „Dovolenky“, „Blockery“, „Sťahovanie“, „Presun“, „Reinštalácia počítača“ veľmi, veľmi zvážte, pretože vám to pridáva ďalšie karty. Strácate v množstve kariet orientáciu, neviete priorizovať, spomaľujete celý tok. Je ešte jeden taký „neduh“, ktorý bohužiaľ je v mnohých firmách nutný a to sú „Zberné úlohy“. Na tie si dajte veľký pozor. Ľudia začnú zberné úlohy používať jednoduchým systémom: „Ak neviem, kde čo mám zaevidovať, nechce sa mi nad tým premýšľať, tak to dám na tú zbernú kartu.“ Neraz tak celé sprinty nakoniec skončia na zberných kartách. Zberné karty nemám rád, radšej chcem, aby na karte bolo napísané čo sa tam zbiera a prečo to chceme vedieť. Ak je na karte napísané „Evidenčná úloha“ alebo „Zberná úloha“, okamžite brzda, stopka, vrátiť sa, zmeniť to. Na tých kartách má byť zapísaná hodnota. Stručne je lepšie Na kartách by mala byť hodnota. A tú hodnotu je dobre zbadať. Preto, vo forme zápisu, je veľmi dobré byť stručný a presný, a namiesto nejakého vypisovania, lebo Agile vraví, že musíte písať User Story, je lepšie, ak na karte napíšete výsledok, ktorý chcete dosiahnúť. Najprv dokončiť! S Kanban tabuľou je potrebné pracovať disciplinovane. Napriek tomu, že sa to učí na každom jednom školení, ľudia na to zabúdajú. Kanban tabuľa sa používa v smere z „To Do“ do „Done“, zľava do prava. Opačný smer by ste nemali mať. Ak je potrebné urobiť opačný smer – niečo bolo „Done“ a zrazu to musíte dávať to „In Progress“, strácate informáciu o tom, prečo potrebujete úlohu opäť rozpracovať. Nemáte možnosť to vyhodnocovať, nemáte možnosť nabudúce tej situácií predísť a zabrániť tomu, aby sa tieto neustále poskakovania na tabuli nevyskytovali. Poskakovania kariet indikujú zbytočnosť. A práve preto v tom prípade radšej vytvorím novú kartu. Začnem na nej pracovať, a neskôr viem vďaka tomu lepšie plánovať. Ak sa objaví nová aktivita, pridajte ju na tabuľu. Pridajte ju do „To Do“. Na konci sprintu tak ľahlo nájdete odpovede na otázku „Čo sme pri plánovaní zabudli, čo sme museli pridávať a v tomto sprinte by sme už nemali zabudnúť? Prečo?“. Priority V Agile nám nestačí sústredenie sa na dokončenie. Ľudia si veľmi radi vyberajú prácu podľa toho, čo vedia a čo chcú. Je dobré dodržiavať priority. Karty, ktoré sú hore na tej tabuli sú dôležitejšie ako tie v strede, ako tie, ktoré sú na tabuli úplne dole. Samozrejme, že tie najdôležitejšie chcete čo najrýchlejšie dokončiť. Počas sprintu odstúpte od tabule, pozrite sa na tabuľu z diaľky. Mali by ste vidieť karty na diagonále na tabuli. To indikuje prácu podľa priorít. Aj v prípade, ak nestihnete nejaké úlohy v dolnej časti tabule, tak sú to úlohy s najnižšou prioritou. Nie je až taký problém ich presunúť do nasledujúceho sprintu. Predovšetkým, ak máte možnosť častej dodávky, a teda ak máte DevOps a viete tú kartu dodať o deň neskôr. Ak by ste ale pracovali na úlohách v opačnom smere, tak už len smer kariet vám indikuje, že robíte na menej dôležitých veciach. Úplne prirodzene môžete od klienta očakávať frustráciu, pretože dôležitejšie veci nemá hotové. Síce ste minuli peniaze a vybrali budget, ale reálne hodnota nie je vytvorená. To vedie k strate dôvery. Aplikujte jednoduchý princíp – nemáš čo robiť, berieš ďalšiu kartu podľa poradia a podľa „smieš“ „vieš“, „chceš“. Limitujte rozpracovanosť Viete ako sa správne dizajnujú potrubia? Viete, že každé koleno, každá rozdvojka spôsobuje spomaľovanie toku? Vodári chcú mať čo najmenej rozdvojok, chcú mať čo najmenej kolien na celom potrubí. Vo vývoji produktov je to rovnaké. Nechcete mať v nejakom stave zbernú nádobu, v ktorej sa zbiera voda, pretože úplne prirodzene sa tok spomalí. Tok chcete mať čo najlaminárnejší, čo najrovnomernejší. A tu prichádzame k tomu, čo znamená slovo „Work In Progress Limit“, „WIP Limit“, ktorý často zbadáte v nástrojoch nad stĺpcami tabule. Ak má stĺpec WIP limit 4, môžete tam dať max. 4 karty. V momente, keď pridáte piatu, celý ten stĺpec sčervená, čím vám naznačuje „Teraz už možeš byť neefektívny. Skús zvážiť, čo by si mohol najprv dokončiť a až potom pridať túto ďalšiu kartu. Tie počty môžu byť rôzne. Číslo nemusí byť rovnaké pre všetky stĺpce. V mojej konzultačnej praxi som zatiaľ mal iba jeden jediný tím, ktorý mal odvahu na to, že ak vieme dodávať za Sprint desať kariet, tak si dal limit deať cez všetky stavy. Tým pádom sa potreba rozpracovať prevalila na vstup, kde sa táto otázka zmenila na otázku „Ktorých správnych desať dokončíme?“. A to viedlo k tomu, že v danom prípade sa firma musela oprieť do svojich biznisových modelov, biznisových pravidiel a začať vyberať tie rozumné veci. Ak je desať málo, potom vyvstane iná otázka „Ako zvýšime tú efektivitu, prečo vieme spracovať iba tých 10?“. Mnohokrát, keď sa do procesu zamotá preratávanie kapacít, o chvíľku zabudnete na limity a ste tak na tom opäť zle. WIP limit treba neustále reflektovať. Pri akomkoľvek zásahu vám každá zmena môže tento limit narušiť. Pozorovanie je kľúčová práca Scrum Mastra. Na zmeranie toku máte aj vizualizačné nástroje, ako Cummulative Flow Diagram, Control Chart. Čo analyzovať a vylepšiť? Takže čo analyzovať a vylepšiť, v tom takom bežnom živote, keď vám skončí denný Stand-Up? Pred denným Stand-Upom by si mal dobrý Scrum Master sadnúť, zanalyzovať Kanban tabuľu a snažiť sa pochopiť kde čo viazne. Pýtať sa: “Ako túto vec umožním tímu zviditeľniť, aby si to v tíme všimli, aby som im to ja nemusel pripomínať?“ Vizualizácia Vizualizácia môže byť vo veľkostiach, farbách, tvaroch. Môžu to byť ikony a v niektorých nástrojoch k tomu viete pridávať aj cover image. Konzistencia Ako Scrum Mastri musíte venovať pozornosť konzistentnosti a disciplíne prístupu k práci. Štandardom. Napr. či má každý backlog item svoje aktivity. Mali by ste pozrieť na stav. Nie všetky nástroje sú stavané na to, aby udržiavali stav konzistentne. Napr. stav ako je vykázaná práca. Dokonca aj hlúposti, ako napr. či je čas ukončenej úlohy je skutočne nulový. Pozrite sa na obmedzenia – prečo je úloha blokovaná. Ako dlho, ako staré to obmedzenie je, na koho čakáme. Ponorte sa do porozumenia, prečo sme vôbec tú úlohu naplánovali, keď je blokovaná už v “To Do”. Takáto úloha nemala byť ani naplánovaná. Skontrolujte, či sú karty priradené. Má byť karta “To Do” priradená alebo nie? My karty priradzujeme, ale v “To Do” stĺpci priradenie znamená, že na danej karte by som rád pracoval. Neznamená, že aj budem, ale vyjadruje to viditeľne pre všetkých ostatných “veľmi rád by som na tom chcel”. A zrazu máme v tíme lepšiu komunikáciu a nastavujeme si samoorganizáciu. Úlohy, ktoré nie sú v “In Progress”, nie sú veľmi často priradené. Tím vôbec netuší, kto na nich pracuje. Samozrejme, že sú nástroje, ktoré vás nútia to priradenie vyklikať. Sú to 2-3 kliky naviac. Pri dobrom toole to nepotrebujete – jednoducho potiahnete kartu do “In Progress” a karta vám je automaticky priradená. Už len tento jednoduchý trik vám pomôže odbúrať pomerne veľké percento rezistencie k nástrojom. A posledná vec, možno konšpiratívna, sú odhady. Nie každý tím odhaduje, nie každý chce, nie každý vie. Každopádne vám odhady pomôžu viac odhaliť a nastaviť štandardy. Neskôr budete vedieť ľahko odhadnúť náročnosť. Bude vám stačiť karty počítať. Samoorganizácia Dobrá Kanban tabuľa by mala podporovať samo-organizáciu. Scrum Mastri by sa mali pýtať: “Aké situácie potrebujeme identifikovať včas a mali by sme ich v nejakej forme vidieť?”. Tabuľa by mala zvýrazňovať situáciu keď máte v tíme človeka, ktorý si berie stále rovnaký typ úloh. Ak sa v tíme nezastupujú, pretože sa boja, pretože sa to nedá. Veľa firiem sa zastupiteľnosti bojí kvôli odchodu ľudí. Minulý týždeň mi na školení povedali v jednom tíme, že sa dosť obávajú, že seniori povedia, že to je tak juniorný typ práce, že jednoducho oni toto robiť ani nechcú. Neriešenie však povedie k tomu, že juniori budú stále juniormi a seniori budú ešte väčšími seniormi. Špecializácia môže byť nielen v type aktivít, ale aj v doméne problémov – napr. spracovanie platieb, reportovanie, dátové transformácie. Je super, ak by tabuľa ukazuje aj to, či karty sú aktualizované. V niektorých nástrojoch (https://www.scrumdesk.com/) si viete zvoliť okraje alebo aj farbu. Už na prvý pohľad by malo byť vidno, že karta nebola aktualizovaná, čo vás, Scrum Mastrov, odbremení z toho neustáleho poháňania ľudí aby si aktualizovali úlohu. Členovia tímu sa vďaka takejto transparentnosti sami prispôsobia a kartu posunú. Nechcú byť tým, ktorý to stále neaktualizuje. Najdôležitejší návyk dobrého Scrum mastra ohľadom Kanban tabule je nej odstúpiť a hľadať na nej inšpiráciu pre pravidlá a dohody. Ako veci nerobiť zle, ako neobjavovať problémy, ako nezastavovať, ako si lepšie rozdeliť prácu, ako ju skôr dokončiť. Práve pravidlá a dohody pri dobre nastavenej tabuli vám vyskakujú úplne samé. Ak je tabuľa iba nástrojom pre evidenciu, k pravidlám a štandardom nikdy neprídete. Je dobré sa zamyslieť nad tým aké filtre je dobré mať. Každý z nástrojov vám umožňuje urobiť filter “Moje úlohy”. S týmto filtrom osobne veľmi bojujem. Aj keď je pre ľudí možno veľmi dôležitý, ja ho rád v zozname filtrov dávam na posledné miesta, aby ľudia mali skôr na mysli ako pomôžem kolegovi a nie sám sebe. Filtre definujem podľa princípov samo-organizácie a konzistencie, ako napríklad filter Skryté chyby, aby ten tím si ich sám všimol. Skúseným mentorom stačí vidieť Kanban tabuľu a graf, napríklad Burn Down graf alebo Cummulative Flow. Z nich sa dá vydestilovať veľa problémov, ktoré máte, ktoré vás blokujú, pre ktoré je Agile u vás možno trochu zamotané. Otázka Scrum Mastra na každý deň “Čo nám šepká tabuľa? Čo musíme spraviť, aby sme pravdu videli na Kanban tabuli?”. Pretože vidieť znamená zbadať. Ak touto otázkou naštartujete deň, verím, že v priebehu niekoľkých Sprintov bude aj váš tím oveľa ďalej a nebude vnímať tabuľu ako nástroj pre sledovanie, ale ako nástroj pre podnecovanie, motiváciu dokončiť. Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

5. 

   16 Feb 2025

   #2: Scrum Majster, Master a Maestro

   O slovíčku Master Porozumenie začína spoločným jazykom. Aj preto sa na začiatku ponoríme do slova Master z rôznych perspektív. Prekvapujúce pre nás ako veľmi ovplyvňuje porozumenie výzanmu slova Master reálnu aplikáciu v tejto roli. Slová Majster, Master aj Maestro majú rovnaký základ v latinčine. Sú odvodené od latinského slova Magister. Osobnosť s autoritou, zručnosťou a expertízou. Definícia slova Majster, Master, Maestro, lat. Magister Je zaujímavé, ako pomenovanie tejto kľúčovej roly v Scrum vyjadruje podstatu správania a prístupu k tejto roli. Stačí sa spýtať jendoduché sebareflexívne otázky: * Čo Vás definuje ako osobnosť? Ako dobre poznáte svoju osobnosť? Ste osobnosťou v tíme a v organizácii? * Ako ste na tom s autoritou? Čo autorita pre Vás znamená? Čo znamená pre členov vášho tímu? Akou autoritou ste vo vašej organizácii? * A čo Vaše zručnosti? Aké zručnosti potrebujete pre rolu Scrum Master? Akú úroveň týtcho zručností máte? Aké iné zručnosti potrebuje Váš tím, alebo organizácia? * A poslednou je expertíza. Čo definuje Vašu expertízu v roli Scrum Master? Ako ju viete preukázať? Kedy ju potrebujete využiť? Čo potrebujete spraviť pre starostilvosť o svoju expertízu? Veľa otázok. A pritom tak jednoduché slovo. Vynikajúci Scrum Master má ale tento kód sebareflexie silno vybudovaný. Scrum Master a Scrum Guide Slovo Scrum Master bolo definované autormi Scrum Guide (https://scrumguides.org/scrum-guide.html#scrum-master). Jeho definícia nie je dlhá. Je zameraná na aktivity, zodpovednosti a prístup v tejto roli. Stručnosť a presnoť definície poskytuje priestor pre interpetáciu. Nie je sa čo čudovať. Scrum je nakonie iba rámec, nie presná metodológia. Scrum Master je v súvislosti so Scrum spomínaný iba v tomto krátkom popise šeťkrát. Yámerom teda bolo úžšie naviayať rolu Scrum Master na Scrum samotný. Inak povedané: Scrum Master „masteruje“, kuje, Scrum. Ospravedlňujem sa za skomolenie anglického slova, ale presne vystihuje podstatu tejto roly. Má to byť kontinuálny proces zlepšovania, kutia, Scrum. Vplyv jazyka na aplikáciu roly Scrum Master A týmto sa dostávame k vplyvu jazyka na aplikáciu a porozumenie roly Scrum v rámci organizácie. V slovenčine je slovo Scrum Master chápané ako rola, ako fixná pozícia. Je to podstatné meno. Je to označenie človaka, ktorý má svoju expertízu a zručnosti, ktoré aplikuje v práci. Je to rola s pozíciou kontroly aplikácie Scrum v organizácii. V angličtine nachádzame výraznejší rozdiel. Časť Master je v označení roly slovesom. Scrum Master označuje kontinuálny, neustály, proces ‚to master‘. Význam je oveľa bližší ‚kutiu‘ Scrum. Ešte výraznejší rozdiel je v porozumení tejto roly v Japonsku. Rozdiel medzi východnou a západnou kultúrou je aj v tomto prípade obohacujúci. Scrum Master bolo prevzané z angličtiny s jeho. zameraním na zlepšovanie. Navyše bolo kultúrne prepojené so slovami: * Sensai, majster bojových umení, učiteľ, * a slovom Kaizen značujúceho filozofiu kontinuálneho zlepšovania a zvyšovania efektivity. V Japonsku sa sensai zameriava na kontinuálny osobný rozvoj seba samého. Svojim rastom vytvára predpoklady pre rast aj svojho okolia. Prekvapujúce, že? Presne takéto porozumenie roly Scrum Master si predstavujem ako majiteľ firmy. Práve táto filozofia kontinuálneho zlepšovania je dôvod, prečo platiť Scrum Mastra. Prečo inak platiť Scrum Mastra? Rozumiem, že je to provokačná otázka. Za čo by ma mala platiť firma? Dajme si ale ruku na srdce. Skutočne by sme ako Scrum Mastri mali byť platení za vedenie dailies? Za facilitáciu? Vedenie inžinierov a magistrov? Ľudí, ktorí vedia porozumieť komplexné technológie, no potrebujú „mamičku“ pre daily standup a aktualizáciu tabule? Pracovné inzeráty roly Scrum Master Ne-porozumenie tejto roly vedie firmy aj k nesprávne napísaným ponukám. Z metodického pohľadu. Ale možno nie až tak zle z pohľadu organizačného. Každá organizácia potrebuje riešiť aj bežný pracovný chod organizácie. A často sa s tým spája aj adaptácia realite a potrebám. Ktoré však zarámujú človeka v roli Scrum Master do pozície niekedy aj v rozpore so správnou kultúrou agilnej organizácie. Na nasledujúcom obrázku sme si dovolili vynačiť zelenou farbou vyjadrenia v súlade so správnym nastavením Agile a bielou farbou vyjadrenia, ktoré môžu byť, alebo sú v rozpore s agile kultúrou. Prvá pracovná ponuka je iba v dvoch prípadoch zameraná na správne nastavenie roly. Zvyšné časti dokonca popisujú zodpovednosti, ktoré viac patria iným rolám. Scrum Master v tejto pozícii bude v skutončosti venovať Scrum Master roly iba veľmi obmedzenú kapacitu a úsilie. Organizácia bude viac potrebovať pomôcť v iných rolách. NIektoré zodpovednosti by dokonca Scrum Master ani nemal robiť. Druhá ponuka je už na tom lepšie. Je zameraná na „fyziku“ Scrum, na ceremónie a aktivity Scrum Master roly. V tomto prípade bude Scrum Master robiť Scrum Mastra tímu. ORganizácia však podľa popisu nepotrebuje, resp. nevyjadruje potrebu, kontinuálneho zlepšovania organizácie. Tím je dostatočnou potrebou. Tretia ponuka pridáva aj organizačnú perspektívu, ale stále viac z aspektov „fyziky“ tejto roly. Štrvtá ponuka hľadá človeka, ktorý chápe aj „chémiu“ zmeny organizácie. Tím nie je až taký kľúčový. Samozrejme je ešte stále v hľadáčiku tejto roly, ale v skutočnosti je tím vnímaný ako časť organizácie, ktorá je oveľa podstatnejšia. Čo z toho vyplýva? Scrum Master v dnešnej dobe sa musí zamerať na organizáciu a jej kontinuálnu zmenu. Scrum Master 2023+ je agentom kontinuálych zmien organizácie. Buďte v strehu * Tím, tím, tím, tím * Mix roly Scrum Master a iných rolí * Zastupovanie Produktového vlastníka * Manažment požiadaviek * Projektový manažment * Koordinácia závislostí * Kontaktná osoba všetkej komunikácie * Rozpočet, čas, kvalita * Zdroje a kapacity * Postupy, štandardy * Delivery * Agile, agile, agile, agile, agile, agile, agile Správne zameranie roly * Rola na 100% * Tok hodnoty * Systém * Organizácia * Biznisová agilita * Kultúra a mindset * Ľudia a spolupráca * Odstraňovanie zbytočností * Root cause analýzy * Zavádzanie zmien * Metriky * Facilitácia * Vzdelávanie, mentoring a koučing * Prepájanie s inými praktikami Správne nastavená rola sa zameria na kontinuálne zlepšovanie vďaka kontinuálnemu zvyšovaniu transparentnosti vo všetkých aspektoch fungovania organizácie. Viac sa môžete dozvedieť o webinári o transparentnosti (https://scrum.sk/blog/2023/11/17/webinar-transparentnost-v-agile/). Prvou a najdôležitejšou otázkou Scrum Mastra je: „Ako lepšie?“ Začnite každé ráno správnou otázkou Táto otázka pomáha Scrum Mastrovi s jej, jeho, osobným a profesionálnym vývojom. Vývoj začína na stupni Majster, ktorý vidí viditeľné a je skvelým ‚remeselníkom‘ často navigujúcim tím. Pokračuje stupňom Master, v ktorom už hľadá aj neviditeľné a viac vedie tím otázkami, nielen návodmi. Posledný stupeň Maestro už rozumie podstatu Agile a zmysluplný spôsob jeho aplikácie v organizácii. Maestro vidí neviditeľné, hľadá medzery medzi lístočkami na Kanban tabuli. Hľadá priestor pre optimalizáciu procesov. Chápe, že neviditeľné poskytuje viac príležitostí pre optimalizáciu efektivity a produktivity. Stáva sa učiteľom, sensaiom, organizácie. Našim zámerom nie je definovať nové roly. Našim zámerom je zmapovať fungovanie a správanie sa Scrum Mastra na jednotlivých stupňoch rozvoja. Úroveň Scrum Majster Cieľom osoby na úrovni Scrum Majster je formovanie tímu a usadenie ceremónií tímu. Scrum Majster často prejavuje tieto aktivity a používa slovník: * Aktívne vedie * Denné standupy * Kanban tabuľa * JIRA * Ceremónie * Retrospektíva * Rieši konflikty * Sleduje závislosti * Vykazovanie ako nutnosť * Burn Down graf, Velocity Od Scrum Majstra budete často počuť navádzanie, príkazy, žiadosti. Budete počuť výzvy pre aktualizáciu Kanban tabule, slová ako Storypointy, BUrn DOwn graf, velocita, kapacita. Žiada aktualizáciu tabule, alebo ju dokonca sám robí. Sťažuje sa na nedostatočnú podporu manažmentom, na rezistenicu tímu. Už len napr. kamery si nechcú zapnúť. RIeši nepodstané veci ako napr. Wifi pripojenie. A to všetko s veľkým seabzdaosťučinením a sebaspokojnosťou. Veď predsa pomáha tímu. Mimichodom, každý si touto fázou prejde. Je to uspokojujúca fáza, ktorá hladká ego Scrum Mastra. Je užitočnou, užitočným. Ale preto by som Scrum Mastra osobne neplatil. Úroveň Scrum Master Cieľom Scrum Mastra je vybudovať samostatný a výkonný tím. Ak sa to podarí, Scrum Master nie je potrebný. Scrum Master sa zvyčajne stará o: * Transparentnosť * Samoorganizácia * Facilitácia konfliktov * Riadenie cez spätnú väzbu * Strednodobé plánovanie a kontinuálna príprava * Celofiremná retrospektíva * Riešenie konfliktov * Odstraňuje závislosti * Vykazovanie ako zdroj metrík pre adaptáciu * Odhadovanie s referenciami * Zjednodušovanie nástrojov * Mapovanie toku s pomocou Cumulative Flow, Control Chart Scrum Master kladie múdre otázky. Zaujím sa kontinuálne o to, čo môže byť lepšie. Pýta sa s čím môže pomôcť tímu a organizácii. Pýta sa na zabudnuté, neviditeľné. Pýta sa ľudí čo si neuvedomili. POmáha nájsť šandardy firmy. Dobrý Scrum Master je jednou nohou na vyhodenie. Iba vtedy poskytuje tímu a organizácii výzvy. Úroveň Scrum Maestro Cieľom Scrum Maestro je optimálny tok a firemná kultúra založená na agilných hodnotách a princípoch. Aktivity Scrum Maestro pokrývajú: * Kultúra firmy * Firemné ciele * Dlhodobá a strednodobá perspektíva * Soft perspektívy v tímoch * Rozvoj ľudí s podporu HR * Transparentnosť neviditeľného * Vyvoláva konštruktívne konflikty v tímoch * Kontinuálna identifikácia zbytočností * Analýzy príčin a následkov * Optimalizácia systému práce * Nedovoľuje závislosti * Zefektívňovanie systému s líniovým manažmentom * Zjednodušovanie nástrojov * Edukácia zákazníkov o agilnom prístupe * Metriky Vzhľadom na témy je Scrum Maestro pravou rukou exekutívy organizácie. Pomáha exekutíve a seniórnemu manažmentu vidieť obmedzenia, ktoré organizácia má prekonať, aby bola schopná efektívnejšie dodať hodnotu. Scrum Maestro vyzýva na uvedomenie si čo chceme dosiahnuť. PRečo práve to potrebujeme? ako budeme vedieť, že sme to dosiahli. Pýta sa čo potrebujeme zmeniť. Čo obmedzuje organizáciu v dosiahnutí danej vízie a stratégie. Pomáha firme nájsť koreňové príčiny problémov a spôsoby ich odstránenia. Záver V závere tohto blog postu nám ostáva poďakovať za vašu trpezlivosť a čas strávený na spoločnej ceste objavovania sveta Scrum Mastera a jeho neustáleho vývoja. Ako sme spomínali na začiatku, rola Scrum Mastera je dynamická a vyžaduje si neustálu sebareflexiu a rast. V článku sme sa zamerali na význam slova „Master“ a jeho odzrkadlenie v aplikácii Scrum Mastera. Dôležité je uvedomiť si, že Scrum Master nie je iba „majster“ vedenia tímu a aplikácie Scrum, ale aj „kováč“ neustáleho procesu zlepšovania – človek, ktorý podporuje organizáciu v dosahovaní agility a kontinuálnej transformácii. Rovnako sme sa pozreli na význam jazyka v aplikácii Scrum Mastera, či už v slovenčine, angličtine alebo v japonskom kontexte, kde je Scrum Master vnímaný nielen ako líder tímu, ale aj ako učiteľ a facilitátor kontinuálneho osobného rozvoja. Prispeli sme aj k pohľadu na pracovné inzeráty pre rolu Scrum Mastera, upozorňujúc na nezrozumiteľné očakávania a nesprávne zameranie, ktoré môže viesť k nedorozumeniam v rolách a zodpovednostiach. Na záver sme sa ponorili do troch úrovní Scrum Mastera – Majster, Master a Maestro. Každá úroveň predstavuje iný štádium vývoja a zameriava sa na rôzne aspekty, od vedenia tímu až po formovanie firemnej kultúry založenej na agilných hodnotách. Pochopte a zmerajte svoje potenciály v roli Scurm Master (https://scrum.sk/scrum-master/scrum-master-hodnotenie/) Ako vynikajúci Scrum Master je táto dynamika a sebareflexia stále v jeho každodennom živote. Pretože iba týmto spôsobom môže byť skutočne účinným agentom kontinuálnych zmien v organizácii. Buďte v strehu, pýtajte sa správnych otázok a neustále sa rozvíjajte – to sú kľúče k úspechu v roli Scrum Mastera v dnešnom agilnom prostredí. P.S. Článok a prezentácia vznikla v spolupráci s Lenkou Kocúrekovou. Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

6. 

   16 Feb 2025

   #1: Transparentnosť v Agile

   Prečo o transparentnosti Transparentnosť sa v súvislosti s Agile veľmi spomína ako absolútny základ tohto spôsobu fungovania v tíme. Transparentnosť totiž podnecuje kontinuálne zlepšovanie. Práve to potrebujeme pre vybudovanie schopnosti priebežne tvoriť a dodávať produkty v prostredí neustálych zmien. Dnešný svet je komplexný. Nevieme čo nevieme. Plánovanie je v takomto type prostredia aktivita, do ktorej sa neoplatí investovať veľa úsilia. Jednoducho, kým si tieto aktivity naplánujeme, svet a realita sa zmení. Preto dlhodobé plánovanie vedie iba k zbytočnostiam. Komplexnosť nás zároveň privádza k faktu, že dnes je veľmi náročné budovať produkty s tak komplexnými technológiami a náročnými biznisovými požiadavkami bez zapojenia viacerých rolí, schopností a znalostí. Táto rôznorodosť a závislosti si vyžaduje práve transparentnosť. Práve transparentnosť umožňuje vidieť a zbadať. Keď zbadáme, umožní pochopiť, rozobrať, analyzovať. A následne spraviť zmenu, adaptovať sa. Takáto zmena nás (zákazníka, firmu, tím) privedie k novému status quo. A môžeme začať opäť. Vybrať si ďalší problém. Tento webinár začína tým, že v posledných rokoch stretávame veľmi veľa ľudí, u ktorých pozorujeme, že Agile je nejako pochopené a nejako implementované a vyvoláva aj pachuť. Trochu nás to povzbudzuje v tom, aby sme tento stav napravili, aby sme sa povenovali základom, ktoré sú často vnímané iba povrchne. Čo to je ‚transparentne‘? Nad transparentnosť je potrebné sa zamyslieť. Čo to pre nás v tíme znamená? Máme na význam slova transparentnosť rovnaký názor? Pred niekoľkými týždňami počas workshopu sme získali od dvadsiatich účastníkov viac než dvadsať významov slova. A pritom sa ani jeden význam neopakoval. Dobre nastavené Agile začína od podlahy. Od hodnôt. Transparentná Kanban tabuľa Agile začína od hodnôt. Po prvotnom zladení očakávaní a identifikácii dôvodov „prečo potrebujeme transparentnosť„. Samozrejme, Kanban tabuľa sama o sebe výrazne zvyšuje transparentnosť. To komunikuje absolútna väčšina ľudí fungujúcich agilne. Čo sa však potrebujeme dozvedieť? Čo na nej potrebujeme vidieť? Čo nie je teraz viditeľné? Práve táto otázka umožní pochopiť skutočne zmysluplný prístup k Agile. Agile je o neustálom odstraňovaní zbytočností. A teda o kontinuálnom zlepšovaní. Máme na tabuli veľa kartičiek? Je vašou tendenciou ich tam radšej ani nepísať, pretože agilne pre vás znamená byrokraciu? Chyba! Veľa kariet máte pretože máte skutočne veľa práce. Priznajte si to a radšej sa zamyslite aké úlohy skutočne potrebujete a dokážete dokončiť. Zvyšné na tabuľu dáte neskôr keď prídu na rad. Potrebujeme vidieť, či sme nezabudli na testy? Alebo na Code review? Alebo na deploy? Použijeme farby podľa typu úlohy. Dodržíme tak konzistenciu v našom spôsobe implementácie. Identifikujeme zabudnuté odhady. Spresníme tak sľuby. A zároveň vytvoríme štandardy a pravidlá ako pracujeme. Tabuľu nemáte kvôli Agile, Scrum, alebo Scrum Mastrovi. Potrebujete ju kvôli sebe, drahé tímy. Transparentný produktový backlog Aj produktový backlog sa dá viac stransparentniť. Použite farby napr. podľa: * Typ požiadavky * Typ úlohy, aktivity * Hodnota * Riziko * Platená, neplatená * Interná * Zákazník, Persona * Projekt V osobných workshopoch sa neobávajte použiť aj napr. karty rôznej veľkosti, alebo tvarov. V lepších elektronických nástrojoch (https://www.scrumdesk.com/) sa dá takisto použiť farba. Hierarchia Typický backlog má niekoľko stoviek ba možno aj tisíc položiek, požiadaviek. A aj to typicky na rok. Najtypickejšou chybou je slabá organizácia práve produktového backlogu. Hierarchia požiadaviek umožní zlepšiť prehľad a orientáciu v požiadavkách. Umožní zároveň oddeliť zodpovednosti rolí. Napr. biznis sa môže starať o Features zatiaľ čo Produktový vlastník o User Stories. Alebo aj inak. Hierarchiu začnite tým, že odstránite z produktového backlogu staré položky. Dokonca staršie než tri mesiace. S hierarchiou to ale netreba preháňať. Menej je viac. Veľmi hlboká hierarchia vedie k Features, ktoré majú málo User Stories. A namiesto toho veľa Features. Ale neexistuje presná odpoveď ako to má byť správne. Vyskúšajte, preskúmajte ako to funguje, adaptujte. V hierarchii by nemala byť odpoveď na otázku Ako. Pozor aj na vynútenú hierarchiu len kvôli predpísaným firemným pravidlám. Pre zvýšenie transparentnosti použite User Story Mapu. A neobávajte sa ju spraviť spolu s vašimi zákazníkmi, stakeholdermi. Veď prečo im neukázať ako transparentne potrebujete zadania práve vy? Popis požiadavky Najčastejšia chyba v agilných tímoch „Príliš veľká ‚transparentnosť‘ v detaile požiadaviek. Ako prvé odstráňte optický šum. Viac detailov neznamená lepšie. Skutočne. Na nasledujúcom obrázku je user story popísaná v dokumente. Aj to je chybou, ale teraz nás to nemusí zaujímať. Zvýraznený zelený text označuje časti požiadavky, user story, ktoré používateľ potrebuje doplniť do funkcionality. Áno, iba niekoľko riadkov. A pritom celý dokument má 9 strán. popisujúcich aktuálny stav. Vraj to treba? Nie, aktuálny stav sa kedykoľvek v agilnom prístupe môže zmeniť. Stačí preplánovať požiadavky a čas poznačí aktuálnosť aktuálneho popisu. Pohľad na produktový backlog z diaľky poskytne produktovým vlastníkom pochopenie, ktoré z features sú veľké. Tie majú dlhé stĺpce na mape požiadaviek. Aj takýto transparentný pohľad na produktový backlog vám napovie kde máte zbytočnosti. Transparentný systém Skutočný Scrum Master je System Maestro. Nestará sa o stand-up, stará sa o celý systém, v ktorom sa požiadavky zbierajú a realizujú. Skutočne agilná firma má popísaný a transparentný tok hodnoty. Value stream mapping je nielen nakreslený, ale práve ten je analyzovaný, sú identifikované jeho obmedzenia a tok je kontinuálne prispôsobovaný. V preklad, proces od A-Z sa kontinuálne skúma a zlepšuje. A pracujú na tom Scrum Mastri a manažment. Áno, transparentnosť sa týka aj manažmentu. Pri analýzach obmedzení natrafíte určite na problémy. No netešme sa prirýchlo, že sme našli problém. Zväčša ide iba o indíciu problému. Skutočná príčina problému leži hlbšie. Koreňová príčina je nájdená po sebareflexii napr. s použitím techniky Five Why. A týmto to nekončí. Transparentná firma funguje na spätnej väzbe. A spätnú väzbu neočakáva iba v kvalitatívnej forme, ale predovšetkým v kvantitatívnej forme. Firma má možnosť zmysluplne sa zlepšovať kontinuálne pomocou metrík, ktoré sa nielen zbierajú a generujú, ale predovšetkým používajú pre zlepšenie. Príkladom takej systémovej metriky je Cumulative Flow Chart, ktorý pomáha pochopiť nielen čas dodávky, ale aj zmeny vo vyťažení komponentov práce. Transparentne o sebe a o nás Túto úroveň transparentnosti spomíname ako poslednú, no v skutočnosti by ste s ňou mali začať. Pretože Agile je o úzkej spolupráci. Sebapoznanie môžete začať osobnými aj tímovými hodnotami. Pokračovať môžete víziu a misiou tímu. Osobnou mapou, ktorá vás transparentne predstaví kolegom. Až potom sa zamerajte na znalosti a skúsenosti. A ak nájdete seba-odvahu, možno si vyskúšate aj osobnostné, tímové testy, alebo aj napr. hodnotenie Scrum Mastra (https://scrum.sk/scrum-master/scrum-master-hodnotenie/), alebo Hodnotenie Produktového vlastníka (https://scrum.sk/product-owner/hodnotenie-product-owner/). Nad čím sa zamyslieť? * Čo sa chcem dozvedieť? * Vymažte staré * Odstráňte šum * Zviditeľnite dôležité * Hodnoty, vízia, ciele, pravidlá * Adaptujte systém práce Dobrá úroveň transparentnosti vám dovolí zbadať keď sa pozriete. Dobrá transparentnosť vám pomôže dosiahnuť dôveru v tíme, ale aj s manažmentom a zákazníkmi. Neobávajte sa investície do transparentnosti pre rýchlejšie výsledky. Get full access to ScrumDesk, Meaningfully at scrumdesk.substack.com/subscribe (https://scrumdesk.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)

Contact Let's galvanise organizations Podcast

Guest appearances

Books guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.