Tag: Management

Procesy a metriky deformují lidi

Čím více chodím po firmách, tím více docházím k tomu, že existuje jasná rovnice. Čím striktněji nadefinované máte procesy, tím méně je ve firmě inovace, otevřenosti, důvěry, motivace, iniciativy, spolupráce. Lidé sedí a čekají, až dostanou úkoly. Bojí se ozvat, starají se jen o to, jak naplní metriky. Produktivita klesá, a čím více klesá produktivita, tím více metrik vzniká. Co neměřím, to neřídím.

Agilní metody to dělají jinak. Místo striktního procesu jen vymezují hřiště. Definují týmům i jednotlivcům pouze mantinely, které by se neměly překračovat. Už jen agilní manifest. Neříká takhle přesně vypadá/nevypadá dokumentace, ale “upřednostňujeme funkční produkt před vyčerpávající dokumentací“. Tedy jediné co říkáme je, že “je to o produktu, ne o dokumentaci“. A nepřímo i to, že dokumentace je důležitá, ale komunikace je důležitější. Tedy, určitě dokumentaci dělejte, ale asi není třeba ji mít sepsanou do posledního detailu, sepište jen to, co opravdu bude někdo potřebovat. Zdánlivě tedy neradí nic. Je to common sense. Selský rozum. Na ten jsme ale při našem pracovním vytížení často zapomněli. Agilní procesy nás vrací tam, kde jsme kdysi byli. Tam, kde věci fungovaly i bez detailních metrik a přesně definovaných procesů.

Jak takové metriky často vypadají? Pár historek pro příklad z poslední doby…

Počet řádek kódu. Ta patří k mým oblíbeným. Musíme přece vědět, který vývojář je lepší než ten jiný. No ne? Jak bychom to jinak zjistili? A jak bychom docílili toho, že vůbec něco dělají. Tedy důvěra: nula. Spolupráce: ani vzniknout nemůže. Protože pak bych kolegovi pomohl k lepší výplatě, což o to, ale sobě tím pádem k horší…

Počet testů, pokrytí testy. Zdánlivě smysluplná. Ale jak jistě testeři potvrdí, zcela nevypovídající. Tedy končí tunou testů. Test máme na všechno, co jde. Obzvláště na ty jednoduché věci. Tam počet přibývá nejsnáze. A protože testování nikdo kromě testerů nerozumí, jediné, co manager honí, je procento pokrytí. A má dobrý pocit, že roste. Jenže ty testy musí někdo udržovat, a to stojí energii. Zbytečně investovanou hned dvakrát. Jednou u vzniku testu, který není až tak klíčový a podruhé opakovaně při libovolné změně systému. Cílem firem, které to pochopily, již dávno není 100% pokrytí testy, ale funkční produkt. Psát jen ty testy, které mají pro nás smysl a potřebujeme je.

Počet reportovaných chyb. Zdánlivě správná metrika. Když ale přitvrdíte, a začnete ohodnocovat testery podle počtu nalezených chyb a vývojáře podle stejného počtu penalizovat, dojdete k tomu, že tyto skupiny mají zcela odlišné cíle. A to, že by spolupracovaly již v průběhu na kvalitním vyřešení User Story je v nedohlednu. Jen ať tam ty chyby udělají. Alespoň je snadno najdeme. A z druhé strany tento přístup generuje nekonečné a často úspěšné diskuse typu: “ne,ne,ne, to není chyba, tu já jako vývojář neakceptuji, to je change request, nebo chyba testu, ale rozhodně ne chyba kódu. Kdepak.“ Frustrující.

Čas na dokončení tasku. Obvyklá věc, že? Jak jinak byste věděli, jestli závazek ve Sprintu stihnete nebo ne? Potřebujete mít přeci jistotu! Ale ono to nikam nevede. Jistota je jen pofidérní. Navíc, takové výpočty stojí spoustu času, který by šel smysluplněji investovat jinak. Stačí přece práci rozdělit na menší kusy a ty přehledně zobrazit na tabuli. A vnímat funkcionalitu jako celek. Ne jako jednotlivé části. Příště o tom napíšu víc.

