Proč jsem si knihu vybral?
Po knížce jsem sáhnul, protože jsme se rozhodli v projektu Fluego vyzkoušet více agilní přístup a jeho nástroje. Do čtení jsem šel s tím, že jsem slyšel pojem sprint, a že v agilním prostředí se pracuje nějak v týmech a to je tak celé.
Poznámky z knížky
Na začátek si musím odpovědět na základní otázku: Proč přecházet do agility? Moje odpověď byla původně, protože je to nové a rychlejší. Kniha se této otázce taky věnuje a dává jí mnohem lepší a více odůvodněnou odpověď. Agilita je atraktivní, protože celý svět je více VUCA.
Přechodem do agility se přizpůsobujeme tomuto nastavení světa okolo nás a můžeme na něj lépe reagovat. Musíme se naučit s novými nástroji abychom se mohli měnit. Agilní totiž znamená přizpůsobivý a adaptivní.
První myšlenka, která trochu změnila můj pohled na celý přerod je ta, že obecné použití agility neexistuje. Jde spíše o nastavení kultury firmy a každá firma (v mém případě projekt Fluego) využívá agilní metody, které si sám vytváří a upravuje. A hlavně ne vše je vhodné řešit agilně. K tomu nám pomůže CYNEFIN framework (čte se /:kynevin:/).
Na něco je vhodné použít procesy (jednoduché), na něco projekt (komplikované) a na něco být agilní. Záleží jaký typ problému / potřeby řešíme.
Lean
Agilní přístup vychází z něčeho co se jmenuje lean a zjistil jsem, že minimálně o to se tu snažíme. Obecně se snaží o zeštíhlování - dělat jen to, co zákazník je zákazník ochoten zaplatit, hledá hodnotu, v kultuře stojí na samořídících se týmech, ve kterých jsou jednotlivci respektováni a mají svůj hlas a hlavně neustálé zlepšování.
5 kroků Lean
Tento postup bych rád použil na konkrétní problém, který budeme řešit ve Fluegu.
Tři prvky motivace 3.0
Dnes abychom uspěli jak v týmu tak sami, potřebujeme “drive” a ten ovlivňují tyto tři prvky.
Sám se snažím tyto tři prvky u sebe mít. Myslím si, že první dva prvky mám a používám již pravidelně. U toho třetího je to někdy. Všechny části této motivace u sebe ale vidím a cíleně je rozvíjím například u snahy vytvořit Tiimi bard (jakousi kmenovou radu našeho programu). Skrz to mám touhu řídit své vlastní fungování, sám chci být lepší v organizaci a vedení lidí a má to přesah do rozvoje unikátního vzdělávacího programu, který má obrovský potenciál.
Nenosme lidi k práci ale práci k lidem. Každý dobrý tým si poradí s celou škálou různých problémů. Tato myšlenka mě velmi zaujala, protože něco podobného děláme na BG - dostaneme zadání a v krátkém časovém úseku se musí tento omezený tým poprat s činnostmi, které jim nemusí být například úplně přirozené.
Dělení organizací Red až Teal
(Toto si tu jen odkládám pro budoucí znalosti, nevím jak zakomponovat ATP aniž bychom překopávali celou strukturu týmu, projektu či komunity. Myslím, že se GimiTimi nachází někde okolo zelené organizace.)
Poznámka k tyrkysovým organizacím - deleguje se tam bottom up = problémy se předávají nahoru a ne zadávají dolů. Základem pro fungování takové organizace jsou schopní lidé.
Veškeré nutné věci a činnosti by měli být transparentní a navzájem ve vazbách napojené a pak už je jedno jaký “agilní” nástroj použijeme, např.: backlog, road map, , story map…
Agilní nástroje a metody co jsem zkusil nebo chci zkusit
Product backlog je adresář položek, které je třeba udělat k naplnění cíle vývoje. Každá z takových položek musí dodávat hodnotu pro zákazníka, jinak tam nemá co dělat. Každá PBI (product backlog item) by měl obsahovat:
Product backlog jsme si narychlo vytvářeli i u nás ve Fluegu. Myslím, že to může fungovat dobře, ale je nutné aby byl projekt / vývoj většího rozsahu než u nás pouze na krátké valentýnské focení. Teprve pak se dá plně využít potenciál backlogu a jeho možností popisu položek.
Scrum. Místo, kde se vyvíjí daný produkt a snaží se dojít k cíli. Scrum má pilíře na kterých staví:
Myslím, že náš projektový tým se s těmito pilíři snaží pracovat, naopak v GimiTimi tyto pilíře pokulhávají (ale taky jsme si neřekli, že budeme pracovat agilně) - hlavně transparentnost mezi projekty.
Hodnoty scrumu
U nás tyto hodnoty si myslím, že fungují, ale nemáme je vyslovené nahlas a myslím, že bychom to udělat měli, hlavně hodnota zaměření je si myslím zásadní, protože (a to je asi problém všech aktivních v TAP) děláme roztroušeně na více věcech zároveň v různých stádech vývoje.
Planning poker
Jednoduchá technika, kdy je potřeba co nejlépe odhadnout časovou náročnost činnosti. Všichni vývojáři si vezmou karty a každý vyloží podle toho, kolik hodin si myslí, že činnost zabere. Ti s nejnižší a nejvyšší vysvětlí proč a pokračuje se dokud se vývojáři neshodnou.
Hrubý průběh sprintu
Kanban
Klasické řazení činností podle jejich stavu - To Do, In Progress, Done. Tyto tři jsou základní, samozřejmě může mít každý tým své vlastní. Skvělé pro přehled v činnostech, co se právě odehrávají a co je potřeba udělat.
ATP
V týmu jsme měli úžasné TS na knihu Sprint, kde jsme si za pár hodin prošli celým sprintovaným cyklem. Uvědomil jsem si, jak důležitý je iterace se zákazníkem a zároveň, že formát agilního vývoje nelze použít na vše. Je to ale skvělý nástroj pro například vývoj webových stránek, nebo nového produkt.
Kanban jsme nějakou dobu používali v aplikaci ClickUp, pro mé kolegy ale bylo toto rozhraní příliš náročné a teď používáme kanban v Miru, ale moc nám nefunguje. Myslím, že bychom na tom měli zapracovat, je to totiž velmi jednoduchá forma, díky které víme kdo na čem dělá.
