Lean | Zuzi's Blog o Agilu a Scrumu

Design Thinking

Nedávno se mě někdo ptal co má společného Agile a Design Thinking, tak se na to pojďme podívat. Takže co to je Design Thinking? Framework pro řešení komplexních problémů. Přišel z oblasti designu a primárně cílil na designové týmy a firmy a návrhy produktů, ale je obecně použitelný nejen na návrh nových hmotných věcí, ale i služeb a obecně všeho, co zákazník požaduje. Vhodný pro rychlé hledání inovativních řešení.

U Design Thinkingu je základem orientace na zákazníka a porozumění jeho potřeb. Nehledáme řešení pro sebe, či jak to vidíme my, ale pro zákazníka. Dalším prvkem je iterativní způsob práce, nejedná se tedy o lineární proces. Definice frameworku se občas nepatrně liší, ale obecně by měla obsahovat v nějaké podobě následující kroky:

Empathise – vcítění se do zákazníka a porozumění jeho potřeba. Bez porozumění toho, co zákazník chce, nemá smysl pokračovat.
Define – když víme, co zákazník chce, měli bychom si problém, který chceme řešit, definovat. Takže popsání problému.
Ideate – hledáme řešení, vlastní „myslící fáze“. Snažíme se najít desítky řešení, je snaha řešení hledat i v iracionální zóně či “out-of-the-box” (např. pohledem dítěte) a snažíme se brainstormovat a najít co nejvíc možností.
Prototype – vyberme několik (doporučuje se do tří) nejsilnějších myšlenek z předchozí fáze a udělejte prototyp.
Test – otestujte prototyp na zákaznících. Ověřte si výsledek své práce.

Jak již bylo zmíněné, proces je iterativní. Z libovolné fáze se můžete vrátit, pokud se ukáže, že nerozumíte potřebám zákazníka. Nejviditelnější je to po testování, ale pokud se ukáže ve fázi Define, že definujete jiný problém, než jste načetli ve fázi Empathise, vraťte se i zde. Fáze se mohou také prolínat.

Implementace Design Thinkingu ale nemusí skončit jen u návrhu nových produktů, pokud se aplikuje dovnitř organizace, může pomoci nastartovat organizační změnu a změnu firemní kultury. Cílem je kolaborativní forma spolupráce a orientace na zákazníka. Můžeme pak hovořit o design-thinking orientované společnosti. A pár příkladů společností, které Design Thinking používají: Nike, Apple, IBM, GE, Samsung.

Takže zpět k úvodní otázce. Co má společného Agile a Design Thinking? Řekla bych že mindset a filosofii. Design Thinking je totiž Agilní metoda. Takže nepřináší nic převratně nového, o čem bychom v Agilní komunitě nevěděli. To ale neznamená, že by se na některé typy problémů nehodil, ba právě naopak. Zařadila bych ho do kategorie šikovných nástrojů jako je Lean Startup, Impact Mapping a podobně.

Jaké to je když vám vyjde kniha

První pocit? Překvapení. Přijde tlustý balíček se třemi autorskými výtisky. Jen tak, z ničeho nic. Jeeeee už je to tady! Ta je pěkná 🙂 a pak se vám začne honit hlavou, jak to celé bylo. Já v podstatě knihu psala v nejrůznějších koutech světa. Doma prostě nebyl čas se zastavit a přemýšlet. Proto tak ráda cestuju. Je to osvěžující. Kde to celé začalo? Já myslím, že v Indii. Seděli jsme u bazénu při konferenci a říkali si, že by bylo fajn napsat knihu. A vymysleli osnovu. A pak osnova pak dlouho ležela u ledu… A pak jsme začali pomalu psát. Kousek po kousku. Ale jak říkám doma mi to moc nešlo. Psát knihu je děsně práce. Trvá to nekonečně dlouho. Pořád to není hotové.

A tak jsem se rozhodla s tím pohnout a první rozumně velký kus jsem napsala v Indonésii. Bangka Island. Každý den po odpoledním ponoru, až do večeře. Jsou tam úžasné soft korály. Jedny z nejhezčích na světě. To je stejně můj sen, pracovat někde pod palmičkou. Pak bylo po dovolené. Pak další části vznikaly v letadlech a při čekání na letištích do Kalifornie – v San Fransicsu je úžasně, taky je tam moře. Pak cestou do Kieva, Rigy, Barcelony, Talinu, Kodaně, Krakova, Moskvy, New Yorku, v Las Vegas – nic jsem v casinech nevyhrála. Škoda, pár miliónů by se mi ke splnění snu sedět pod palmičku hodilo.