Sprint Burndown. Obdobně zbytečný jako reportovat čas potřebný na dokončení tasku. Když k němu přidáme tlak na to, aby vypadal “pěkně“, často dojdeme k tomu, že tým reportuje za každý den 8h*počet členů. Tolik času jsme přeci na táskách strávili, ne? Graf má krásný lineární průběh, ale vypovídající schopnost je nulová.

Velocity musí být nějaké konkrétní číslo. Třeba řekněme 22. Jinak tým funguje špatně a málo toho udělá. No tak proč ne, stačí říct a my budeme ještě lepší. Prostě jen začneme ohodnocovat User Stories jinak. Nebo rovnou celý Backlog vynásobíme 100. Jo, to že nesmíme? No tak jo, ale ono se to za nějaký čas objeví na kvalitě. Technický dluh je moc príma. Jeho odstranění je ještě dražší, než to, že si dáte pozor, aby nevznikl .

A pokračovat bychom mohli dalšími složitostmi, jako detailními výkazy o tom, co kdo přesně kterou minutu dělal, nebo kvótou na počet business bodů, které tým musí doručit. A přitom nic z toho není potřeba. Nevěříte? No těžko vás budu přesvědčovat takhle od stolu. Zkuste to. Zeptejte se firem, co to dokázaly.

Obecné doporučení je, že je dobré něco měřit, ale libovolná metrika musí být jen indikátor, ne cíl, pravidlo, modla. Nelíbí se vám velocity? Mysleli jste si, že by tým toho měl doručit více? No tak se podívejte čím to je. Najděte příčinu, ne důsledek. Libovolné tvrdé metrice se tým přizpůsobí a upraví své chování tak, aby metrika vyšla. Některé firmy je proto často mění, aby to týmy nestíhaly. Jiné pochopily, že o problémech je dobré vědět, a jsou rády, že je pomocí soft metrik vidí.

Druhá rada říká, nebabrejte se v detailech. Stojí moc energie a ztratíte se v nich. Všechno je vidět z jednoduchých trendů. Obvyklé věci se totiž dějí obvykle, výjimečné výjimečně. A na velkých číslech, jako je např. velocity za tým a sprint to vychází. I těch neobvyklostí nám za tým a Sprint přijde pokaždé stejně. Jedna User Story byla podhodnocená, jiné dvě nadhodnocené, jeden onemocněl, dalšího bolela hlava, někomu to zas výborně šlo od ruky. Tedy, když přestanete řešit detail, jako je počet hodin na tasku, ale podíváte se jen na velocity, dozvíte se z trendu přesně to, co potřebujete.

Tvrdé metriky a detailní procesy zabíjí tvořivost, inovace, náladu. Končí tak, že produktu nikdo nevěří, z těch úžasných vývojářů, analytiků a testerů, co mnohdy mají několik titulů a jsou nadprůměrně inteligentní, se stávají dělníci u pásu. Zombie bez energie. Udělejte si test. Zeptejte se vašich zaměstnanců, proč pracují. Ti, co jsou tam jen pro peníze, berou práci jen jako nutné zlo. Hlídají si spokojeného šéfa a metriky. Schovávají se za procesy. Vymlouvají se. Jak malé děti. Děláme přece přesně to, co řeknete. Tak nás nechte, a plaťte nám. My máme hypotéku. Uvidíte nás tu maximálně od devíti do pěti, a když tu není šéf, tak jen do čtyř. Přesně podle pracovní doby. Ti druzí, u těch je na prvním místě práce, která má smysl, svítí jim očička, jak tuhle říkal jeden jejich manager. Zajímají se, jsou schopni se zdravě pohádat o řešení, nebojí se říct svůj názor. Mají společný cíl. A tím není mít víc peněz. To je důsledek jejich přístupu, který zákonitě přijde. Kde byste chtěli pracovat vy?

Agile tohle prostředí mění. Mohlo by se sice změnit samo, i bez agilních přístupů, ale často je k tomu nějaký nový label potřeba. Překvapivě, velká část týmů, které dnes coachuji, řeší přesně tento problém. Výhodou je, že že změna přichází rychle. Nabaluje se to jak sněhová koule. Přitahuje to. Ale začátky jsou obvykle o to více bolestivé.

Všechno je o self-organized týmu

