Je Scrum samospasitelný?

Nejhorší ze všeho jsou zkratky. Něco nám nefunguje, třeba dodáváme aplikace zákazníkům pozdě, s chybami a nevíme co s tím. Někde zaslechneme, že existuje nová metodika, jejímž jádrem je jakýsi Scrum. Tak si to rychle někde přečteme, zajdeme na školení a vše změníme, jenom abychom měli Scrum. Moc nad tím nepřemýšlíme, přeci Scrum je přesně tohle a tamto. Přesně dané postupy, jako v každé metodice. Když to budeme “přesně“ aplikovat, tak bude konečně vše dobré. Ale ono to tak často není. Ba co víc, z pohledu zvenku je vše stejné, nic se nezměnilo, a pohledem uvnitř je vidět spousta vyhozené energie na tuny meetingů které nic nepřináší. Máme sice jakýsi Scrum, ale výsledek je stejný. Kdo za to může? Scrum? My? My přece ne, takže je to jasné, Scrum.

Klidně můžeme říct, že Scrum je k ničemu. A můžeme mít i pravdu protože vás zázračně nezachránil. Ale problém je v tom, že tato změna není snadná. Neexistuje žádná kuchařka, co musíte udělat, aby to fungovalo. Jen sada doporučení, které by se daly shrnout do dvou principů:

  • Pochopte, jak vypadá správně Scrum a proč by tak měl vypadat. Rozlište co je důležité a co jen berlička která vám pomůže se se Scrumem sžít. I kdyby se ta představa zdála být nedosažitelná.
  • Začněte co nejdříve. Aplikujte maximum toho co je Scrum. A pak takový proces postupně měňte. Vyměňujte berličky, abyste se víc a víc blížili cíli.

Když neuspěcháte první krok, bude to fungovat. Slepé kopírování postupů často k cíli nevede. Ani Scrum není samospasitelný. Vlastní úsudek a zdravý rozum při implementaci je také velmi důležitý. Pak nás Scrum může a často také spasí.

Překlad Agilních termínů

Minulý týden jsem školila Agile a Scrum na Slovensku. Večer jsme diskutovali na téma, jestli se mají výrazy překládat, nebo ne. A že i v mé knize jich mám příliš v originále. Já na to oponovala, že nejsem obrozenec, a že nebudu vymýšlet žádnou další “čistonosoplenu“. Na to padnul docela relevantní názor, že když začínaly počítače, tak to bylo taky všechno anglicky. A pak přišel Microsoft a ty v té době divné výrazy prostě komunitě svých uživatelů vnutil. Ti se chvíli kroutili a prskali, ale nakonec si zvykli a dnes to nikomu nepřijde divné.

Druhý den tým si tým na to sedl a při ranní kávě vytvořili toto. Když jsem přišla, už to na mě čekalo. Posuďte sami 🙂

A teď vážně. Asi v podstatě souhlasím. Nedávno jsem překládala otázky do testu pro Certified Scrum Master CSM certifikaci a je to náročné. Přeložit, nebo nechat? Pochopí to pak Scrum Masteři? A protože i překlad Agilního Manifestu, do kterého jsem se zapojila, vznikal týmově, pojďme to zkusit. Pošlete návrhy pod tento článek a třeba z toho vyjde nové české a slovenské Agilní názvosloví.

Certified Scrum Master kurz CSM poprvé i v češtině, aneb jak se to stalo

Byla k tomu dlouhá cesta. Někdy před rokem jsem se potkala na Scrum Gatheringu v Indii s Bobem Hartmanem, který zastupoval na konferenci Scrum Allianci. Část konference party jsme diskutovali o tom, že Scrum Alliance chce změnu, že se chce více otevřít novým lidem, nebýt už tolik tím uzavřeným elitním klubem, co mezi sebe nepustí nikoho nového, bez ohledu na to, jestli je člověk dobrý či ne. A tak jsem si říkala, že je asi na čase to zkusit. Využila jsem pro to jejich provisional CST proces. A začala sepisovat žádost, takový aplikační balíček. Byla to docela legrace. Bylo toho opravdu hodně a bylo to hodně detailní. Zkušenosti, doporučení, cotrainingy, mentoring… Když to zkrátím, trvalo téměř rok, než jsem se dopracovala k interview a po pár dnech čekání na výsledek to tu bylo. Nejdříve PCST – tedy Provisional Certified Scrum Trainer. A krátce na to Certified Scrum Trainer – CST. O co těžší a méně přehledný ten proces byl, asi o to větší z toho mám nakonec radost.

