Category: Agile

Vše co jste chtěli vědět o Agilních metodách

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.

Certifikace je mrtvá, nechte se certifikovat

A nebo taky ne. Hned v úvodu zopakuji svůj názor, že certifikace jsou jen drahý cár papíru. V případě Agilních certifikací hodně drahý. Většina certifikací nezaručuje, že rozumíte Agilu ani Scrumu. A ke stejně dobrým kurzům se dostanete i za nižší cenu, bez certifikace. Ale ač to všichni vědí, stejně i tak je certifikace v mnoha firmách ceněná a vyžadovaná. Tak si pojďme udělat přehled Agilních certifikací.

Klasikou je Scrum Alliance a její CSM – Certified Scrum Master a CSPO – Certified Product Owner. Jsou to certifikace zaměřené na Scrum proces, zakončené velmi jednoduchým online testem. Ideálně byste měli mít se Scrum procesem již nějaké zkušenosti, jen tak si z kurzu odnesete hodně. Začátečník si odnese jen ten papír a to je dost škoda. Trváte-li tedy na certifikaci, chcete aplikovat čistý Scrum jako Scrum Master nebo Product Owner, je to asi ta pravá volba pro vás.

Další z certifikací, které jsou dnes na trhu k dispozici je certifikace ICAgile. Je to certifikace zaměřená nejen na Scrum proces, ale primárně na pochopení Agilního mindsetu. V Čechách je dostupná od začátku letošního roku, v zahraničí je ale hodně známá a oblíbená. V rámci kurzu se probírají různé Agilní přístupy a praktiky. ICAgile Certified Professional je kurz zaměřený prakticky, tak aby účastníci získané zkušenosti mohli hned aplikovat v kontextu své firmy. Je také cenově dostupnější. ICAgile dále nabízí další kurzy pro pokročilé na základě této certifikace. Když už nějakou certifikaci chcete, doporučuji certifikaci právě od ICAgile.

No a pro úplnost ještě je tu hodně formální a z mého pohledu až “neagilní“ Scrum.org a ještě tradičnější PMI. Jestli nějaké certifikace nedoporučuji, tak to jsou právě tyto. Ale je to samozřejmě věc názoru.

Takže ještě jednou, zapomeňte na certifikace, o nic agilnější s nimi nebudete. Ale když už nějaký ten certifikát získáte, snažte se vybrat takový kurz, který vám přinese co nejvíce. Nemá smysl certifikací začínat. Certifikaci si nechte až jako třešničku na dortu, jako ocenění vaší dobré práce v Agilním nebo Scrum týmu.

Výsledky Agilního dotazníku

Přibližně před půl rokem jsme vás spolu s Etneterou prosili o vyplnění Agilní ankety. Výsledky pak byly prezentovány v rámci konference Agile Prague 2013. A tady je slíbený report.

Co se ve zkratce dozvíte? Že dotazník vyplňovali převážně firmy které agilní metody používají.

Snížení nákladů kupodivu považuje za nejdůležitější jen 13% respondentů. A vyšší efektivita, kterou slýchám velmi často se do první desítky ani neprobojovala. Asi je to dané tím kdo odpovídal.
Duvody pro zavedeni agilnich metod

A kde jsou Agilní metody lepší? V rychlosti dokončení, kvalitě a spokojenosti klienta.
Srovnani agilnich metod a klasickymi

Chcete se na výsledky podívat detailněji? Více se dozvíte na stránkách Etnetery která za celým výzkumem stojí: Výsledky Agilního dotazníku.

Jak vybrat Scrum Mastera aneb proč i zkušení Scrum Masteři selhávají v Agilní transformaci