Byla jsem si na na přelomu roku odpočinout na Filipínách. Potápění, krásné resorty na pláži. Ale proč o tom píšu. Jak jsem tak sledovala práci třeba Moniky, belgické manažerky prvního dive resortu kde jsme se objevili, nemohla jsem se zbavit dojmu, že tuhle práci bych prostě dělat nemohla. Neustálé upomínání lokálních děvčat co mají dělat, jak to mají dělat, neustálá kontrola. Místní expati říkali, že Filipínci prostě takoví jsou. Řeší jen aktuální okamžik, když se jim zrovna nechce, tak do práce nepřijdou. Kvalita jim nic neříká, vždyť na tom přeci nezáleží. Že namontovali umyvadlo křivě? Vždyť ta voda z kohoutku teče, tak co. Všichni se shodovali na tom, že se musí neustále kontrolovat, hlídat, a že to chce tvrdou ruku. Není to o penězích. Peníze dostanou, utratí, a už další den z nich z nic nezůstane. Ani ta radost, nic. Například když dáte opraváři střechy velkou zálohu, že práci chcete rychle a vám prší do domečku, tak čím větší ta záloha byla, tím déle trvá, než opravář nakonec dorazí. Slibuje, že už zítra, ale takový slib nic neznamená. A tak všichni majitelé resortů aplikují cukr a bič, definují jasné role, pevné procesy. Výsledek takového řízení je v zásadě ok. Nakonec člověk je na dovolené, tak nějaké ty nedostatky bere jako místní kolorit a nijak zásadně to nevadí…

Na poslední týden jsme si vybrali takový malý resort. Vlastnili ho Dánové. Opuštěný ostrov někde v moři. Nádherné místo. Po pár dnech mi začalo vrtat hlavou, co je tady jinak. Že by si Dánové uměli lépe vybrat a našli si motivovanou pracovní sílu? Že by tady bylo jiné etnikum? Pracovitější? Rozdíl byl ohromný. V kuchyni a na lodi samá legrace, úsměvy, a služby v podstatě perfektní. A žádná viditelná kontrola. Takže ono by to nakonec nebylo Filipínci? Poslední den jsem si povídala s jedním z majitelů a ptala se, jak to dělá, že sehnal takové dobré zaměstnance, že mu resort funguje výrazně lépe než jiné, které jsme cestou potkali… A k mému ohromnému překvapení říkal – my jsme z nich udělali tým. Dali jsme jim zodpovědnost a jistou volnost. Neřídíme, kdo má přesně co dělat. Bereme je jako sobě rovné. Chodíme do kuchyně, děláme si legraci, smějeme se. Když mají problém v rodině, pomůžeme jim. Vyjdeme jim vstříc. Třeba například zítra je tu fiesta. Ohromný svátek. A oni se ptali, jestli je pustíme, jestli smí jít. No, když se vrátí ráno včas, aby připravili snídani, tak ať jdou a diskotéku si užijí. Ostatní resorty je nepouštějí, protože by druhý den nikdo nepřišel. My dneska nemusíme osobně jezdit pro hosty do města. Můžeme tam poslat někoho z našich zaměstnanců. A to nám ohromně uvolnilo ruce. Máme čas i pro sebe…

Aha. Nevím proč, ale přišlo mi to povědomé 🙂 Jinými slovy, všechno je to o schopnosti tvořit týmy. Dát lidem zodpovědnost, a možnost se rozhodnout. Self-organized tým (nebo samoorganizující se tým, chcete-li). Výsledek je ohromující. A jak se ukazuje, v každém prostředí. Lidé budou tak dobří, jak dobří jsou ve vaší představivosti. Manager, který si myslí, že jeho zaměstnanci jsou pitomci a nikdy neudělají nic pořádně, s nimi bude zápasit a bude mít problémy. Ten kdo jim věří a bere je za své partnery, bude mít výrazně více úspěchu.

Jak vypadá Scrum, jak Scrum Master, jak má Scrum Master motivovat tým a jak řídit produkt

Jsou to zdánlivě nesourodé otázky, ale dalo by se říct, že po shlédnutí příslušných videí budete vědět, jak vlastně agilní metody fungují.

Jak vypadá Scrum?

Začneme krátkým úvodem Scrum ve 13s.

