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.

    Vánoční Dot Voting

    Našla jsem pěknou stránku na online Dot Voting… Tak jsem jí chtěla vyzkoušet.

    Otázka zní: “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?”

    Najdete tam plné procesy, jednotlivé praktiky i drobné artefakty. Zvolte si to co je pro vás a vaši firmu teď zrovna nejdůležitější. Máte 5 hlasů. Hlasování končí 24.12.2013.

    Hlasovat můžete tady:
    http://www.dotvoting.org#vote12128002ryxa15aomz74

    A do komentářů mi napište, jak se vám služba Dot Votingu líbila 🙂
    Já rovnou dodám že mě hodně zklamal UI pro hlasování. Když jsem voting vytvářela, podle obrázků na stránce bych čekala něco zcela jiného.

    Na výsledky se můžete podívat tady.

    Role testera v agilním týmu

    Jedním z nejčastějších problémů, na které týmy při agilní transformaci narazí, je rozdílné vnímání rolí. V tradičním světě analytik dělá dopředu analýzu, vývojář to podle ní nakóduje a tester následně hledá chyby. O tom, že analýzy dopředu nepotřebujeme, neboť můžou vznikat klidně za běhu, se mluví často. O tom, že vývojáři mohou pomoci s testováním taky, ač tato praktika již obvykle není přijímána s takovým nadšením a slýcháme k ní spousty výmluv typu vývojáři to nemůžou testovat protože to neumí. No proto také říkáme, že testerům s testováním mohou pomoct. Ne že je mají nahradit. Hned druhá výmluva v pořadí je, že berou větší plat než testeři a tak že by se to nevyplatilo. A tak nám tato spolupráce obvykle zpočátku trochu skřípe.

    Dříve nebo později tak týmy dojdou do stavu, kdy testeři na začátku Sprintu nemají co dělat a na konci nestíhají. User Stories jsou hotové – tedy nakódované – a přesto je nesmíme uznat jako výsledek Sprintu. Chybí přeci testy. Týmy v takové situaci přichází s různými legračními nápady jako např. že by bylo potřeba testery od týmu oddělit a udělat jim separátní posunutý Sprint. Tedy to, co vývojáři v jednom Sprintu napíšou, testeři v druhem Sprintu otestují a je to. Ale to jsme pořád mentálně ve waterfallu. Nikam blíže k agilnímu Scrum týmu jsme se v pochopení ani implementaci neposunuli. Bez ohledu na to, jestli máme tabuli a děláme standupy.

    Jak by tedy taková spolupráce měla vypadat? Analytik, vývojář a tester si vezmou User Story, a začnou si o ní povídat. Analytik vymýšlí, jak by se daná funkcionalita měla chovat, vývojář to hned implementuje a tester upozorňuje, na co vše si musí dát pozor. Co uděláte když nepřijdou data? Co když nebudou validní? Nezapomeňte, že v akceptačních kriteriích je i to či ono. A v neposlední řadě připomíná business value (proč) definovanou v poslední části formule User Story, abychom v plném zapojení do implementace funkcionality nezapomněli, proč to vlastně celé děláme a v návrhu to zohlednili. Tedy v podstatě místo aby chyby chytal na konci (kdy už je pozdě), chceme aby chybám předcházel. Chceme, aby chyby vůbec nevznikaly a vývojář se tedy nemusel k již ‘hotovému’ kódu vracet. Spolu s tím, že testera zapojíme do návrhu řešení funkcionalit, chceme, aby vývojářům pomáhal již v průběhu a testoval jednotlivé části. V některých případech pak klidně pracují v páru, jinde jde jen o úzkou spolupráci. Honí-li se vám hlavou, že to nebude efektivní, protože tester to musí testovat pořád dokola, není tomu tak. Opravy chyb se také testují dokola a k tomu tam máme ještě multitasking vývojářů a jejich čas strávený opravou již hotových funkčností. A říkáte-li si, že to vaši testeři nezvládnou, protože co mají testovat pochopí až z hotové funkcionality, zkuste se podívat na to, jak dobře definované User Story máte. Jestli dobře, včetně akceptačních kriterií, je to snadné. Když ne, není to chyba testerů, ale pravděpodobně tomu nerozumí ani ostatní členové týmu.

    Takže summary na závěr. Úkolem testera není chyby hledat, ale předcházet jim. Dobrý tester v agilním týmu dosáhne toho, že ve finálním testování User Story se žádné chyby nenajdou. A tím jen tak mimochodem ušetří firmě spousty času potažmo peněz. Dobrý tester rozumí zákazníkovi a funkcionalitě a pomáhá s návrhem řešení. Umí se na User Story podívat očima uživatele. Je to plnoprávný člen týmu, který je pro jeho úspěch klíčový. A otázka na závěr… Opravdu si myslíte, že takový člen týmu má mít menší plat jen kvůli názvu jeho pozice?

    Shu-Ha-Ri aneb návrat k základům

    Agilní metody upadají více a více do vlastní pasti zdánlivé jednoduchosti. Jak se všeho co je agilní chytá více lidí, stává se z agilních metod běžná praxe, kterou se ohání kde kdo. A tak to přeci nemůže být složité, že. Ostatně co je na agilním manifestu nového. Jsou to staré známé věci, které se zdají být zřejmé až do té doby než se je pokusíte použít. A tak hned jak se vám něco z toho co Agile doporučuje nezdá, změníte to nebo rovnou vyhodíte.

    Jenže ona složitost agilního světa je ukryta někde zcela jinde. Musíte tomu porozumět, musí vám to přejít do krve jako metoda, styl řízení, jako způsob jak organizovat lidi. A právě tady je ukrytý problém. Aby se tak stalo, chce to cvik. Opakující se dril. Zpět k základům. Držet se daných pravidel a nezkoušet je hned v začátku měnit. Poslední dobou slýchám čím dál častěji na různých workshopech a konferencích skloňovat japonský princip učení se: Shu-Ha-Ri. Na to abyste se stali masterem, musíte postupně projít jednotlivými stupni. Ale to si většina Scrum Masterů, týmů ani managerů neuvědomuje. Je to moc práce, a oni už jsou zkušení, certifikovaní, tak proč začínat od začátku. Agile je přeci tak snadný. Selský rozum. Tak co, upravíme si to rovnou.

    Jak se tedy podle japonských mistrů stát masterem? Shu je pro začátečníky. Je to čistý dril jako v armádě. Držte se pravidel, neměňte je, a snažte se je dělat pravidelně, správně a v plné kvalitě. Nepřemýšlejte o možných odchylkách, držte se doporučených principů a pravidel. Jak dlouho? Nebudou to ani týdny, ani měsíce. U takového Agilu a Scrumu to mohou být klidně tři roky. V druhé fázi – Ha – už máte sice základní principy zažité a začínáte se dívat na různá další doporučení a možnosti jak tyto další cesty implementovat, ale pořád ještě nejste experty kteří si pravidla mění a vymýšlí nová. 

    Poslední fáze Ri je je pro ty, kteří už se nepotřebují učit od jiných jak mají danou věc dělat, a jsou schopni si vytvářet své vlastní teorie, principy a praktiky. Učí se z vlastní praxe. Bohužel, většina týmů ač ve fázi Shu, je skálopevně přesvědčena o tom, že je dostatečně zkušená na to, aby vymýšlela vlastní Agile a Scrum. Věří, že již dávno dosáhli Ri. A když by to náhodou nefungovalo, tak je to vina Agilu samotného. Prostě Agile ani Scrum není pro nás. Je na to jednoduchá pomoc. Vrátit se k základům, a jít cestou drilu jednoduchých základních praktik a postupného pochopení a vstřebání agilního přístupu. Není to ani Ri, ani Ha ale Shu. To je ale spousta práce a vyžaduje hodně trpělivosti. A to se v dnešním rychle běžícím světě špatně hledá. Ale bez toho se jen těžko stanete úspěšnými a Agile pro vás bude jen další teorie, která stejně jako ty předtím, prostě nefunguje.

    Může být velká korporace agilní?

    A co to vlastně to agilní je… Když za agilní považujeme prostředí, kde je jeden tým, jeden Scrum Master a jeden Product Owner, asi se jiné odpovědi než že ne, nedobereme. Moje výhoda je, že na rozdíl od spousty mých českých kolegů jsem se Scrum a Agile neučila z knihy ani v malé firmě, ale ve velké nadnárodní korporaci v Americe, která má přes 50% světového trhu svých produktů, a k tomu operuje v takzvaném life critical segmentu, tedy prostředí významně regulovaném normami a předpisy, kde se za eventuální chybu platí až lidskými životy. A tak mi tyhle žabomyší spory o to co je a není agilní, ne nepodobné náboženským třenicím o universální pravdu, poněkud unikají…

    Ono na tom modelu jeden tým, jeden Scrum Master a jeden Product Owner není nic špatného. Naopak. Je to takový základní stavební kámen, kterému musíme do detailu porozumět, než se pustíme do něčeho většího. Taková “mateřská školka”. Když ale zavádíme takovou změnu v korporaci, chce to schopnosti a zkušenosti z “vysoké školy”. Tedy o tři stupně víc. Když jste v garážovce, asi si s tímto modelem i vystačíte. Když ale jste součástí korporace, často narážíte na zcela drobné překážky. Nemáte pod kontrolou HR strategii. Vypsat novou pozici je náročná věc. Nemáte na ní headcount. Musíte vygenerovat mračna směrnic, a hlavně vysvětlit HR podstatu změny, kterou nasazujete. Změnit styl ohodnocování je většinou zcela mimo vaši kontrolu. Často nemáte ani možnost vyhodit některé nepřizpůsobivé jedince, tzv. trafikanty, co si za dlouhá léta zvykli nic nedělat a každé změně se zuby nehty brání. Obvykle nemáte pod kontrolou celou organizaci, a ostatní její departmenty často vaše nadšení nesdílí, ba právě naopak. Chrání si status quo. Každá změna pro ně znamená potenciální riziko, nebo alespoň více práce. A korporace jsou plné přepracovaných lidí, co kdysi možná měli ideály a chtěli změnit svět, ale časem se unavili, a spokojili se s tím, že chodí z meetingu na meeting a že to, co dělají, v rámci možností funguje. No, a v neposlední řadě je tu procesní mašinérie plná metodik, kterými se stejně nikdo neřídí, ale chcete-li změnu prosadit, musíte je změnit nebo rozšířit. A někde tady se rodí přesvědčení, že korporace agilní stejně nikdy nebudou. Budou, ale stojí to výrazně více úsilí než v garážovce. Asi tak jako projít mateřskou školou a úspěšně dokončit vysokou.

    Stačí se podívat kolem sebe – tedy do světa – a agilních korporací najdete spousty. Dříve byly také hierarchicky řízené, svázané mašinérií nesmyslných nařízení, které samy neznaly a nedodržovaly. Na lidi se dívaly jako na zdroje a iniciativa byla vnímána jako špatná. Upřednostňovali samostatnou práci jednotlivců, které micromanagovali do posledního detailu. Alokovali lidi na různé projekty na měsíce dopředu a na hodinu přesně. Pak se ale něco změnilo a firma, aby přežila, musela se změnit. A agile je jednou z cest, jak přežít v dnešním hekticky se měnícím světě. Jak se přizpůsobit. Jak být dostatečně flexibilní.

    Takže až zjistíte, že ten základní koncept sice chápete, ale že vůbec nevíte jak jej škálovat na více týmů nebo na celou organizaci, nevzdávejte to. Lidí, co mají s transformací takových organizací zkušenosti je ve světě dost, a soudě podle mě, často je taková práce i víc baví. Je to větší challenge, je to náročnější, je v tom větší riziko. Ale když se to povede, přináší to i větší uspokojení a výraznější výsledek. Divizi, ve které jsem poprvé byla součástí takové velké transformace, agile umožnil provést výrazný upgrade produktů a technologie, a v dlouhodobém horizontu zvýšil efektivitu více než dvojnásobně. O spokojenosti zaměstnanců a jejich nasazení ani nemluvě. U vás to bude jiné. Ale určitě bude výsledek stát za vynaloženou energii. A škarohlídům, co říkají, že korporace nikdy agilní nebude, nevěřte. Obvykle zjistíte, že vlastně v žádné větší firmě nikdy nepracovali, a tedy si ji neumí ani představit. Natož mít představu, jak ji transformovat.

    Agile Prague Conference je již za pár dní – 16-17/9/2013 …

    … a tak je na čase napsat, na co se můžete letos těšit. Ale než představím program, sluší se pro ty co konferenci neznají, představit i Agile Prague. Agile Prague Conference je první mezinárodní konferencí zaměřenou na agilní metody v Praze a tradičně patří mezi špičku co se programu týče. Je to již tradičně dvoudenní akce, kde se ve dvou paralelních sekcích dozvíte vše o Agilních metodách, Scrum procesu a Kanbanu, co jste chtěli vědět. Letos pořádáme již třetí ročník, a stejně jako předchozí roky počítáme s účastí přes 200 účastníků. A proč zahraniční? Protože český a slovenský trh je malý a naplnit kvalitní program z pouze lokálních speakerů není v zájmu kvality akce vůbec možné. To ale zdaleka neznamená, že jsme nedali prostor firmám působícím na českém trhu. V sekci praktických case-studies se s vámi o zkušenosti se zaváděním a aplikací agilních metod, Scrumu nebo Kanbanu podělí téměř výhradně zástupci lokálních firem.

    A teď již k programu 2013. Na úvod, museli jsme změnit prostory, přesídlili jsme se do sousedního OK Systému, od čehož si slibujeme větší přednáškové prostory a také lepší spolupráci s provozovateli. Díky tomu jsme byli schopni rozšířit dvě zmíněné přednáškové sekce o třetí, ve které pořádáme v odpoledních hodinách Open Jam session, kde máte možnost sami navrhnout téma a diskutovat ho pak ve skupinkách. Druhým podobným slotem je Coaching Clinic, kde budete mít možnost nechat si poradit od agilních koučů, alias našich speakerů v podstatě s jakýmkoli problémem, který ve firmě řešíte. Do této třetí sekce jsme zařadili i novou deskovou verzi Scrum hry – Tulming Travel Game, takže když už budete unaveni z přednášek, pojďte si s námi hrát. Kapacita je omezená, tak přijďte včas.

    V hlavním programu jsme i letos získali hvězdy agilního světa jako je David Hussman, Scott Barber, Kevlin Henney a nebo Pat Guariglia. David má letos i jednodenní tutoriál, který byste si neměli nechat ujít – Agile Product Design. Nechci vypisovat celý program, ale namátkou – Johannes Broadwall ukáže remote pair programming, Uri Nativ se zaměří na QA, Fred Williams na psaní User Stories, Gustav Bostrom na TDD, Andrea Provaglio přijede do Prahy již počtvrté, tentokrát s přednáškou Dreaming, Angel Medinilla vysvětlí roli Scrum Mastera, a spousta dalších, kteří budou mluvit o konkrétních praktikách, zkušenostech, Scrumu, Kanbanu, agilní transformaci… Ostatně přijďte se podívat. Taková příležitost se nebude hned tak opakovat – až zase příští rok – 15.-16. září 2014.