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 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