Proč byste měli chtít CSM certifikaci? Neměli. Žádná certifikace z vás odborníka neudělá. A certifikační kurz není nutně v ničem lepší než ten bez certifikace… Ale pro spoustu lidí je to určitý krok dál. Někde si ho odškrtnou ve svém vlastním interním rozvojovém plánu. Já vlastně nikdy certifikace nechtěla a dostávala je tak trochu náhodou… ve správný čas na správném místě. A překvapivě je nikdo nechtěl ani po mně, což mě vždy udivovalo. A proč jsem se tedy do toho celého kolotoče se Scrum Alliance a CST tedy pustila? Asi abych si dokázala, že na to mám. Přišlo mi trapné říkat, že nepotřebujete certifikaci, stačí vám můj necertifikační kurz, ale žádný certifikační kurz sama nenabízet. Je to jako ta bajka o lišce a hroznech vína. “Stejně jsou kyselé,” říká liška, když zjistí, že ani omylem na žádný hrozen nedosáhne. A tak jsem si říkala, že nechci být jako ta liška. A proč zrovna Scrum Alliance a Certified Scrum Trainer (CST)? Asi že není snadné takovou CST certifikaci dostat. Tyhle hrozny se prostě zdály být nejvýš. Tohle všechno jsou asi často motivace lidí jako jednotlivců. Jako důvod můžete přidat lepší šanci uspět u pohovorů, ale to stejně v praxi moc nefunguje.

Proč ale firmy chtějí certifikaci? Asi abyste jako firma dodali celému procesu důležitost, my to opravdu myslíme vážně, a opravdu Scrum chceme nasadit. Vidíte? Anebo abyste svým novým Scrum Masterům pomohli vytrvat, vydržet všechna ta příkoří a složitosti, kterými si při Agilní transformaci musí projít, zvednout jim sebevědomí, že to dokážou. Zvládnou to, mají přeci certifikaci. To oni jsou ti, kteří znají Scrum a pomůžou vám ho nasadit a adaptovat tak, aby fungoval. Když se nad tím zamyslíte, asi na tom něco je.

Takže jestli žádnou certifikaci nechcete, je to fajn. Váš Agilní život nebude o nic méně úspěšný. Tedy za předpokladu, že se nestěhujete třeba do Indie, kde každým získaným certifikátem významně stoupá společenské postavení jednotlivce. Ale jestli vás certifikace láká, teď máte první a jedinečnou příležitost absolvovat CSM – Certified ScrumMaster kurz nejen v angličtině, ale i v češtině.

Správný Product Owner není úředník

Správný Product Owner má nápad, dokáže ho zformulovat do vize, a tu prodat jak zákazníkům, tak firmě i týmu, který pro něj pracuje. Spousta Product Ownerů ale je jen úředníky. Vychází z té armády business requirement specialistů, business konzultantů. Dělají to, co jim někdo řekne. To se ale přesně snažíme pomocí Agilních metod a Scrumu změnit. Proto jsme toho člověka udělali Product Ownerem, a ne jen Product úředníkem.

Jak takový produkt začíná? Ideálně si uděláme product charter. A to jak pro produkt jako takový, tak pro první release. Co to je a jaký to má formát. Je to snadné. Vše se vejde na jeden flipchart. Jméno, timeframe, elevator pitch – tedy jedna, dvě věty, které shrnují, co že to děláme a hlavně proč, vytváří obrázek, konkrétní jasnou představu cíle, vzbuzují emoce. Prostě vás zaujmou. A pak ve dvou sloupcích jako stručné odrážky cíle, kterých chcete dosáhnout a success measures, tedy jak poznáte, že jste toho dosáhli.

Product nebo Release Charter je klíčová věc. Bez ní ani nemá smysl se pouštět do psaní Backlogu a User Stories. A není to ani snadné. Když se do toho pustíte, bez ohledu na množství prezentací, které jste už o produktu vyrobili, zjistíte, že umět z toho všeho, co byste mohli dělat vydestilovat podstatu stojí čas a energii. A Product nebo Release Charter je přesně to, co vám roli Product Ownera jako člověka zodpovědného za funkcionalitu (tedy Backlog) a celkový úspěch produktu usnadní. Cílem toho “product úředníka“ z klasického světa totiž je daný nápad rozpracovat do šířky. Vymyslet co nejvíce funkcionality tak, abychom pokryli přání zákazníků a stakeholderů. Cílem Product Ownera ale je pravý opak. Nápady a přání omezit na minimální funkcionalitu, která zákazníkům přinese to, co opravdu potřebují. Dělat tedy ne to, co umíme a můžeme, ale jen to, co má nejvyšší business value. To, co potřebujeme. Jen takový produkt je potom agilní, a jen takový produkt bez ohledu na Agile a Scrum je úspěšný.

