Z projekťáka ScrumMasterem

Spousta lidí si myslí, že Project Manageři jsou dobrými kandidáty na ScrumMastery. Ze zkušenosti tomu tak ale ne vždy je. Většina projekťáků má s přechodem na roli SrumMastera velké potíže. Je to hlavně o hodnotách a o tom, co považujete za důležité.

Asi největším rozdílem je, že ScrumMaster není zodpovědný za dodávku v rámci Sprintu, za kterou je zodpovědný Development tým, ani za dodávku produktu jako takového, za kterou je zodpovědný Product Owner, ale za to, aby tým dobře fungoval, zlepšoval se a byl takzvaně self-organized, tedy samoorganizovaný. A to vyžaduje úplně jiný přístup, než organizace práce na projektu. Je to o coachingu, facilitaci, nadšení a víře, že Agile a Scrum funguje a je tou správnou cestou, schopnosti měnit kulturu organizace a stavět dobře fungující týmy. Převážně jde o softskilly.

Dalším rozdílem je, že v agilním světě nejsou projekty. Ostatně není pro ně důvod. Dodávku řídíme pomocí Product backlogu, kde Product Owner položky backlogu prioritizuje, podle business value.

A posledním rozdílem je, že nám až tak nejde o efektivitu. Dodání více funkcionality zdaleka totiž neznamená že dodáte více hodnoty. Scrum je Business value-driven, customer-centric. Maximalizujeme hodnotu za minimalizace effortu. Estimaty, velocity a burndowny jsou jen pozůstatky tradičního světa, které mají jen pramálo společného s měřením dodané hodnoty.

Asi vidíte, že změna z projekťáka na ScrumMastera není zdaleka tak jednoduchá, jak se původně zdála. Není samozřejmě nemožná, ale spousta projekťáků si na ní vyláme zuby a zůstane ScrumMasterem z donucení. Jestli se chcete stát skvělým ScrumMasterem, moje rada je, zapomeňte, že jste kdy byli projekťáky a začněte úplně od nuly. Bude to tak snazší, než když budete neustále tyto světy porovnávat.

Co se stane s rolí Project Managerů?

Jak jsem psala minule, poptávka po projektových managerech je na ústupu. Už delší dobu. A bez ohledu na to, jak moc se to PMI snaží zakrýt různými akvizicemi, nebude trvat dlouho a role projektového manažera bude pryč. Stejně jako koňské povozy a vozka. Dnešní projekťáci ještě možná přežijí jako projekťáci do důchodu, ale těm co studují bych kariéru projekťáka neradila.

Ale když už máte tu smůlu a vaše organizace přejde na Agile a Scrum předtím, než jste stačili odejít do důchodu, máte v podstatě několik možností co dál:

–        Zapomenout na projekty, posunout se více k zákazníkovi, místo efektivity a dodávané funkcionality se zaměřit na maximalizaci business value, produkt jako celek, a stát se Product Ownerem,

–        Zapomenout na projekty, posunout se více k týmu a fungování organizace a stát se ScrumMasterem,

–        Zapomenout na projekty v klasickém slova smyslu a stát se stakeholderem, který pomáhá Product Ownerovi a týmu porozumět složité struktuře zákazníků a získat feedback.

První varianta se děje málokdy, protože vyžaduje velký nadhled a schopnost prioritizovat. Druhou variantu zkouší firmy nejčastěji, ale málokdy je taková změna úspěšná vzhledem k osobnosti většiny project managerů. Takže zbývá třetí varianta, vzdát se managementu týmu a pomáhat Product Ownerovi a týmu s tím, co je zrovna potřeba. Čím otevřenější jste změnám, tím snazší pro vás bude první nebo druhá varianta, protože Agile není jen další změna procesů, ale poměrně zásadní změna uvažování a fungování organizace.

Agile není další metoda řízení projektů

Agile není o nových praktikách, procesech ani nástrojích. Je to jiný způsob myšlení a přístupu k věcem. Být flexibilní, adaptivní. Pokud postoupíme na další úroveň, je to iterativní customer-centric, value-driven týmový přístup vhodný pro řešení komplexních problémů. Potřebujete mít odvahu dělat věci jinak, být otevřený a transparentní, spolupracovat, ale myslím, že to všechno už víte.

Implementace Agilu na úrovni projektů může být drobným krokem na vaší cestě k Agilu. Dává vám relativně omezený prostor pro experimenty, takže minimalizujete riziko toho, že se váš první pokus nepovede. Ale dříve či později, pokud chcete dosáhnout reálných business cílů, musíte posunout agilitu na úroveň produktů a organizace, kde se projekty stanou zbytečnými. Překvapení? Vraťme se tedy o krok zpět. V tradičním světě je projekt kontejnerem pro řízení celé dodávky a projektový manažer ten kdo projekt řídí. Ve Scrumu ale máme Product Backlog, který obsahuje, co je třeba udělat, a Product Ownera, který se postará o to, aby vše bylo dodáno dle priorit. A místo projektu máme jednoduše položku backlogu. Můžete jí nazvat Epic, ale žádný projekt na to není potřeba, práce z Backlogu se postupně dokončuje, Sprint po Sprintu.

