Agile | Zuzi's Blog o Agilu a Scrumu

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?

Jak si vyzkoušet Scrum v korporaci která není agilní

Zavádět agilní metody ve velké korporaci je těžší. Přinejmenším musíte pro agilní přístup nadchnout větší množství lidí, což dá více práce. V podstatě máte dvě možnosti. Buď svoláte velký meeting a na něm oznámíte, že od teď je vaše firma agilní a vše tlačíte silou, nebo budete agilní metody stavět od jednotlivých týmů a necháte lidi, aby si sami vybrali, jakou metodikou projekty chtějí řídit. Ze zkušenosti se dá říct, že fungují oba přístupy, což ale neříká, že oba budou fungovat pro každou firmu. Nakonec stejně časem zvolíte jistý mix obou krajních variant. Příkaz a rychlou změnu celé organizace na agilní si asi můžete dovolit, jen když jste si sami jisti výrazným přínosem takové změny a také když víte jak. Většina firmem si ale přechod na agilní organizaci moc představit neumí, takže začíná spíše opatrně.

Asi ideální je zlatý střed. Vybrat produkt, který bychom zkusili řídit agilně, najít vhodného Product Ownera a Scrum Mastera, vyčlenit ze standardní organizace vývojáře, analytiky a testery které plně alokujeme do pilotního Scrum týmu. Vyplatí se vysvětlit jim v 1-2 denním workshopu jak fungují agilní metody, na čem stojí, že je to spíše filosofie a změna myšlení než striktní proces. Aby to nebyla jen teorie, ale věděli i proč jednotlivé praktiky děláme. Když se tým již od počátku zapojí do vytváření Scrum procesu, přijde si sám na to jak proces adaptovat na své podmínky.

Když je i tohle pro vás nepředstavitelné, dosáhli jste správné úrovně klasického korporátu. Je zajímavé, že i drobná agilní změna zanesená do vašeho zaběhnutého systému může přinést ohromné výsledky. Většině týmů schází napojení na business, a protože pro ně není ze začátku snadné v korporaci udělat stabilní Scrum tým se vším všudy, začne standupy. Na začátek tam chodí jen členové IT týmu. I to je přínosné. Když se tým zaběhne, začne jim víc a víc vadit, že nemají přístup k nikomu za business a že zástupci businessu se standupů neúčastní. Tak je pozvou a oni po větším či menším protestování že na to nemají čas, začnou chodit. Obvykle je ale standup rozvleklý a technicky orientovaný, takže to naše zástupce businessu moc nebaví a brblají, že je to pro ně ztráta času. Z tohoto stavu obvykle vedou dvě změny. Vizualizovat lépe stav práce na přehledné tabuli a připomenout že standup je hlavně o commitmentu, tedy o tom co se dokončilo. A abychom mohli mít commitment kterému business rozumí, je dobře dělit práci na nějaké funkční celky které za nějaké fixní období – tedy Sprint dokončíme. Co se udělá, by se měl domluvit tým s businessem a ne si o tom rozhodovat sám jako doposud.

Je zajímavé, že i takováhle agilní ochutnávka stačí k tomu, aby tým začal fungovat výrazně lépe a vzbudilo to v jeho členech chuť zkusit další věci. Sami se ptají jak že se to ve Scrumu plánuje, jak se ohodnocuje, co je to UserStory, začnou dělat retrospektivu, hledat rovnováhu mezi tradičními projektovými funkcemi a nově definovaným rolemi a zkoušejí si, jak by Scrum v jejich prostředí mohl vypadat. Po nějakém čase je v organizaci dostatečně positivní atmosféra pro postavení plného pilotního Scrum týmu. A to je následně začátek přerodu v agilní organizaci.

Druhý ročník konference Agile Prague

Začnu řečnickou otázkou – proč vlastně pořádáme konferenci. První co se mi vybaví, je že asi proto, že nás to baví. Je to děsně práce, spousty emailů a s blížícím se termínem je toho víc než je zdrávo. Ale stejně jako loni, pak akce proběhne, my si odpočineme a začneme připravovat další rok.

Nechceme, aby konference byla jen o tom, že lidi přijdou a budou poslouchat přednášky. Všichni víme, že zkušenost je lepší než teorie a proto v rámci této dvoudenní konference bude mnoho workshopů a praktických ukázek jak agilní principy a metodiky aplikovat v praxi.

