Tag: Scrum

Na které věci můžete v Agilním prostředí zapomenout

Specifikace

Specifikace v takovém tom klasickém slova smyslu je mrtvá. Agilní prostředí se daleko více zajímá o to co je to minimum, které musíme implementovat abychom dodali maximum business value, než co všechno musíme naimplementovat abychom se do nějaké té business hodnoty trefili. Jak říkal jeden můj známý ScrumMaster, klasické organizace často se zavázanýma očima střílí na kachny. A protože střílí hodně, občas nějakou trefí. Agilní organizace pochopily, že méně je někdy více, a přestali trávit hodiny času specifikací toho co všechno bychom taky mohli udělat. Na místo toho se v rámci Inspect and Adapt principu a časté zpětné vazby snaží pochopit co přináší nejvyšší business hodnotu a na tu se soustředí. Ano, je to změna, a bude to těžké, ale o tom Agile právě je.

Častým nepochopením je že organizace mají pocit, že v rámci UserStory musí psát detailní popis, jak danou potřebu adresovat například formou Akceptačních kritérií. To ale vůbec nepatří do UserStory. Ta by měla pouze definovat potřebu konkrétního uživatele/persony, ‘jak’ji budeme řešit je na dohodě týmu v rámci Sprintu. Ano, pre-rekvizitou je pochopení toho co děláme celým týmem, tedy dobrý Product Owner a Backlog Refinement. Jinak vám ale Scrum ani Agile fungovat nebude. Agile i Scrum je customer centric, business driven. Takže zapomeňte na specifikaci, zkuste se zcítit do zákazníků a pochopte jejich potřeby. Jen tak dosáhnete lepších výsledků.

Projekty

Další věcí, která se dříve či později octne na smetišti dějin, jsou projekty. Stejně jako role project managera. Ale o tom třeba zase příště. Projekt je totiž jen kontejner, v jehož rámci řídíme a zpracováváme práci v klasickém světě. V agilním světě nám stejnou službu dělá Product Backlog, jeho položky a krátké Sprinty/iterace se zpětnou vazbou. Product Backlog je navíc daleko lépe optimalizovaný na vysokou adaptivnost systému, reakce na změny a obecně práci v komplexním prostředí. A tak důležitost světa produktů postupně uvadá. Že jste projektovými managery? Určitě se pro vás najde uplatnění. Project manageři se nejčastěji stávají stakeholdery, kteří pomáhají týmům pochopit kontext zákazníků, častá bývá i změna na Product Ownera, výjimečně ScrumMastera. Většinou platí, že když jste byli potřeba v předchozí neagilní struktuře, budete potřeba i v té nové. Jen vaše role a práce se změní. Ale to platí nejen pro projektové managery, ale i developery, testery, analytiky, a managery. V agilním světě je všechno jinak a jednoduchý mapping neexistuje. Agile je změna mindsetu, a ta začíná ve vaší hlavě. 🙂

Tribe firmu agilní neudělá

Všechny české organizace asi v poslední době napadl virus ‘fake Agile & Scrum’. Jak se virus pozná? Přesvědčil jinak docela rozumně uvažující organizace, že když department přejmenují na tribe, bude všechno lepší. Inspiraci jde asi hledat ve Spotify (která se sama svým “modelem“, co nikdy model nebyl, neřídí), nebo v holandské ING, která terminologii v rámci své transformace použila a znovu zpropagovala. Obě zmiňované case-study mají jedno společné. Obě organizace prošly zásadní transformací hodnot, přístupu, kultury. Ti, co je slepě aplikují však nejdou cestou změny mindsetu, ale přelabelováním existujícího. Nové šaty ale člověka samy o sobě nezmění. A tak tyto organizace docela bolestivě failují. Jedna nejmenovaná korporace, co přešla na ‘Spotify model’ po roce musela v podstatě zahodit všechno co udělala a vrátit se v produktech o rok zpět.