Že jste se toho moc nedozvěděli? Pusťte si video ještě jednou, a zjistíte že Scrum je iterativní proces, v každém cyklu dodává nějakou část, která má hodnotu. Zjistíte, že existuje něco jako Product Backlog, ze kterého se před každou iterací vybere pár celků, které tým v jednotlivých dnech zpracovává a které na konci iterace dodá jako hotové a nasaditelné. Na dokončené kousky se dívají ti, co k produktu mají co říct, tedy zákazníci, business, uživatelé a z jejich zpětné vazby vznikají požadavky na změnu, nové funkcionality, či funkce které můžeme oželet a ty se hned promítají do Product Backlogu. To je na 13s vaší pozornosti informací až až.

Kdo je to Scrum Master a jak spolupracuje s týmem?

Video má tentokrát asi 5min a uvidíte v něm jak se Ian jako “Super Scrum Master“ stará o svůj tým. Že byste to dělali jinak? Proč ne. Podstata je ale stejná. Všichni včas na Standup, nerušit tým změnou priorit, dodržovat done kritéria, brát testování jako součást úlohy. Scrum Master musí dělat to co je potřeba. Je coach a facilitátor. Je to o týmu. Ne o Scrum Masterovi. Ale bez dobrého Scrum Mastera nikdy nebudete mít dobrý tým.

Jak má Scrum Master motivovat tým?

A jak je téma složitější, prodlužuje se délka videí. Tohle je na přibližně 20min, ale opravdu stojí za zhlédnutí do konce. Přesně takhle totiž funguje motivace. Italy Talgam demonstruje na ukázkách různých dirigentů a orchestrů jak funguje leadership. Ve kterém orchestru byste chtěli pracovat? A který dirigent by byl dobrým Scrum Masterem? To určitě posoudíte sami.

Jak řídit produkt?

Poslední video je nejdelší, ale také je více nabito informacemi. Vytvořil ho Henryk Kniberg a myslím, že stejně jako jeho knihy Scrum and XP from the Trenches nebo Kanban and Scrum – making the most of both je i tohle velice pěkně vytvořené video kde se dozvíte vše co jste kdy potřebovali vědět o produkt managementu a roli Product Ownera.

Originál spolu s přepisem textu nejdete zde.

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íň.

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:

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.

Lean metody ve vývoji softwaru

Je to takový pěkný buzzword. Lean firma. Spousty velkých firem Lean principy implementuje, obvykle bez většího porozumění jejími zaměstnanci. Často to končí tím, že si udělají nějaké lístečky a jsou dostatečně Lean, tedy štíhlí. Jenže na to aby to přineslo nějaké výsledky, je stejně jako u agilních metod třeba porozumět filozofii. A ne jen slepě vykonávat nějaké rituály. O co tedy jde? Jednoduše řečeno o omezení práce na tom, co by nemuselo přinášet hodnotu a tedy v konečném důsledku mohlo přijít nazmar.

Nejznámější Lean firma je určitě Toyota. Tam vyvinuli proces řízení výroby, odlišný od běžných procesů kdy vyrábíme kdykoli a cokoli na sklad. Řídí výrobu systémem tahu, kde vyrábíme příslušný díl, až když je potřeba.

Jak takový princip použít ve firmách kdy žádné fyzické díly nevyrábíme? Tak se třeba podívejme na standardní vývojový proces – waterfall. Nejprve uděláme na sklad analýzu, pak kód, a pak testy. A čekáme, že to je tak v pořádku a že všechny díly jsou kvalitní (tedy že design už se nezmění, v kódu se nenajde chyba, a že zákazník to tak opravdu chce). A stejně jako ve výrobě se nám děje, že jednotlivé věci musíme předělat, opravit, zahodit. Někdy i celou krabici dílů se stejnou chybou (někdy i celou rozsáhlou funkcionalitu).

Jak na to? V kostce, omezte ‘work in progress‘ a soustřeďte se na to, abyste jednotlivé požadavky protlačili systémem co nejrychleji. Implementujte systém tahu a nezačínejte s analýzou, dokud nemáte prioritní požadavek od zákazníka. A dokud nemáte zpětnou vazbu, že předchozí požadavek byl akceptován.

A aby to bylo více uchopitelné, Lean Software Development je založen na následujících principech:

Odstraňte vše, co nepřináší hodnotu – tedy zbavte se odpadu. Pracovat na něčem co se ve finále vyhodí je škoda času, když se vám podaří tento čas investovat do věcí, co mají smysl, budete jistě efektivnější.

Zlepšujte se a učte se již v průběhu – když jen slepě vykonáváte předpisy a sledujete procesy, může se stát, že stejnou chybu opakujete pořád dokola a ‘odpad’ se vám tedy na konci projektu nahromadí víc, než byste si přáli. Pravidelná zpětná vazba vám pomůže se soustředit jen na to, na čem záleží.

Rozhodujte se co nejpozději – čím později rozhodnutí padne, tím více máte informací. Takže jsme zase zpět u myšlenky, že nemá smysl vyrábět zásoby na sklad jen proto, že zrovna máte volnou linku nebo programátory.

Dodávejte práci, jak nejrychleji to jde – čím dříve něco dokončíte, tím dříve dostanete zpětnou vazbu, kterou můžete hned v další iteraci zohlednit.

Dejte týmu důvěru a zodpovědnost – a budete mít mnohem motivovanější tým, než když se budete držet tradičních top-down struktur.

Zaměřte se na celkový dojem – produkt není jen software. Dbejte na kvalitu a celkovou udržitelnost systému, nevytvářejte technický dluh.

Zaměřte se na celkový výsledek – jednotlivé chyby a selhání nejsou podstatné, pakliže se z nich poučíte. “Think big, act small, fail fast; learn rapidly” – tedy Přemýšlejte dopředu, začněte u malých věcí, ty vyhodnoťte a rychle se z nich poučte. Jen tak zajistíte, že výsledný produkt bude úspěšný.

Metoda, která vám radí jak na to je Kanban. Ale o tom zase příště.

Motivace

Jak efektivně motivovat zaměstnance? Je to jedna z nejčastějších otázek které dostávám hned po tom jak implementovat Scrum. Dobrý Scrum Master by měl umět tým motivovat. Být dobrým koučem. Takže jak na to? Určitě nepotřebujete žádný budget. To že peníze nejsou motivačním faktorem ale demotivačním – tedy ať přidáváte jakkoli, radost z vyšší mzdy či prémie vydrží tak týden. Pak zajdete na večeři, jedete na dovolenou a zas je to všechno jako dřív. Čím více dostanete, tím dříve si přijdete pro další. Ale dostáváte-li méně, než byste vzhledem k tomu co děláte měli, nebo než nutně potřebujete, za poměrně krátkou chvíli jste silně demotivováni. Takže řekněme, že plat je fér. Co ty nejlepší lidi vlastně v týmu drží a neodejdou ani za lepší plat jinam? Obava ze změny? Možná. Ale to nestačí. Dobrý kolektiv, smysluplná práce, pocit že to co děláte je potřeba, a že to má význam. A že to děláte dobře.

Tohle všechno samozřejmě není primární starostí Scrum Mastera. Má kolem sebe pár pomocníků.
Začněme tím co je starostí Product Ownera. Dodávat vaší práci smysl. Product Owner je vlastníkem produktu, potažmo product backlogu a ten musí tým nadchnout, aby ve svém počínání viděl smysl. Customer demo vám v tom jistě pomůže. Pochvala od zákazníka nikdy není k zahození. Pocit, že to co píšete někoho opravdu zajímá. A že to potřebuje. Takže by se dalo říct že Scrum proces vám s motivací také výrazně pomůže. Jestli tahle složka motivace nefunguje, jako Scrum Master to budete nejdříve muset spravit. Jinak práce bude těžko někoho bavit a těžko z kohokoli v týmu dostanete nějaké větší nasazení. Naopak uslyšíte samé výmluvy na okolí.

Takže produktu rozumíme, dává nám smysl, práce tým baví. Co zbývá? Scrum Master pomáhá odstraňovat překážky, tu šílenou práci co vás dřív obtěžovala… Občas pomůže moderovat diskusi, řeší problémy. To ale není vše. Měl by i lidi rozvíjet…