Role Scrum Mastera není zdaleka snadná, a ne nadarmo se považuje za klíčovou k úspěchu týmu a nasazení Scrum procesu. Scrum Masterem je typově někdo jiný než se hodí na běžnou roli team leadera (který často vše určuje za tým), nebo experta (který se neptá, ale za tým rovnou odpovídá, protože jako expert zná vždy tu správnou odpověď), nebo projektového managera (který často mikromanaguje, vše řídí sám a to včetně organizace týmu, priorit a celé dodávky). Scrum Master není zodpovědný za dodání, ale za to, že tým funguje jako samoorganizovaný tým, že tým přebírá zodpovědnost za svůj vnitřní proces, že se zlepšuje, je motivovaný, prostě v dlouhodobém pohledu funguje optimálně. Krátkodobě klidně nechá tým v rámci Sprintu nedodat nic, ale nenechá takovou situaci vyrůst v běžný zvyk a obvyklý stav. Když máte plně Agilní firmu a zaběhnutý, zkušený tým, je to relativně snadné. Stačí najít Scrum Mastera, který rozumí Scrum procesu a podstatě své role, je vnímavý, empatický, umí naslouchat a dá týmu prostor, aby se sám rozhodoval a nesl v rámci procesu za svá rozhodnutí zodpovědnost. Koučuje, facilituje, staví tým. A tým funguje.

Problém nastává, když ale Scrum Mastera zvyklého takhle pracovat dáte do týmu, který ani neví, co je Scrum, proč jednotlivé praktiky aplikují a co by jim měly přinést. A takový Scrum Master si nevzpomene na své začátky, a jen pomocí coachingu a facilitace vykonává roli Scrum Mastera v ideálním týmu tak, jak byl zvyklý. To samozřejmě nestačí. Scrum Master musí být i mentorem a týmu Scrum proces vysvětlit, prodat. Ne přikázat, ale poradit. A postupně je učit Agilu jako mindsetu, Scrumu jako procesu, kde jde primárně o zodpovědnost, samoorganizaci. Čistý koučing a facilitace nestačí. Tým prostě neví co a jak. Nemá zkušenosti. Nikdy nic podobného nezažil.

Další častou chybou Scrum Mastera v začínajícím týmu (a takový tým může začínat i dva roky) je pocit, že tým musí ‘rychle začít fungovat a že vysvětlování ‘proč‘ by vše jen zdržovalo. Prostě jim řekne, jaké mají dělat meetingy a co na nich říkat, a žádným školením ani vysvětlováním proč to všechno se nebude zdržovat. Vždyť je to jasné. Výsledkem je v lepší případě technický Scrum. Bez pochopení, bez energie, bez výsledku. Takové loutkové divadlo. Kdo je za takový stav odpovědný? No zcela jistě nezkušený Scrum Master, který neupravil svůj styl týmu. Problém je, že na interview to často nepoznáte. Scrum Master ví, jaká je jeho role, co má dělat, ví proč a jak Scrum funguje, jen nepovažuje za nutné to týmu vysvětlit. Vždyť už agilní jsou, říkali to.

Dalším problémem, který je ve firmách častý, je Scrum Master idealista. Stejně jako v předchozích případech, na pohovoru vše vypadá dobře, ba ideálně. Scrum Master je pravým odborníkem na Scrum. Ví jak funguje, rozumí své roli, a v jednom dobře fungujícím týmu úspěšně Scrum Masteroval. Jen se často zapomene na to, že on ten Scrum neimplementoval a často ani nezažil v rámci větší organizace, a tedy se s mnoha problémy běžnými při transformaci velké organizace nikdy nesetkal. Stačilo rozumět Scrum procesu a mít nadšení. Ve velké organizaci ale nejde implementovat všechno hned a ideálně. Musíte dělat kompromisy. Zbytku organizace často trvá hodně dlouho, než Agilní proces vezme na vědomí a ještě déle, než ho akceptuje a pochopí. Předchází tomu hodně komunikace, diplomatického vyjednávání a PR. Ale Scrum Master idealista na nic nečeká a Scrum tlačí silou hlava nehlava. Product Owner musí, manager nesmí, tým neřekne, protože to není jeho zodpovědnost, proces se musí změnit, pozice upravit, ohodnocování změnit, … Výsledek je jak po procházce slona v porcelánu. Víc škody než užitku. A to nejen mimo tým ve zbytku organizace, ale i v rámci týmu, který takového Scrum Mastera často odmítne stejně jako v předchozích případech. Co z toho plyne? Transformaci velké organizace nemůžete nechat na lidech, co nikdy žádnou takovou organizaci neměnili a s podobnou transformací nemají zkušenosti. A to bez ohledu na to, jak dobrými se zdají být Scrum Mastery. Zdá se to být jasné, ale firmy si často roli Agilních coachů se Scrum Mastery pletou a pak jsou překvapení, že Scrum Master se neosvědčil.