Na co se můžete těšit? Stejně jako loni budeme pokračovat v praktických case studies, kde se s vámi zástupci převážně českých firem podělí o své zkušenosti z nasazování agilních metod a Scrum procesu. Budou mluvit nejen o tom, co se jim podařilo, ale i o svých problémech a o tom jak je řešili. Součástí konference bude i diskuzní openspace zóna, kde po každé přednášce zastihnete speakery, kteří budou připraveni odpovídat na vaše dotazy. Těšit se můžete na zážitky a zkušenosti z Barclays (Let’s see what stuck, Agile at Barclays Capital), Seznamu (Size Doesn’t Matter, Seznam’s full text team and Scrum – new friends or arch-enemies?), IBM (What does good and bad smell like in the large?), LMC (Software tools and Scrum), Keria (Agile Testing – True Life Stories), CA (Stuck in the Middle with You – The life and times of a PO Proxy) a dalších firem.

Několik přednášejících si jistě pamatujete z minulého roku. Např. Andrea bude mluvit o agilním týmu, Gaetano o transformaci klasické hierarchicky řízené firmy na agilní. Někteří si možná vzpomenete na předloňskou agilní sekci WebExpa, kde byl jedním z nejlépe hodnocených speakerů David Hussman s jeho Dude’s Law. Letos na Agile Prague bude mluvit o tom, že spousta lidí aplikuje jen agilní názvy, zaštiťuje se s nimi bez hlubšího pochopení a čeká, že budou fungovat.

Vzhledem k tomu, že dva dny plné přednášek jsou opravdu náročné, i letos bude možnost si hrát. První den to bude simulace Scrumu v prostředí více týmů. Bude to určitě legrace, ostatně kdy jste naposled stavěli letadla z papíru. Druhý den bude nová Lego hra od Thorstena, ti co se loni zúčastnili, ji jistě doporučí a určitě si hru ani letos nenechají ujít.

Čím bude tento rok jiný? Snažili jsme se program udělat pestřejší a zapojit i vývojáře a testery. A to nejen teoreticky. Zmíním v tomto kontextu Johannese, který kromě dvou technicky orientovaných přednášek má i třetí den konference workshop Coding Dojo. Dále Ola, který vám ukáže jak naložit s velkým množstvím legacy kódu. Danko bude mluvit o rolích managera, testera a vývojáře v agilním světě, a Kevlin o tom jak dělat kvalitní software.

Další zajímavou praktickou ukázkou je simulace, jak funguje motivace od Joakima, kterého si možná také pamatujete z loňska. Určitě se ani takhle pozdě odpoledne nebudete nudit.

Dva z nejuznávanějších světových odborníků budou třetí den (tedy 5.9.) dělat specializované workshopy. První je zaměřený na komunikaci se zákazníky který vede Linda Rising a druhy primo pro vývojáře a testery od již zmíněného Johannesse Broadwella. Je to unikátní možnost, která se příště již nemusí opakovat. Musím říct, že letos se nám překvapivě podařilo získat skvělé experty z celého světa kteří mají za sebou mnoho zkušeností od malých projektů až po velké státní zakázky. Řekla bych, že získat takové lidi jako máme letos, je spíše výjimečné. Například Linda příliš do Evropy necestuje, v tomto případě nám pomohlo to že se vždycky chtěla podívat do Prahy… A podobné to bylo i s mnoha dalšími přednášejícími.

Jaká další témata se na konferenci objeví?
Tony bude mluvit o tom, jak vypadá agile ve velkých korporacích, Pat o tom jak scrumem řídit velké státní zakázky. Chris a Olav dokonce kreslí agilní komiks na téma, které představí v keynote – Real Options.

Na závěr mě ještě napadá Jurgen a jeho skvěle připravená přednáška Jak změnit svět. Na konferenci budeme mít několik jeho knih jako dárek pro vylosované účastníky. Pro ty, co by nebyli mezi šťastnými, nabídneme pár výtisků za zvýhodněnou cenu.

A je toho mnohem víc. Ostatně posuďte sami. 🙂