A tady začíná problém. Ve Scrumu by se dalo často říct, že tým je tak dobrý jak dobrého má Scrum Mastera. Scrum Master musí být v jistém smyslu i dobrý manager. Takový, co jednotlivým lidem v týmu věří, že dokáží být výjimeční a pomáhá jim stanovovat si takové cíle, aby byly náročné ale splnitelné. Aby tým pracoval nejlépe, jak umí. Špatný Scrum Master si jen stěžuje, že jednotliví členové nemají potřebné skilly, a že by se to museli učit. A na to že není čas. Dobrý Scrum Master ví, že tým to dokáže. Z hloubi duše jim věří a tým to někde uvnitř pozná. Aniž by taková informace byla kdy vyřčena nahlas. Jen tým pracující pod takovým Scrum Masterem může být ve skutečnosti úspěšný.

Na závěr doporučím jeden článek. Není sice o Scrumu, ale myslím, že dobrý Scrum Master musí vytvářet takový “pygmalion”.

Pozvánka na konferenci Agile Prague 2011

Jak asi jako čtenáři tohoto blogu víte, pořádám v září konferenci zaměřenou na agilní metody. A protože jsem přes víkend napsala takovou pěknou pozvánku, přišlo mi škoda se o ni s vámi nepodělit. 🙂

Konference Agile Prague 2011

První mezinárodní konference zaměřená na agilní metody řízení proběhne ve dnech 29. – 30. září v Praze v konferenčním centru CITY na Pankráci. Přijďte se dozvědět něco nového. Buďte s námi agilní.

Co si představíte pod slovem Agilní? Dynamický, flexibilní, rychlý, mít schopnost reagovat na změnu, komunikovat se zákazníkem, ptát se po jeho potřebách. Pracovat jen na tom, co přináší hodnotu. V krátkých cyklech. Učit se, zlepšovat se, měnit sebe i svoje procesy… Je to pro vás něco nového? Nebo se již staly agilní metody nedílnou součástí nejen vašich projektů, ale i života? Ať již odpovíte na tuto otázku jakkoliv, konference Agile Prague je událostí, kterou byste rozhodně neměli minout.

Konference proběhne ve dvou dnech a dvou paralelně běžících sekcích, během nichž se vám představí 28 přednášejících z různých koutů světa, kteří se s vámi podělí o své zkušenosti s agilními metodami, Scrum Procesem, Extrémním programováním či Kanbanem.

Přemýšlíte, pro koho je konference vhodná? Pro vývojáře, testery, team leadery, managery, ředitele, majitele firem. Pro všechny, kteří se chtějí dozvědět něco nového. Pro všechny, kteří chtějí být efektivnější, flexibilnější, mít spokojené zákazníky, a v neposlední řadě chtějí, aby práce byla i zábava.

Začínáte? Říkáte si, co to vlastně ty agilní metody jsou, a jestli by vám to nemohlo něco přinést u vás ve firmě? Přijďte si poslechnout zkušenosti z firem, které v posledním roce na agilní metody přešly. V praktických case-studies se s vámi podělí o své zkušenosti. Co očekávali, co se jim povedlo, ale i co bylo těžší, než si mysleli, či co se jim stále nedaří. Zajímá vás, proč firma LMC začala se Scrum procesem a jak se změnili jako celá firma? Proč se rozhodli být agilní? Ondřej Mysliveček se s Vámi podělí o své zkušenosti z této změny. Nebo chcete vědět, jak se mění velká korporace jako T-Mobile, a co je k takové změně vedlo? Jindřich Otčenášek má s touto změnou čerstvé zkušenosti.

Jste součástí agilního týmu? Popovídejte si s  J. B. Rainsbergerem (Canada) a určitě nevynechte jeho key-note přednášku, kterou uvádí slovy: “Každý měsíc se mě někdo ptá, jak přesvědčím svého managera, aby mi dovolili refactoring”. Pokračovat můžete přednáškou představující praktický úvod do Kanbanu, který uvede Joakim Sundén (Švédsko), poslechnout si, jak naložit s agilními metodami v oblasti UX, kde se o zkušenosti z Keria podělí Petr Douša, či se jít podívat na přednášku Tomáše Perglera jak se Scrumem naložili v Seznam.cz, nebo Pavla Teichmana na jeho zkušenosti z Pojišťovny DIRECT.