Však ono těm organizacím o žádnou změnu ani nejde. Stejně jako u SAFe se jen snažíme chytře umožnit firmám, aby si odškrtli agile jako ‘done‘, a nemuseli se měnit. SAFe na to jde chytře a generuje tisíce naprosto nesmyslných rolí a názvů jako train, release train engineer a pak jakási ‘kolečka‘, asi od toho vlaku :). Naopak ‘Triby‘ jsou tu pro ty co jsou cool a nějaké vlaky jim přijdou v 21. století trochu nemoderní. Ale vyjde to nastejno. Škoda. Jedna velká americká organizace nedávno začala svou v pořadí třináctou Agilní transformaci. Nojo, fakt. Prý se jim to tentokrát už možná povede. Už pochopili, že Agile není jen o terminologii, ale je to změna myšlení, přístupu, mindsetu. Tak jestli se vás tento virus ‘fake Agile & Scrum’ týká, nesmutněte. Ještě tak 5 pokusů a ono to vyjde. Není to těžké, chce to jen přestat předstírat, že se měnit nemusíte a pohlédnout pravdě do očí :).

Dobrá zpráva je, že v zahraničí už “Spotify model” nefrčí. Když jsem to zmínila na Agile2018 v SanDiegu, všichni se divili proč by to kdo kopíroval. Takže ta dobrá zpráva je, že tato móda přejde, stejně jako móda džínů do zvonu. Občas se vrátí, ale už nikdy to nebude hýbat světem. Takže stačí počkat a možná za pár let budeme opravdu řešit otázky, které jsou strategické a mají smysl. Hodně mě překvapilo kam se konference posunula of roku 2012, kdy jsem tam mluvila naposledy. K lepšímu. Takže když příští rok budete chtít vidět co se opravdu děje v Agilním světě, Agile Alliance Agile 2019 je to správné místo. Jen musíte trochu našetřit do kasičky 🙂

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂

Top 5 bodů co dělá Agilní transformaci úspěšnou

1.    Proč?

Asi úplně nejdůležitější je mít cíl. Proč byste se vůbec měli měnit. Protože jestli vše funguje dobře, firma prospívá a je businesově úspěšná, možná si nechte to, co máte. Ne každý musí být Agilní. Když najdete dostatečně kritický důvod pro změnu, určitě se vám to podaří. Důvody pro Agilní transformaci tedy musejí být strategické z pohledu organizace.

2.    Postoj a pochopení managementu

Druhým střípkem do mozaiky úspěšné Agilní transformace je pochopení managementu. Co tedy management musí pochopit? V první řadě že Agile je změna mindsetu – tedy kultury, přístupu k věcem, myšlení. Není to jen další proces, který bezmyšlenkovitě implementujete a je to. Bude to stát hodně energie na všech vrstvách firmy. Aby se transformace podařila, musíte ve firmě musíte budovat silný Agile Leadership a pomoci managementu se do transformace zapojit, být její součástí a řídit její směr.

3.    Definice Produktu

Dalším důležitým bodem je vědět co děláme. Agilní svět opouští tolik oblíbené projekty a plánuje práci pomocí Product Backlogu. Staví na dobrých Product Ownerech, kteří mají vizi a vědí čeho chceme jako firma dosáhnout.

4.    Experimenty

Dalším bodem, který je pro úspěch Agilní transformace nutný je ochota experimentovat. Určitě si říkáte, že na tom nic není. Ale kolik z vás je ochotno přijmout, že hodně experimentů se nepodaří a jsou tak dobrou příležitostí pro zlepšení? Kolik z vás bere chybu jako příležitost k poučení se? To vše je vlastně Inspect and Adapt princip, který je podstatou celého Scrumu. Experimentujete a hledáte cestu? V produktu i vlastním fungování? Pak jste Agilní. Odmítáte takovou možnost jen připustit a hledáte jednoduché recepty? V Agilní transformaci nic takového nenajdete.

5.    Trpělivost a odvaha

V neposlední řadě je to trpělivost a odvaha. Trpělivost proto, že taková změna se nestane přes noc a pro velkou korporaci je Agile cesta která trvá několik let a vlastně nikdy úplně nekončí. Agile je o neustálém hledání lepší cesty, neustálém zlepšování. Dobrá zpráva je, že výsledky přijdou hned jak se na cestu dáte, tedy už po pár Sprintech. Odvahu proto, že budete dělat věci jinak než dřív, a dost možná i jinak než ostatní kolem vás. A to odvahy vyžaduje docela dost. Budu vám držet palce 🙂

Český překlad Scrum Guidu