Na závěr – kdy kde co
Konference Agile Prague se koná 3-4. Září 2012, a i letos bude v konferenčním centru v Praze na Pakráci. Detailní program a další informace naleznete na stránkách konference agileprague.com.

Ještě jsem zapomněla dodat, že přednášky jsou všechny v angličtině, nepřekládáme je, a po oba dny si můžete vybírat ze dvou paralelních tracků, takže se určitě nebudete nudit.

Těším se na setkání na konferenci.

Je Scrum jen pro male firmy?

Jak se poslední dobou pohybuji ve větších firmách, setkávám se často s názorem, že Scrum je jen pro malé firmy. Tak se pojďme podívat, co se tím v reálu myslí. V korporátech se často objevuje pojem “ideální Scrum“, čímž je míněno prostředí kde je jeden tým, jeden Scrum Master, jeden Product Owner a žádné závislosti. Všichni plně alokovaní, pracují na něčem, co ideálně vytváříme od nuly a co s ničím dalším nesouvisí. Takové jednoduché. A druhým dechem dodávají, že to my v naší organizaci nemáme, my máme ty velké integrační projekty a na nás se agilní metody nehodí. No ostatně každý důvod se hodí, když se chceme bránit změně. Začínala jsem se učit Scrum ve velké korporaci, která měla několik divizí, IT v řádu jednotek tisíců, outsourcing/offshoring a distribuované týmy. A viděla, co se stalo po transformaci na agile a Scrum. Výrazný nárůst efektivity, kvality, zastupitelnosti. A to vše ve velice komplexním prostředí mnoha souvisejících produktů a specifických technologií napojených na vlastní HW. Nebyly to žádné malé internetové projektíky. Proto tomuto argumentu českých firem moc nerozumím.

Ale pojďme se podívat, proč by v prostředí velké korporace mohl být Scrum a agilní metody prospěšné. Takovéhle velké firmy často dokonvergují k zajímavé organizační struktuře. Mají oddělené IT a business. Moc spolu nemluví, moc se nemají rádi. Business dává velice volně definované požadavky – slovy IT neví, co chce – a to IT má na jejich řešení málo kapacit a nestíhá. Všechno je pozdě. A ještě často dodá něco jiného. Takové firmy se snaží tuto nefunkčnost různě házet jeden na druhého. Ti co se na to dokáží dívat s nadhledem, často říkají “Máme velký problém v IT, který ale neleží v IT.“

Jak je business hodně daleko a nemá obvykle příliš motivaci se do projektů zapojovat, tak se týmy obklopí armádou business analytiků, kteří se snaží požadavky businessu dodefinovat a interpretovat IT světu tak, aby pro ně byly srozumitelné. A protože oni za úspěšnost projektu nenesou žádnou zodpovědnost, tak požadavky nijak neořezávají, ba právě naopak. Oni jen plní přání businessu. A rozmýšlí, jak by se taková věc mohla chovat. A tak IT roste a roste a překvapivě pořád nestíhá tu spoustu požadavků businessu zpracovávat. A kdyby mohlo, sedí ve všech budovách a kancelářích po celém městě.

Agilní metody a Scrum proces se snaží organizovat týmy po produktech, ne po technologiích. Základní výhodou potom je, že to co se dělá, není rozhodováno IT nebo analytiky, ale businessem který u každé funkcionality zvažuje, jestli se jim vyplatí do ní investovat energii týmu/peníze. U každé funkcionality se zamyslí nad tím jaký má očekávaný přínos a jakou “pokutu“ bychom ev. platili za její absenci a jestli nám to celé stojí za to. Na to se hodí koncept User Stories (určitě si vzpomenete na zkratku INVEST která je v tomto kontextu docela výstižná). Tohle je tedy kromě lepší komunikace mezi IT a businessem, vyšší motivací a vyšší zastupitelností asi hlavním důvodem pro vyzkoušení agilního přístupu. Říká se, že firmy, které takto řídí svojí funkcionalitu, mohou ušetřit až 80% effortu. Určitě to neplatí plošně, ale podívejte se kolem sebe. Kolik funkcionality se opravdu použije a vyplatí? Kolik toho všeho na čem pracujete, by šlo zjednodušit, kdybychom rozuměli tomu, proč to vůbec děláme. A co by šlo v konečném důsledku úplně nahradit…