Pracujete pro státní instituce a nevíte jak, a jestli vůbec je možné agilní metody použít? Využijte jedinečnou možnost si poslechnout, jak s prostředím Evropské Komise, která si s ničím nezadá s českými státními institucemi, naložil Andrej Zachar (Simpleway) a  Sjerk Van Riel z Belgie, nebo jak Pat Guariglia z USA nasadil Agile a Scrum do New York State Government Agency.

Jste Scrum Master nebo Product Owner? Nevynechte možnost poslechnout si zkušenosti jiných Scrum Masterů a Product Ownerů. Poslechněte si, proč Alan Bustamante považuje Agile jako “nejlepší způsob jak získat ze softwarových projektů nejvyšší hodnotu“, nebo si zahrajte na Scrum a postavte si s Thorstenem Kalninem letiště z Lega.

Vedete více týmů? Chtěli byste, aby byly efektivnější a motivovanější? Přijďte si poslechnout přednášku, kde Ola Ellnestam (Švédsko) bude mluvit o tom, co to znamená být agilní, Andrea Provaglio (Itálie) vysvětlí jak docílit samoorganizujícího (self-organized) se týmu a Chris Matts (Velká Británie) se zaměří na business analýzu v agilních týmech. Nakonec vám Alan Brown (Španělsko) z IBM poradí jak odolat tlaku na dokončení všeho ještě rychleji a levněji než doposud.

Vlastníte nebo řídíte firmu? Vidíte, jak se svět zrychluje, je dynamičtější a klade na Vás čím dál tím vyšší nároky? Máte strach, že neudržíte krok s konkurencí? Přijďte se podívat, co vám agilní metody mohou přinést, jak agilní metody komunikovat, jak je nasadit. Začít můžete hned na naší první key-note přednášce – Christopher Avery (USA) – Your Agile Leadership Gift. Určitě budete souhlasit, že komunikace je čím dál tím důležitější. A to jak v rámci týmu, tak i externě se zákazníkem, businessem či managery. Jak v praxi komunikovat si vyzkoušíte na interaktivní přednášce Zuzany Šochové a Eduarda Kunce.

Jste Agilní? A jen se chcete posunout trochu dál? Něco se dozvědět? Máte pocit, že Vám možná něco uteklo, nebo že potřebujete pár nových nápadů? Zapojte se do open-space diskuse, podělte se s námi o krátký lightning talk, nebo volně diskutujte s přednášejícími i účastníky v příjemných prostorách konferenčního centra na Pankráci.

Jsme rádi, že v rámci aktivit Agilní Asociace spolu s partnery můžeme agilní komunitě v Čechách přinést akci světového formátu. Akci, která pomůže širokému spektru firem být úspěšnější, akci, na kterou se budete těšit zase příští rok.

Těšíme se na setkání s Vámi.

Tým Agile Prague Conference

http://agileprague.com

Jak uvařit žábu

Znáte tu historku o žábě? Žába, když jí hodíte do vroucí vody, tak z ní vyskočí. Když ji ale dáte do hrnce a ten pozvolna zahříváte, žába tu změnu ani nezpozoruje a v klidu se nechá uvařit. Zní to možná překvapivě, ale zamyslete se nad sebou, kolikrát už Vás takhle uvařili zaživa. Pracujete ve stejné firmě, rok co rok. Ze začátku to bylo zajímavé, nové, učili jste se. Později jste si zvykli, práce se stala snazší, bylo v ní stále méně prostoru pro rozvoj, ale byl tam dobrý kolektiv, tak jste zůstávali. A pak co kdyby to jinde bylo horší. Většina zaměstnanců je taková. A jen málo firem se aktivně snaží, aby své zaměstnance neuvařilo jako žáby. Mě nakonec prokázali tu službu, že mě z vařící vody pomohli ven. Také jsem tam byla ráda, ale na druhou stranu, zpětně viděno, ta voda už se skoro vařila.

Takže co dál? Otřepete se, podivíte se, jak je venku oproti vroucí vodě ‘chladno‘, a než abyste se nechali znovu v nějaké další firmě uvařit, zkusíte se postavit na vlastní nohy. Ostatně podnikatelů je spousty, tak proč by to nemělo vyjít zrovna Vám 🙂