Výsledky Vánočního Dot Votingu

Jak jsem slíbila, je tu výsledek Vánočního dot votingu. Než se dostanu k výsledkům, zhodnotím službu jako takovou. Z obrázků to vypadá jako dot voting, když ale službu zkusíte, najdete obyčejné radiobuttony. Ani nemáte možnost dát více hlasů jedné možnosti. Tedy když to shrnu, s dot votingem to má společné tak akorát to jméno. Od registrace nevidíte tečky ani v administraci ani při hlasování. Prostě podfuk. Škoda. Mohla to být pěkná služba pro distribuované týmy.

Ale když už jsem to vyhlásila, na otázku: “Kdybyste chtěli dát vaší firmě dárek k Vánocům darek, který stačí jen rozbalit a je naimplementováno. Co z Agilních metod byste jí nadělili?” vyhrály následující tři možnosti:

  • Scrum
  • Product Owner role
  • Agile Management

    • Vlastně to není nijak překvapivé. Úspěšnému nasazení Scrum procesu obvykle ve firmách stojí v cestě právě nepochopení a nízká podpora managementu a neochota Product managementu se do celého procesu zapojit a převzít odpovědnost za Product Backlog a jeho priority. Bez těchto dvou částí Scrum úspěšný nikdy nebude.
    Takže ať se vám v novém roce daří.

    PF2014

    Další rok máme za sebou. Připadá mi, že Agilní metody se přeci jen pozvolna stávají běžnou součástí nejen projektového řízení a IT, ale že výhody tohoto přístupu pozvolna poznávají i produktoví manageři, business, a liniový management. Což je jistě dobrá zpráva.

    Na druhou stranu stále více se ukazuje, jak je těžké agilní přístupy, Scrum, Kanban, … aplikovat bez někoho s osobní znalostí agilní kultury. Někoho kdo v agilním světě žil a chápe proč jednotlivé praktiky fungují a jak do sebe zapadají.

    Samotné praktiky a plánované meetingy vás nespasí. Ani Standup meetingy, ani tabule s lístečky, ani User Story, ani to že requirementy nazvete Backlogem. Bez pochopení agilní kultury vznikne v nejlepším případě něco, co můžeme nazvat např: ‘technický Scrum’. Vypadá to jako Scrum, ale není. Při troše štěstí vám tyto kosmetické změny pomůžou a vy se uspokojíte. Není to sice bomba, ale je to lepší když teď spolu komunikujeme. Při troše smůly vám takto nasazené agilní metody, Scrum, Kanban, nepřinesou zhola nic, snad jen s výjimkou otravných meetingů, zbytečné byrokracie a nesmyslných pojmů.

    Přeji vám všem, aby se vám nasazení agilních metod dařilo a ten rozdíl proti starému neagilnímu světu byl výrazný a k lepšímu. Pěkný rok 2014.

    Proč máme Product Ownera

    O roli Product Ownera toho bylo napsáno hodně. Přesto však některé firmy nepochopily jeho význam a berou takového člověka jako administrativní sílu. Ostatně, kdo jiný by měl mít čas být týmu k dispozici a psát jasné a konkrétní User Story. Product Manager na to nemá čas, v lepším případě je furt u zákazníka, v horším řeší takových produktů několik nebo jen tráví většinu času na obecných firemních mítincích a stihnout to ani při nejlepší vůli nemůže. V obou případech se pak velmi často setkáváme s modelem, kdy o všem rozhoduje Product Manager, který ale nemá čas, a takzvaný Product Owner se na všechno chodí ptát, protože o čemkoli rozhodne, stejně Product Manager shodí při customer demu ze stolu. Vychází to z neochoty a často i neschopnosti delegovat, nesmyslné organizaci, a také toho, že takový Product Owner není nositelem vize a sám jí často nerozumí. Jak se to pozná? Zeptejte se ho, proč by tým měl na produktu pracovat. Většina takových Product Ownerů odpoví něco ve smyslu, že to asi firma potřebuje… že… Když tím testem přeci jen projde, obvykle se zasekneme hned na další otázce, proč děláme tuhle User Story. A kde je její business value. Co přinese zákazníkovi? A obvyklá odpověď je ‘no Product Manager nebo zákazník to tak chce‘. Kde se pak má brát motivace a zapojení týmu a proč by zrovna na tomhle produktu měli pracovat?

    Samozřejmě i takové rozdělení role Product Ownera mezi více osob může fungovat. Jeden příklad z nedávné praxe. Máme Product Managera co nemá moc čas. Je to vizionář, většinu času cestuje po světě a je v letadle. Oblítává zákazníky z různých koutů světa, vymýšlí inovace, dívá se, co má konkurence. Aby tým nebyl od produktu odtržený, není tento člověk vnímán v roli plného Product Ownera, ale spíše interního zákazníka, co chodí s high-level nápady. Product Owner je s ním v častém kontaktu, sdílí spolu nápady a vize, přemýšlí, co by se mělo jak udělat, co změnit. Product Manager je zodpovědný za budget a celkový úspěch produktu na trhu. V podstatě by šlo i říct, že definuje Backlog na úrovni Epiců maximálně velkých Super User Stories, zatímco reálný Product Owner se za pomoci týmu stará o to, aby vznikla správná granularita User Stories a tým byl na produkt, vizi a business value napojený. Je součástí Backlog Groomingů, je zodpovědným za Product Backlog, jeho hodnotu a porozumění týmu. Výhodou je, že takový Product Owner má v roli Product Managera zástupce, a když se stane, že z nějakého důvodu není k dispozici, tak Product Manager převezme jeho roli a tvoří s týmem User Stories. Je to tedy jen o lidech. Tihle to zvládli rychle a nejsou zdaleka jediní. Ale není to bohužel zdaleka tak obvyklé, jak by bylo potřeba.

    Další obvyklý problém v této oblasti je neschopnost firem se nad portfoliem produktů zamyslet a nějak je omezit nebo prioritizovat a serializovat. Takové firmy si myslí, že tím, že se na produktu už pracuje, je zajištěna jejich úspěšnost. Musíme dělat všechno najednou. A tak se některé firmy podobají střelcům s automatickými zbraněmi, co sice mají zavázané oči, ale o to více střílejí kolem sebe. Čím více výstřelů, tím větší pravděpodobnost že se do něčeho nakonec trefíte… S takovou strategií vám v efektivitě a úspěšnosti nepomůže nic. Ani Agile, ani krásný formát User Stories. Role Product Ownera je tu proto, aby se někdo staral o to, co nám to přinese a s pomocí agilních metod dostal na business nápady rychlou zpětnou vazbu. Když se to neosvědčilo, zahoďte to a zkuste něco jiného. Ale na to musíte mít již v začátku jasnou představu, co chcete dosáhnout a jak poznáte, že se to povedlo. Jinak střílíte kolem a doufáte, že se to tentokrát povede. Agile a Scrum není jen o týmu a spolupráci, ale je o napojení na business a zpětné vazbě. Je o schopnosti prioritizovat. A to nejen na úrovni User Stories a každého produktu, ale i produktů v rámci firmy. A to se bohužel ve spoustě firem neděje.