V rámci české agilní komunity vznikl český překlad Scrum Guidu, tedy ‘Průvodce Scrumem‘. Takže kdyby se vám nechtělo Scrum Guide číst v originále, tohle je poměrně povedená aktuální česká verze, která zachovává normálně používané termíny Scrumu, takže se nemusíte bát, že byste se v ztratili překladu jako já nedávno, když jsem dostala od vydavatele českou verzi své knihy The Great ScrumMaster: #ScrumMasterWay na review a musela se dívat do angličtiny co že to vlastně píšu. Takže nejen Scrum Guide, ale i kniha bude. Už jsem ji přepsala zpět do původního významu a čekam na finalni versi od Computer Press. Jupiiii 🙂

Asi o to víc oceňuji práci, kterou si s tím autorky překladu (viz poslední stranka dokumentu) daly. Když k němu budete mít nějaké připomínky, budou určitě rády za feedback a slibují, že ho zohlední. Děkujeme 🙂

Definition of Done

Přestože Definition of Done (DoD) je velice jednoduchý artefakt Scrumu, spousta týmů s ním zápasí.  V podstatě je to definice toho, co musí splňovat úlohy, abyste je mohli nazvat “hotovými” – tedy “done”. Je to v podstatě takový checklist definující kvalitu, kterou musí všechny úlohy na konci Sprintu splňovat, abychom je mohli považovat za hotové a ukázat je v rámci Sprint Review. Nesplňují-li některé položky Backlogu všechny části Definition of Done, nejsou hotové a musí zpět do Product Backlogu. Primárním smyslem je konzistence. Aby bylo jasné, v jakém stavu dodaný produkt je. Definition of Done vzniká jako dohoda mezi development týmem a Product Ownerem a je stejná pro všechny položky Backlogu. Na rozdíl od Akceptačních kritérií, která jsou u každé položky Backlogu různá, protože jsou funkční specifikací, je Definition of Done stejná pro všechny položky Backlogu abychom věděli, co kvalitativně musí každá funkcionalita splňovat. V dlouhodobém horizontu můžete tuto dohodu mezi týmem a Product Ownerem změnit a Definition of Done rozšířit o další pravidla a celkovou kvalitu produktu tak zvednout, ale rozhodně by se neměla měnit ze Sprintu na Sprint.

Jak taková definition of Done může vypadat?

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Běží na test serveru
  • Akceptováno Product Ownerem

Můžete jí samozřejmě udělat specifičtější:

  • Implementováno podle Product Backlog Item (User Story) definice
  • Automaticky otestováno (unit, functional tests)
  • Review (jiným členem týmu)
  • Dokumentace (interní)
  • Beží na test serveru
  • Akceptováno Product Ownerem

A jak již bylo zmíněno, Definition of Done se vyvíjí a časem zpřísňuje:

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Uživatelská dokumentace
  • Přeloženo do čínštiny, francouzštiny a němčiny
  • Běží na produkci
  • Obsahuje businessové metriky
  • Akceptováno Product Ownerem

V takovém případě jsme v podstatě implementovali Continuous Delivery, neboť jednotlivé funkční celky jsou releasovány na produkci už v průběhu Sprintu kdykoliv je tým dokončí – tedy splní všechny části Definition od Done. Takhle přísnou definition of Done mají týmy, které potřebují získávat zpětnou vazbu od zákazníků v reálném čase a rychle na ni reagovat. Proto businessové metriky, které měří chování zákazníka a porovnávají je s očekáváním jsou nutnou součástí takového prostředí.

Čím Agilnější vaše organizace je, tím přísnější je obvykle Definition of Done. Nezapomeňte ale, že každá Definition of Done je vždy dohodou mezi businessem a týmem a musí tedy odpovídat potřebám vašeho businessu. Přísnější není vždy lepší. 🙂 Žádná nebo slabá Definition of Done na druhou stranu zase vede k chaosu a totální ztrátě předvídatelnosti. A to byste asi nechtěli. Jako vždy v Agilu a Scrumu hledáme balanc, a tak konkrétní podobu Definition of Done musíte sami najít pomocí krátkých experimentů a principu Inspect and Adapt – tedy být Agilní.

Jak na škálování Scrumu pro více týmů? Ideální je LeSS Large-Scale Scrum

Když zavádíte či ve firmě používáte Scrum, časem se dostanete do situace, kdy potřebujete aplikovat Scrum na něco většího, a nechat spolupracovat více týmů. Obecně to není nic složitého, ale abyste se v tom neztratili, je vhodné si trochu pomoct nějakým frameworkem. U menší produktové firmy je to pořád relativně snadné. Použijete Scrum ve větším, tedy Large-Scale Scrum (LeSS).