Řekněme tedy, že jste mi uvěřili, že by to mohlo mít smysl. Co dál? Jak zformovat stabilní tým v prostředí stovky integrovaných systémů, kde se IT skládá z mnoha isolovaných úzkých specialistů a systémy tvoří chobotnici vzájemně provázaných funkcionalit s množstvím legacy kódu, kterému již nikdo nerozumí? Kupodivu to jde snáze než byste si mysleli. V reálu obvykle dojdete k tomu, že tím, že se začnete na systémy dívat z pohledu businessu, uděláte v podstatě vertikální strukturu proti současné horizontální. Je to jiný pohled. Některé produkty spojíte, jiné rozdělíte, ale ve finále se vždy přijde na to, že systém jde relativně snadno rozřezat na funkční logické produkty, kde je možné stanovit Product Ownera, který má zodpovědnost za návratnost a úspěšnost produktu. Není na to sám, pomáhají mu ostatní kolegové z businessu, business analytici a IT architekti jako doposud, ale je tu někdo, kdo je stabilně zodpovědný za produktovou linii. Dělá jen to co má smysl. Co se vyplatí v dlouhodobém horizontu. To je první část úkolu. Druhá část sestává z definování stabilních Scrum týmů. I to není tak složité, jak by se mohlo zdát. Tým musím obsahovat znalosti klíčových technologií, systémů a architektury. Ale když to zkusíte, zjistíte, že vaše současná chobotnice složená z nenahraditelných a nezastupitelných částeček jde obvykle rozdělit na týmy o cca 7-10 lidech, které jsou schopny většinu práce na nově definovaném produktu udělat sami. Co zbyde, si buď objednají zvenku, nebo se naučí. Větší produkty budou implementovat skupiny 1-4 stabilních týmů, menší projekty se dají sdružit pod jednoho Product Ownera, který má jeden takový tým. Zní to jako utopie, ale zkuste to. Zatím jsem nepotkala firmu, ve které by to nešlo.

Co je na tom nejtěžší? Uvěřit, že i v takto složité a komplexní firmě je to možné. Uvěřit, že by nám taková změna mohla výrazně pomoct. Začít budovat kulturu zodpovědnosti, posílit důvěru, a podpořit transparentní komunikaci v rámci celého systému. Zní to jako fráze, ale funguje to. Je to těžká a zdlouhavé práce. Příjemné je, že jakmile začnete, vaše snaha velice rychle přinese své ovoce a lidem se po prvotní vlně odporu nový proces zalíbí. V ten moment začne být vaše snaha o změnu nakažlivá a vy máte o kousek práce míň.

Jak zabít Scrum

Najdete spousty článků jak být agilní, jak Scrum úspěšně nasadit… ale ve spoustě firem řeší naprosto opačný problém. Jak zabít Scrum. Dělám si trochu legraci, ale občas to tak vypadá.

Takže jak na to. A přidejte se s nápady a komentáři. Co dělat, aby to spolehlivě zabilo Scrum. Co napadne každého, je postavit silného šéfa co rozděluje práci a alokace a o všem musí rozhodnout. Najdete spoustu takových nápadů. Ty jsou zřejmé a jsou moc vidět navenek. Bijí do očí. Dá se proti nim bránit. Mám vypozorovnu lepší metodu jak nasadit Scrum bez toho, aniž bychom se museli bát, že se osvědčí. Je to snadné. Naučíte se pár pojmů. Scrum = to je náš nový proces, nebojte se, nic moc se tím nezmění. Sprint = to je jakési období, za které máme něco dokončit. Když to nestihneme, prodloužíme Sprint třeba na třičtvrtě roku. To by bylo, abychom to nestihli. Máme přeci komplexní produkt. Backlog = requirementy a usecasy. To máme, nemusíme tedy nic měnit. Business na nás stejně nemá čas. Nezajímá ho to. Tak se o Backlog stará armáda Business Analytiků. Mají toho moc, ale nakonec to rozmyslí dobře. Body = Divný. Mandays nám vyhovují, jsme na ně zvyklí, tak proč přeházet na body. Standup = to je taková pěkná praktika. Pojďme se každý den sejít a popovídat si. To se ve Scrumu dělá ne? Lidi alokujeme na plno projektů najednou, tak ať se jednou denně vidí. To bude stačit. Tým = skupina specialistů, co věří, že ostatní by v žádném případě nezvládli to, na čem oni pracují. Jsou přeci specialité – na danou oblast, nebo technologii, nebo oboje. Tak co bysme jako sdíleli a jak bysme si pomáhali, že..