Jak vypadá Agilní transformace?

Nevíte přesně co si představit? Je to náročné. Je to velká změna. A trvá to, než vám dojde v čem je to jiné. Na začátku je často nedůvěra. Tohle že by mohlo fungovat? A pak, po delší době zjistíte, že ejhle ono to funguje.

Tady je takový model transformace firmy. Není to o jednotlivcích, ale o celkovém mindsetu společnosti. O tom co si myslí tzv. “Third Entity“.

Agile Transformation Model

První stádium říká zcela jasně „Ne!“ – tohle my nikdy dělat nebudeme. Takovou pitomost. To se nám vůbec nelíbí. A tak vymýšlíte milióny důvodů, proč to doposud bylo dobré a proč to nové, agilní, u nás stejně nemůže fungovat. Když to nevzdáte, po čase se dostanete do stavu „!?!?!“ ono to tu pořád je? Oni to snad fakt chtějí nasadit. Blbouni. Vždyť to nikdy nemůže fungovat. A Když to pořád nevzdáte, firma se pomalu ale jistě šplhá po hraně Agilní transformace směrem k bodu zlomu. Je to náročné a vyčerpávající. Nastává stádium „???“ Je tohleto možné? My snad fakt budeme Agilní.

A jsme v bodu zlomu. Tady konečně přijde úleva. „He He“ říkáte si. Začíná to být pěkná legrace. Tu jízdu po tobogánu si užijme. A pak se odrazíte a jedete. „Jupíííí“. To nám to pěkně jde. Agile není zas tak špatný.

A ve finále si říkáte no jo, Agilní už jsme tak „Co dál?“. Nezměníme zase něco? Bude legrace :).

Agilní transformace at Acision

Jak se tedy pozná, kde jste? Podle úrovně energie. Podle schopnosti dělat si z věcí legraci, mít radost. Takže jak vypadá Agilní transformace ve firmě, která už se na takový bod zlomu Agilní transformace dostala a užívá si to? Podívejte se na pár fotek, co jsem nedávno pořídila v Acision. Jejich start velkého Agilního produktu byla opravdu zábava.

Agilní transformace

Jak pomáhám Agilní přístupy nasazovat v různých firmách, vždycky se našel někdo, kdo se z legrace ptal, jestli až budou opravdu Agilní, budou mít také tak barevné vlasy jako já. Ale až do teď to nikdo neuskutečnil. Na to se firmy většinou berou moc vážně. Ale když chcete změnu, je potřeba lidi nějak rozpohybovat.

Avatar na Scrum tabuli

A když jsem se po týdnu chodila dívat po standupech, ta schopnost dělat si legraci zůstala. A tak máme na Scrum tabuli asi největšího avatara, aby bylo vidět, jak jsem navrhovala, kdo na té věci pracuje.

Scrum tabule: Buďme konkrétní

Scrum tabule: Buďme konkrétní

Jednotlivé tásky na Scrum boardu pojmenováváme konkrétně, aby to bylo vypovídající a všichni věděli, o co se jedná.

Scrum board task

A čísla chyb na Scrum tabuli píšeme římskými číslicemi, protože jsme přeci šikovní a umíme to rozlouskat.

Agilní Architektura

Poslední dobou dostávám hodně otázek na to, jak má fungovat architektura v Agilních týmech. Čistý Scrum roli architekta nemá. Mluví o samoorganizujících se zastupitelných týmech. Když to škálujeme dál, tak se mluví o Scrum of Scrums. Ale architekti nikde. To ale neznamená, že nejsou potřeba.

Jak to tedy vypadá v jednoduchém případě jeden Product Owner, jeden produkt, jeden Scrum tým. Tam je architekt součástí týmu. Je to zkušený vývojář, který se dívá dopředu na celý produkt a pomáhá týmu zvolit takové řešení, které vyhovuje celkové vizi produktu. A protože Scrum má pravidlo, že tým pomáhá Product Ownerovi, pak takový architekt spolupracuje s Product Ownerem na tvorbě Backlogu. Pomáhá mu odstraňovat rizika, dodefinovává akceptační kriteria.