Large Scale Scrum - LeSS

LeSS je jednoduchý framework, který staví na principech Scrumu a dále je používá na více týmů. Tedy v kostce máte, jednoho Product Ownera, jeden Product Backlog, jeden produkt, který prezentujete zákazníkům, ale více týmů, kteří ho společně dodávají. Týmy jsou stejně jako v klasickém Scrumu stabilní, self-organized, a cross-functional – tedy každý tým dokáže vzít libovolnou položku z Backlogu a dokončit jí. Musí tedy mít všechny kompetence, které jsou potřeba aby mohli dodat end-to-end hodnotu zákazníkovi podle Definition of Done např. DB, backend, frontend, dokumentace, UX, architektura, automatické testy, uživatelská dokumentace apod.). Takhle jednoduchý koncept platí pro prostředí do osmi spolupracujících cross-functional týmů.

Product Backlog
Pokud jste velká korporace (banka, pojišťovna, nebo prostě jen velká IT firma či firma s velkým IT oddělením), principiálně je to stejné. Jen implementace je výrazně komplexnější a změna náročnější. V takovém případě už si nevystačíte s jednoduchým LeSS frameworkem, ale musíte použít takzvaný LeSS Huge – tedy Large-Scale Scrum pro obrovská prostředí. Pořád máte stabilní, self-organized, a cross-functional týmy, které společně dodávají jeden produkt. Je dobré si uvědomit že produkt není projekt. Projekt je jen jednou položkou Product Backlogu. Více si o tom můžete přečíst tady. Produkt je tedy daleko dlouhodobější a umožňuje postavit stabilnější týmové prostředí.

Large Scale Scrum - LeSS HugeLeSS Huge není až tak odlišný od klasického Large-Scale Scrumu. Co je ale v LeSS Huge složitější je struktura Product Backlogu. Zbytek zůstává stejný. Překvapivě jednoduché, že? Abychom si zachovali takzvaný tah na branku, stále chceme mít jednoho Product Ownera a jeden Backlog. To ale už není tak snadné, a tak vzniká podpůrná struktura takzvaných Area Product Ownerů, kteří pomáhají výše zmíněnému Product Ownerovi s prioritizací. Arey nejsou fixní, ale dynamicky se mění podle potřeb businessu – ostatně stále platí, že týmy jsou cross-functional, takže mohou vzít z Backlogu jakoukoli položku a naplánovat ji do Sprintu. Co neumí, učí se. Obvykle ale nemusí umět vše a věnují se nějaké oblasti (Area). Nezapomeňte ale, že oblast není komponenta a týmy dodávají vždy end-to-end funkcionalitu. Product Backlog je stále jeden, a tak máme pořád focus na ty pro firmu businessově nejdůležitější věci.

Je to jednoduché, a hlavně to funguje. Ale stejně jako Scrum, ani Large-Scale Scrum tedy LeSS není žádná zázračná pilulka. Aby zafungoval vyžaduje změnu myšlení, přístupu a mindsetu. Ale na to jste si v Agilním světě jistě zvykli. 🙂

Agilní metody řízení projektů – 9. Agilní a Scrum certifikace.

V devátém díle mé video minisérie “Agilní metody řízeni projektů“ se podíváme na Agilní a Scrum certifikace. Na ty, do kterých se vyplatí investovat, pokud chcete na trhu práce zlepšit svojí pozici či plánujete práci v mezinárodním prostředí, anebo vědět, na které se ptát pokud najímáte spolupracovníky do svých Agile a Scrum týmů. Prostě jak říkám jde o Agile a Scrum certifikace, které mají opravdu hodnotu.

Další díl: 10. Zuzana ‘Zuzi’ Šochová.
Předchozí díl: 8. Jak na Agilní transformaci.

Agilní metody řízení projektů – 8. Jak na Agilní transformaci.

V osmém díle mé video minisérie “Agilní metody řízeni projektů“ se zaměřuji na organizaci jako celek. Nebo-li co si představit pod pojmem Agilní transformace, jaké jsou její fáze a jak se firmy transformují na moderní způsoby řízení.

Další díl: 9. Agilní a Scrum certifikace.
Předchozí díl: 7. Agile v marketingu.