Povědomé? Na zabití Scrumu stačí spolehlivě dvě věci. Začít používat názvy bez porozumění a obsahu. A podpořit to zdlouhavým pravidelným Stand-up meetingem bez závazku a bez týmové spolupráce. A věřte či ne, za pár týdnů ani největší optimista neuvěří že Scrum je pro vaši firmu vhodnou metodou.

XP2012 Malmo a GOTO Amsterdam

Dvě konference a každá jiná. Těžko říct, čím to je. Asi organizátory. XP bylo v nedostavěném konferenčním centru za městem, ve kterém se účastníci ztráceli, jak jich bylo proti loňskému roku v Madridu málo. Organizace vázla, vstupné předražené a speakeři neuměli příliš mluvit. Až na vyjímky, kterých bylo žalostně málo. Stálicí XP byl David Snowden. Myslím, že jako obvykle měl nabitou přednášku informacemi. Jak psal někdo trefně na twitteru, “asi je geniální, ale zase jsem ho nepochopil…“. Nicméně i tak to bylo poučné. Poslechla jsem si jeho talk vlastně dvakrát, protože byl na obou konferencích a myslím, že bych ho ještě párkrát snesla. Zajímavý byl už první z jeho slidů: Exaptation vs. Adaptation tedy rozdíl mezi exaptation (nepodařilo se mi najít český výraz) a adaptací … Kdy adaptace se dá popsat jako schopnost vysoce specializovaných lidí své znalosti použít a změnit se, kdyžto exaptation je schopnost použít něco co bylo původně pro jiný účel na něco zcela jiného. Ukazoval obrázek, kde lidé při častých záplavách zjistili, že minimalizují škody, když auto zabalí do igelitového pytle. Ten igelit tu byl i předtím, ale takové jeho použití rozhodně nebylo běžné ani obvyklé. Když s tou úvahou jdeme dál, dá se říct, že Apple dělá přesně tohle, neptá se zákazníků, co chtějí, ale změní jejich chování a vnutí jim používání věcí zcela jiným způsobem. David na to říkal, že je to klíčový skill, který by úspěšné firmy měly mít a své zaměstnance by proto k tomu měli vést. Napadlo mě, že je to i jeden z důvodů, proč se snažíme agilem zapojit lidi do procesu a vymýšlení produktu. Chceme, aby něco takového také dokázali. Aby nám pomohli. Na rozdíl od klasických metod, které podporují v lepším případě jen proces adaptace, agile umožňuje i exaptation.

Ještě jednu měl myšlenku. Že bez ohledu na ohromné PR Scrum Alliance a přání některých firem, po dvoudenním kurzu s multichoice testem se nikdo masterem (tedy ani Scrum Masterem) nazývat nemůže. S tím se dá jen souhlasit. Certifkace jsou prostě jen velký business a tahání peněz z lidí. Kvalita trenérů, Scrum Masterů ani Product Ownerů se certifikací nijak nezvyšuje. Dobré lidi najdete s certifikací i bez. Cerifikace se tedy zatím nedá brát ani v přeneseném slova smyslu jako řidičský průkaz na Scrum. Ale to asi nikoho nepřekvapuje. Dave tím pokaždé rozesmál sál. Ale asi to žádný velký vliv na tuhle pěknou mašinku na peníze mít nebude.

Druhým kdo mě zaujal, byl Todd Little. Přednášel krátký report o review Agile Alliance. Co všechno je takový ten “slon v místonsti“. Tedy něco co tu je, ale nikdo to nevidí a nevšímá si toho. Přišli jsme na to, že Agilní Aliance je takový slon. Utváří prostor pro agile, pomáhá mnoha konferencím po celém světě, ale vlastně se o ní moc neví. Nenutí se nikomu ani neříká my jsme ti jediní co máme právo říkat co je a není agilní. Prostě takové příjemné sdružení lidí. Už se těším do Texasu na Agile 2012 kde mám v létě přednášku. Jestli tam takových lidí bude víc, bude to moc príma konference bez ohledu na to že má na můj vkus trochu příliš moc účastníků. Masovka. Ale uvidíme.

