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 🙂

Scrum proces není všemocný

Scrum proces se zdá být jednoduchou náplastí na všechny problémy. Nefunguje Vám tým? Začněte používat Scrum. Jste zahlceni byrokracií, Scrum Vás jí zbaví. Máte málo kvalitní kód, a pořád něco předěláváte? Netestujete? Zákazník není spokojen s tím, co dostal? Scrum má řešení. Tak se pojďme podívat, jak modelové firmy Scrum proces nasazují.

1. Technokrat s.r.o

Ředitel pověří někoho ze zkušenějších teamleaderů či vývojářů v týmu aby zjistili, o co jde. Ten si udělá research. Možná si koupí knihu, ale internet většinou stačí. Všechno umíme a víme, tak začneme. Scrum meeting (daily standup) je zdánlivě jednoduchý a chcete-li dělat Scrum, tak ho prostě musíte mít. Zároveň je ale třeba hledat tool, protože kartičky se používaly maximálně před sto lety. Čím složitější tool je, tím více možností má, ty všechny by se nám mohly hodit. A výsledek je, že tým brblá, že je to všechno k ničemu, proč tráví denně hodinu na meetingu který nic nepřináší, že své práce má dost. Toolu nikdo nerozumí, a Scrum metodě také ne. Navíc produktivita výrazně klesla a zákazník se také netváří nadšeně. Zeptáte-li se na Scrum metodu, dozvíte se, že Scrum my známe a děláme, ale my jsme v tom a tom jiní a pro nás se Scrum proces nehodí a nejde vlastně použít.

2. Developper s.r.o

Vývojáři o Agilních metodách nebo Scrumu nebo XP zaslechli někde od jiných týmů. A líbí se jim to. Nikdo by jim přeci nerozkazoval, nikdo by jim neříkal, co mají dělat a jak. Plánuje přeci tým, a to jsou oni. Cool. Tak začnou jednotlivé praktiky dělat. Většinou to selže v napojení na management. Někdy už na úrovni teamleadera, někdy až u top managementu. Spousta managerů v Čechách je ze staré školy. Bojí se dát své pseudozodpovědnosti na ostatní. Bojí se, že by někdo mohl vědět, co a jak dělají. A co se chystají dělat. A že by vše neměli pevně v rukou. A tak je lepší praktiky Scrumu omezit, okleštit nebo zakázat. Ale ne přímo, oni dělají Scrum, ale vidíte, dali jsme jim šanci, a ono to mělo takové problémy…

3. Korporát a.s.

Scrum proces a agilní metody používají velké firmy okolo nás. Měli bychom ho zkusit. Pošleme týmy na kurzy, project managery na certifikaci Scrum Mastera, a změníme procesy. Týmy tedy začnou, a až do prvního většího problému vše funguje. Pak ovšem project manager zapomene, že má jinou roli, a že jako Scrum Master nesmí měnit plán, nesmí rozhodovat za tým, a rychle se vrátí k osvědčeným metodám řízení projektů, na které byl zvyklý. A celá firma prochází deziluzí. Dalo by se říci, že devět z deseti project managerů se na Scrum Mastery nikdy nepodaří přeučit.

Existují i úspěšné firmy. Velké i malé. Ty většinou pochopili, že Agilní metody a Scrum představují změnu myšlení a přináší změnu kultury firmy. Investovali do kurzů, našli si interního či externího kouče aby jim s transformací pomohl. Vědí, proč změnu chtějí a co od ní očekávají. A vědí, že změna je náročná a vyžaduje hodně každodenní práce na každé úrovni. Taková změna nejde nařídit zhora, ani partyzánsky vybudovat odspodu. Musí propojit celou firmu. Stojí hodně energie. Ale výsledek pak stojí za to.