Další velký kus jsem napsala na Filipínách. Zase potápění. Odpolední dvě hodinky po ponorech na Moalboalu, pak v thajské restauraci na pláži v Boholu a finální části v Coronu, kde mají Japonské vraky plné podmořského života. Nádhera. Ale pořád to tak nějak nebylo hotové. Už mi to začínalo vadit, nemám ráda dlouho nekonečnou práci… a tak jsem poslední kusy dopsala ve Vietnamu v Saigonu nebo Ho Chi Minh City chcete-li. Hodina taxíkem do práce, hodina zpět do hotelu. Tam jsem ve finále četla i celou knihu ještě jednou v rámci finálního review. To si teprve uvědomíte, kolik jste toho napsali. To už bylo povzbudivé. Skoro hotovo. A jsem moc ráda, že jsem na knihu nebyla sama. Vždycky je daleko větší zábava s někým spolupracovat.

A pak nastal ten největší problém, kde sehnat vydavatele. Nakonec to šlo celkem snadno. A tak děkujeme nakladatelství Computer Press za vydání naší knihy “Agilní metody řízení projektů“ a doufáme, že se vám bude líbit. Co se dočtete?

„Snažili jsme se čtivou formou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na Agilní metody mohou potkat. Kniha nepopisuje jen teorii, co to Agilní metody jsou, jak funguje Scrum Proces a Kanban, a jak by jednotlivé artefakty těchto procesů měly správně vypadat, ale primárně se snaží vysvětlit filozofii Agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení co dělat a čeho se naopak vyvarovat.

Kniha se zabývá Agilními metodikami vývoje software v různých typech společností, od malých firem až po nadnárodní korporace. V první části knihy jsou popsány základní stavební prvky Agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Čtenář se dozví všechny potřebné informace k adopci Agilních metodik, kulturní odlišnosti Agilních firem a další základní stavební kameny nutné pro úspěšnou adopci Agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky vyskytují v Agilně řízených firmách. Vedle těchto popisů obsahuje kniha i “kuchařky”, resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy firem.“

Dejte nám prosím vědět, jak se vám kniha líbila, co vás zaujalo, nebo co byste viděli příště raději jinak. Hezké čtení. Naší knihu Agilní metody řízení projektů můžete získat zde.

Jak se liší Agilní a Lean přístupy od klasických metod?

Našla jsem o tom krásny článek. Článek popisuje na jednoduchém příběhu ze života pacienta, jak funguje klasický proces, kde plánujeme věci tak abychom zajistili stoprocentní efektivitu zdrojů. A jak se takový proces liší, když se na celý proces se díváme z pohledu zákazníka a optimalizujeme ho tak, aby měl nejkratší průchod systémem. Zajímavé je, proč je to plánování zdrojů ve firmách tak oblíbené. A proč si spousta lidí myslí, že plánovat zdroje na několik měsíců až rok dopředu je efektivní. Jestli v takové firmě pracujete, ukažte jim tento příklad.

V Agilním světě jsme flexibilní. Plán můžeme kdykoli změnit. Necháváme tým aby si sám vybral a domluvil se, kdo na čem bude pracovat tak, aby zákazník dostal co nejrychleji, co potřebuje. Efektivita využití “zdrojů“ přijde sama. A ještě jedna změna je v agilním světě patrná. Nedíváme se na lidi jako na zdroje. Jsou to kreativní jedinci, co se jsou sami schopni rozhodnout a nést za svá rozhodnutí zodpovědnost.

Ostatně podívejte se a posiďte sami. Lean LEGO – The red brick cancer, Håkan Forss

Na závěr vám dám pár otázek. V které nemocnici byste se raději nechali léčit? Které nemocnici se blíží vaše firma?

Kanban

Poslední dobou se stále častěji v diskusích objevuje Lean software development a Kanban. Problém s Kanbanem je, že Kanban vám v podstatě nic nenařizuje. Všechno si můžeme sami zvolit, sami rozhodnout. Tedy skoro všechno. Stačí dodržet tři principy:

– omezit rozpracovanou práci – work in progress
– minimalizovat čas průchodu – lead time
– vizualizovat progress