Pár dalších z popsaných slonů v místnosti je že velká část komunity předstírá, že agile není business. Že si jen tak budeme pomáhat a všechno bude najednou skvělé. Nebo to, že manažeři jsou všichni špatní. A zrovna tak distribuované týmy. Ale ty asi jen tak v tomto globálním světě nezmizí. Na závěr říkal, že agile se musí přizpůsobit kultuře výrazně víc, než se kultura musí přizpůsobit agilu. To možná spousty firem potěší.

GOTO Amsterdam oproti tomu bylo moc příjemné. Pořádané v centru Amsterdamu, v krásné budově. Bylo moc fajn. Byla jsem bohužel jen na polovině konference, ale všechny přednášky – až snad na tu poslední, byly nadprůměrné. Greg Young měl skvělou přednášku na téma “Developers Have a Mental Disorder“. Čím mě zaujal nejvíc? Asi tím že říkal, že každý vývojář by se měl na chvíli stát podnikatelem, a zaměstnat někoho komu by platil cash, aby za něj psal kód. Pak by totiž konečně pochopil stranu businessu a byl schopen se lépe rozhodnout který refactoring je opravdu, ale opravdu potřeba. Zkuste si to byť i jen jako mentální cvičení. Možná, že změníte názor na závažnost technického dluhu.

A na závěr, už během několika málo dní začneme prodávat registrace na Agile Prague Conference, která se koná 3-4. září a letos je doplněna i o den workshopů s nejlepšími speakery. Kapacita je omezená, tak si to nenechte ujít.

Ú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:

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.

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.

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.

Agile Riga Day

Rok se s rokem sešel, a tak jsem se zase objevila na Agile Riga Day, příjemné jednodenní konferenci v Lotyšsku. Letos se organizátorům podařilo zdvojnásobit počet účastníků, a rozrostli se na tři tracky. K tomu jsem ještě měla jednodenní workshop, “Starting Scrum“, takový den plný her, simulací a diskuzí. Bylo zajímavé, že slečny převládaly, ostatně i na konferenci den poté jich bylo výrazně více, než bývá v Evropě zvykem. Ale přeci jen méně než na Agile India. Překvapilo mě i to, jak rádi si analytici, kterých jsem na workshopy několik měla, hráli. U nás mám s analytiky spíše opačnou zkušenost.

Riga a vlastně i Lotyšsko má jedno další specifikum. Je hodně navázané na Skandinávii, takže mám pocit, že jsem byla jedním z mála lidí co nebyli z pobaltsko-skandinávské oblasti. Převládali Švédové, Norové, Estonci. O čem se hovořilo? O tom jak psát dobrý kód, jak dělat refactoring, jak naložit se starým legacy kódem, jestli dělat test driven development, nebo pair programming… výborný workshop na toto téma vedl Johannes Brodwall – Extreme Startup. Moc se mi to líbilo. Už dlouho jsem neviděla na konferenci pair programming v praxi. Bylo zajímavé to sledovat.

Hodně se diskutovaly odhady. Vlastně, začali jsme s tím tématem už den před konferencí v místním baru. K pochopení základního problému s odhady je nutné si uvědomit rozpor mez i tím, co odhady jsou – tedy nepřesná predikce budoucnosti – nijak exaktně přesná být z principu věci ani nemůže, od toho je to odhad. A jistá představa managerů některých firem, že odhad musí být naprosto přesný. A když k tomu dodáme nepříjemný pocit členů některých týmů, že jsou tlačeni do něčeho, co není možné dodat – tedy do stoprocentně přesného odhadu, máme tu problém, který se dá dlouho do noci vášnivě diskutovat. Obzvláště když jeden z diskutujících má ráno na dané téma keynote kde v podstatě říká, že odhady v bodech jsou stejně tak špatné, a nepřesné, že zrovna tak můžeme každý Sprint jen počítat dokončené a nedokončené User Story a odhady nedělat vůbec. Příště o tom třeba napíšu víc.