Když to škálujeme na větší produkty, kde je více týmů, pak obvykle máme dva typy architektů. Jednoho – ‘velkého‘ – který je na úrovni celého produktu a stanovuje pro týmy takzvanou runway, v rámci které by se měli držet. Takový architekt je součástí týmu Product Ownera a dívá se spolu s ním klidně i několik let dopředu. Zároveň v každém týmu je takový ‘menší‘ architekt, který týmu pomáhá porozumět dané architektonické runway a dělat v rámci ní každodenní drobná rozhodnutí. Všichni tito architekti jsou samozřejmě v častém kontaktu a společně definují architekturu produktu. Jedna z dobrých best practices je, že na takovýchto velkých projektech dělají týmy nejen review mezi sebou, ale věci zrevidované v rámci týmu posílají na takzvané architecture review ‘velkému‘ architektovi. Ten samozřejmě neprochází v detailu všechny změny, ale dává pozor, aby změny byly konzistentní a odpovídaly dané architektonické runway.

No a jestli chcete o Agilní architektuře vědět víc, přihlaste se na workshop “Architecture with Agility“ který vede Kevlin Henney před konferencí Agile Prague 2014, v pátek 12. září. Nebo na konferenci samotnou 15.-16. září, kde jedna z keynote, kterou přednese Peter Eeles, je na téma “Architecture, Agile and DevOps“.

A co o workshopu píše Kevlin?

  • I will be covering the following topics during the day:
  • Defining software architecture as a service to the business
  • The relationship between development process and software architecture
  • The relationship between architecture and development teams and practices
  • The importance of code habitability
  • Empirical processes and architectural decisions as hypotheses
  • The Worse Is Better approach versus the up-front approach to architecture
  • Dealing with uncertainty and change, and using uncertainty and change to define the architecture
  • Architectural properties and requirements
  • Different architectural styles and patterns and their trade-offs
  • Identifying and managing technical debt
  • Refactoring, rewriting and re-engineering
  • Decoupling and dependency management

Jsou odhady zbytečné? #NoEstimates

Poslední dobou začíná být hodně populární neodhadovat User Stories. Proč? No když je umíte dobře definovat, stačí spočítat počet User Stories za Sprint a máte velocity. Bez dlouhých diskusí o bodech. Umožňuje vám to jak plánovat reálné množství práce, tak předvídatelnost v rámci produktu. Ono na tom něco je, když totiž umíte dobře definovat User Stories, tak to opravdu stačí. Ale… Co když neumíte, a teprve začínáte se Scrumem, nebo Agilem experimentovat? Jste zvyklí na mandays a hodiny, místo User Stories máte klasické requirementy? Pak je tato praktika téměř nereálná. Relativní jednotky – body – vám totiž pomáhají se spoustou věcí. A to číslo je překvapivě jen vedlejším produktem. Není samo o sobě důležité. Takže proč odhadujeme v bodech? Pomáhá nám to soustředit se na hodnotu pro zákazníka a ne na technické komponenty. Pomáhá nám to zvolit takové řešení, abychom co nejsnadněji dosáhli business cíle. Pomáhá nám to učit se komunikovat napříč departmenty (development, testing, business), a všechna ta diskuse, kterou okolo funkcionalit vedeme, z nás dělá dobrý tým. Učíme se dobře definovat funkcionality tak, aby tomu tým rozuměl. Diskuse okolo ohodnocení nám také pomáhají prioritizovat jednotlivé funkcionality. Ze začátku jsou nekonečně dlouhé. Tak byste radši vzali zkratku a než se naučíte chodit, jezdit na kole, lyžích, bruslích byste raději začali rovnou řídit auto nebo pilotovat letadlo. Teoreticky to možné je, ale v praxi takové zkratky moc nefungují. Takže jestli už nejen děláte Agile, ale jste opravdu Agilní, rozumíte Agilnímu mindsetu, máte pravý samoorganizující Scrum tým, tak je možná na čase to zkusit.

Jestli chcete vědět víc, ráda vás pozvu na konferenci Agile Prague 2014, 15.-16. září, kde o tom bude mluvit Vasco Duarte ve své přednášce “How to improve software project estimates – The #NoEstimates view“.