Takže jako malý rychlý experiment je asi ok Agile aplikovat na konkrétní projekt, ale být agilní znamená mnohem víc. Čím více organizací rozumí agilitě, tím méně projektů a projektových manažerů ve firmách uvidíte. Možná se vám to nelíbí, můžete se se mnou hádat či rovnou bojovat s celým Agilem argumentací, že to je od začátku celé špatný nápad, který nikdy nemůže fungovat, anebo můžete naskočit do již jedoucího (agilního) vlaku, zůstat konkurenceschopní a udržet si relevantní práci, protože poptávka po projektových manažerech klesá. Pomalu ale jistě.

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ě. 🙂

Co je to produkt a co projekt

Projekt začíná a končí. Produkt je tady ‘donekonečna‘. Pokračuje dalšími fázemi, rozšiřuje se, mění se.  Definice, kterou používá LeSS (Large Scaling Scrum) říká, že produkt by měl být tak široký jak je jen možné, ale stále praktický. Praktičnost obvykle končí hranicemi vaší firmy. Když už byste museli do cross-functional týmů zakomponovat lidi z cizích firem, abyste mohli dodávat end to end funkcionalitu, tak jste asi na hranici produktu. Na druhou stranu, jestliže produkt vnímají zákazníci jako jeden produkt – je to jeden produkt bez ohledu na technologii. Tedy frontend a backend je jeden produkt. Internetové řešení obsahující Web, iPhone a Android aplikaci je jeden produkt. Z druhé strany všechno co má podobný kód a je technicky podobné je jeden produkt.

Továrna na párky

Firmy často nevědí, kdy se na to co dělají, mají dívat jako na jeden produkt (viz výše zmíněná kritéria) a kdy to naopak rozdělit na více celků. Analogie, kterou pro takové rozhodnutí používáme, se jmenuje Továrna na párky. Chodí k vám různé zakázky-projekty. Někdo chce hovězí párky na večeři, někdo grill mix na párty. Někdo chce dokonce vegetariánský párek, někdo pikantní chilli. Když se na to budete dívat projektově, nikdy nepostavíte stabilní cross-functional týmy. A Agile vám nikdy pořádně nebude fungovat. Když ale řeknete, že vaše továrna na párky je továrna na internetová řešení, a na projekt se budete dívat jen jako na velký Epic v Backlogu, bude vše najednou snadné. Máte jeden Backlog, tam se sypou veškeré projekty. Jako každá položka Backlogu prochází Backlog Refinementem a prioritizací. Týmy pak jen berou ty nejdůležitější položky z Backlogu a dodávají je v rámci svého procesu v kvalitě odpovídající Definition of Done.

Když to mám nějak sesumarizovat, většinou produkt proti současnému stavu rozšiřujeme a stavíme stabilní továrnu, kde týmy mohou spolupracovat na jedné věci. Na druhou stranu takových továren můžete mít ve firmě mnoho. Například když děláte online hru a informační systémy, asi je praktické aby to byly dvě továrny a ne jen jedna.

Jak takovou velkou továrnu organizovat? Na to odpovídá například Large Scaling Scrum LeSS –kdybyste se chtěli o LeSS frameworku dozvědět více, pořádáme 3 denní LeSS workshop při konferenci Agile Prague 2016 v září.

Úspěšnost agilních projektů

Pro firmy, které s agilním vývojem nemají praktické zkušenosti, je jednou z nejdůležitějších otázek jak jsou agilní projekty úspěšné. První, na co si musíme odpovědět je úspěšnost IT projektů obecně. Jaká je? A jak se vlastně pozná úspěšný projekt? Když se nad takovou otázkou zamyslíte, zjistíte, že jde o projekt který je dodán včas, v rámci budgetu a s očekávanou funkcionalitou. Jaké procento úspěšnosti byste očekávali?
Standish CHAOS study dělá již pár let výzkum, jehož výsledky nejsou nijak povzbudivé – pouze cca 30% projektů končí úspěšně. Ostatně posuďte sami:

Success of IT projects

Studie dále uvádí i prvních pět důvodů pro úspěch IT projektů:
• Zapojení uživatele
• Podpora Executive manamentu
• Jasné business cíle
• Optimalizace funkcionality
• Agilní procesy

Pro firmy uvažující o přechodu na agilní metody bych ráda zmínila i Standish Group CHAOS studii z roku 2012, která porovnává úspěšnost IT projektů řízených tradičními metodami s agilními. Výsledky jsou opravdu překvapivě dobré ve prospěch Agilních metod.

Agile vs. Waterfall Projects success

Zpráva dále doporučuje Agilní metody jako “univerzální řešení nízké úspěšnosti softwarových projektů”. Projekty, na kterých jsou nasazeny Agilní procesy, mají třikrát vyšší úspěšnost než projekty řízené klasickým waterfallem. Zároveň výrazně nižší procento agilních projektů končí později a přesáhne stanovený budget.

Můžeme diskutovat o tom, proč taková data byla naměřena a čím to přesně je, nicméně pro všechny agilní nadšence, kteří hledají nějaký důkaz proč agilní metody ve firmách alespoň zkusit, to může postačit jako vhodný argument pro podporu pilotního projektu. Zbytek už bude na vás a vašich schopnostech. A já věřím, že se agilní metody osvědčí i u vás.