Dalším tématem, které mě zaujalo, byla myšlenka, že na to, abyste změnili svět, třeba na agilní, je třeba si uvědomit že “nemusíte systém řídit, stačí s ním umět tančit“. Možná že to je jedna z věcí, které musí umět každý Scrum Master, a asi nejen on. Nestačí vědět, jak okolní svět funguje, musíte vyvinout něco, co se bude chovat jako virus. A takový virus potom do okolního, neagilního, světa pustit.

Abych to shrnula, myslím, že všechny praktické sessions pro programátory a testery se osvědčili, a že mám zase pár dalších kontaktů a nápadů na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Konference Agile India 2012

Kolik z vás navštívilo konferenci zaměřenou na agilní metody v zahraničí, a kolik z vás v Indii? Cestuji ráda, takže se to zdálo být jako dobrý nápad. Navíc, chystala jsem se do blízké oblasti na dovolenou, tak proč ne 🙂

Jestli byste čekali, že Bangalore – Mekka IT outsourcingu – bude podobné moderním asijským městům jako Singapore, Kuala nebo Bangkok, tak to ani nápad. Žádná wifi, přelidněné město, všude smetiště a špína. Prostě Indie. Říkala jsem si tedy, že na konferenci uvidím ty IT odborníky, kterých má být Bangalore plné, a že třeba pochopím, proč si velké firmy vybrali pro outsourcing zrovna Indii. Myslím však, že to ani firmy samy nechápou. Jistě, je tu nízká cena. Ale ta je draze vykoupená nízkou kvalitou služeb a ohromným overheadem spojeným s řízením takto distribuovaného projektu.

Takže o čem se přednášelo? Základy, které i v zemích kde se s agilními metodami začíná už dávno znají. Tedy nic, co by stálo za zmínku. Témata, která se řešila, už byla zajímavější. Třeba že Indie je země s nejvyšším indexem “vzdálenosti od zákazníka” – tedy laicky řečeno, na zákazníka kašlou. A taky distribuované týmy a kulturní rozdíly. Zajímavé bylo, že Indové jsou přesvědčeni, že zákazník, když s nimi chce spolupracovat, se jim musí plně přizpůsobit. Třeba není vhodné od nich očekávat, že vám řeknou, jak se věci mají. Budou kývat hlavami, a to, že projekt má problém, se nedozvíte. Když na to jeden ze speakerů narazil, dostal udivenou odpověď z publika, že to je přeci v pořádku, oni si to mezi sebou poví, ale někomu cizímu, to přeci neřeknou. Další z legračních situací popisoval jiný speaker. Proškolili indickou firmu na Scrum, vše se zdálo být v pohodě, ale jen do té chvíle, než představili nové role. A kdy nový Scrum Master říká že se mu Scrum líbí, že mu rozumí, ale jestli si může dál říkat project manager, že by tím že je teď jen Scrum Master utrpěl jeho status a jak by pak před kolegy a rodinou doma vypadal…

Jak tedy chcete v tomto kastovním systému zavádět agilní metody založené na týmové spolupráci, zapojení zákazníka a transparentní komunikaci? Jak chcete dosáhnout self-organized týmu? Těžko. Někdo to na konferenci pěkně shrnul na twitteru: “Outsorcing v Indii je levná možnost jak nechat zkrachovat svůj produkt”. A asi s ním musím souhlasit. Ostatně většina firem už na to přišla také a tak Indii svěřuje v podstatě dva typy projektů. Výběhový SW, který sice musí udržovat, ale nejradši by se ho zbavili, a testování. Ostatně spousta firem netestuje vůbec, tak proč to nedat levně do Indie. I to má však jeden háček. Tím prvním můžete současné klienty odradit a přijít tak o více peněz, než by se z ceny outsourcingu původně zdálo. A co se kvality týče, jak chcete nechat testovat produkt lidem, kteří žijí v souvislém smetišti. Tester musí být precizní, vidět i drobné nesrovnalosti… A to lidé v Indii obvykle nevidí. Prostředí deformuje. Ostatně i mě po třech týdnech v Indii přišlo, že je tam uklizeno víc, než když jsme přijela… Na všechno si člověk zvykne.

Asi nejlepší byla přednáška o distribuovaných týmech kde Alexey Krivitsky pěkně popisoval jak se s takovým prostředím vypořádat. Doufám, že se nám podaří ho nalákat na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.