Tedy aplikováno na sw vývoj – udělejte si hodně přehlednou tabuli, připravte kartičky s jednotlivými úkoly, rozdělte proces na jednotlivé fáze – pro začátek stačí “Backlog / In progress / Done” a omezte, kolik lístečků může být najednou v jednotlivých sloupcích. Když už kvůli limitu nemůžete přidat další lístek, musíte nejprve dokončit některý z rozpracovaných. Zdá se to být snadné, ale ne tak úplně. Např. stanovování limitů front je poměrně věda.

Kanban sám o sobě není proces, proces z něj teprve musíte udělat vy. Je to trochu náročnější než u Scrumu, který vás hodně při implementaci vede, ale zase na druhou stranu, ve Scrumu či XP se můžete inspirovat. V úspěšných implementacích to nikdy nebude jen Kanban, vždy to bude Kanban a něco k tomu.

Lean metody ve vývoji softwaru

Je to takový pěkný buzzword. Lean firma. Spousty velkých firem Lean principy implementuje, obvykle bez většího porozumění jejími zaměstnanci. Často to končí tím, že si udělají nějaké lístečky a jsou dostatečně Lean, tedy štíhlí. Jenže na to aby to přineslo nějaké výsledky, je stejně jako u agilních metod třeba porozumět filozofii. A ne jen slepě vykonávat nějaké rituály. O co tedy jde? Jednoduše řečeno o omezení práce na tom, co by nemuselo přinášet hodnotu a tedy v konečném důsledku mohlo přijít nazmar.

Nejznámější Lean firma je určitě Toyota. Tam vyvinuli proces řízení výroby, odlišný od běžných procesů kdy vyrábíme kdykoli a cokoli na sklad. Řídí výrobu systémem tahu, kde vyrábíme příslušný díl, až když je potřeba.

Jak takový princip použít ve firmách kdy žádné fyzické díly nevyrábíme? Tak se třeba podívejme na standardní vývojový proces – waterfall. Nejprve uděláme na sklad analýzu, pak kód, a pak testy. A čekáme, že to je tak v pořádku a že všechny díly jsou kvalitní (tedy že design už se nezmění, v kódu se nenajde chyba, a že zákazník to tak opravdu chce). A stejně jako ve výrobě se nám děje, že jednotlivé věci musíme předělat, opravit, zahodit. Někdy i celou krabici dílů se stejnou chybou (někdy i celou rozsáhlou funkcionalitu).

Jak na to? V kostce, omezte ‘work in progress‘ a soustřeďte se na to, abyste jednotlivé požadavky protlačili systémem co nejrychleji. Implementujte systém tahu a nezačínejte s analýzou, dokud nemáte prioritní požadavek od zákazníka. A dokud nemáte zpětnou vazbu, že předchozí požadavek byl akceptován.

A aby to bylo více uchopitelné, Lean Software Development je založen na následujících principech:

Odstraňte vše, co nepřináší hodnotu – tedy zbavte se odpadu. Pracovat na něčem co se ve finále vyhodí je škoda času, když se vám podaří tento čas investovat do věcí, co mají smysl, budete jistě efektivnější.

Zlepšujte se a učte se již v průběhu – když jen slepě vykonáváte předpisy a sledujete procesy, může se stát, že stejnou chybu opakujete pořád dokola a ‘odpad’ se vám tedy na konci projektu nahromadí víc, než byste si přáli. Pravidelná zpětná vazba vám pomůže se soustředit jen na to, na čem záleží.

Rozhodujte se co nejpozději – čím později rozhodnutí padne, tím více máte informací. Takže jsme zase zpět u myšlenky, že nemá smysl vyrábět zásoby na sklad jen proto, že zrovna máte volnou linku nebo programátory.

Dodávejte práci, jak nejrychleji to jde – čím dříve něco dokončíte, tím dříve dostanete zpětnou vazbu, kterou můžete hned v další iteraci zohlednit.

Dejte týmu důvěru a zodpovědnost – a budete mít mnohem motivovanější tým, než když se budete držet tradičních top-down struktur.

Zaměřte se na celkový dojem – produkt není jen software. Dbejte na kvalitu a celkovou udržitelnost systému, nevytvářejte technický dluh.

Zaměřte se na celkový výsledek – jednotlivé chyby a selhání nejsou podstatné, pakliže se z nich poučíte. “Think big, act small, fail fast; learn rapidly” – tedy Přemýšlejte dopředu, začněte u malých věcí, ty vyhodnoťte a rychle se z nich poučte. Jen tak zajistíte, že výsledný produkt bude úspěšný.

Metoda, která vám radí jak na to je Kanban. Ale o tom zase příště.