Kultura Agilní firmy

Existuje spousta více či méně formálních frameworků jak Agile a Scrum aplikovat na úrovni celé firmy. V Agilní komunitě o tom nepanuje shoda a vedou se dlouhé diskuse, který framework je lepší či horší, který je agilnější či scrumovatější. Více než potřeba přidat další meetingy jako Scrum of Scrums nebo role, je zde ale potřeba posunout hodnoty Scrumu a agilních přístupů na úroveň firmy. Být týmovými hráči, otevřeně o všem komunikovat, budovat důvěru a posilovat zodpovědnost.

A když už tu o tom mluvíme, pěkným příkladem, jak na to, může být třeba Spotify. Spotify je dneska hodně Agilní firma, která už rozhodně není na začátku své Agilní transformace. Naopak, ve Spotify mají Agile a Scrum už několik let a za tu dobu se naučili Agilní opravdu být a jejich praktiky jsou rozhodně inspirativní.

Přečíst o Spotify modelu si můžete tady:
A jestli se vám nechce moc číst, a chcete se podívat jak takovou Agilní kulturu vybudovat, jako obvykle se Henrikovi podařilo moc pěkné video: část 1 a část 2.

Jaká je budoucnost Agilu a Scrumu

Před nějakým časem jsme v Praze pořádali setkání se členy boardu Agile Alliance. Byla to pěkná diskuse, která končila otázkou, jaká je budoucnost Agilu. Na odpovědi se můžete podívat tady:

Když to trochu rozšíříme, plně souhlasím. Za nějakou dobu, až se zase svět vinou evoluce pootočí o kousek dál, tady nebude ani Agile ani Scrum. Bude tu něco zcela jiného, třeba tomu můžete říkat “Queguer”. Nebo jakkoli jinak. Ale dokud se nenaučíme cestovat v čase, těžko říct, co to bude. Možná, že to bude něco zcela jiného, něco na způsob změny, jakou vyvolala průmyslová revoluce. A možná že ne, možná, že to bude zatím jen něco velice blízkého současnému Agilu a Scrumu. Drobné nuance, které udělají ohromný rozdíl.

Kdybych si měla tipnout, bude to něco, co si nikdo neumí představit. Za 60-70 let tu bude “Queguer”, a těžko odhadnout, co to bude. Mně by se líbilo něco rychle se měnícího, adaptujícího se na změny, něco veselého, spokojeného. Ale já nemám jako business věštírnu, ale coaching, takže jistojistě nic lepšího než vy nevymyslím. A tak nezbývá než se zeptat… Zavřete oči a představte si, že jste právě cestovali v čase o třeba 69 let do budoucnosti. A je to. “Queguer”. Rozhlédnete se, a je všude kolem. Všichni se snaží být více “Queguerovatí”. Je to těžké, ale stojí to za to…. Co by takový “Queguer” byl pro vás? Jak byste si přáli, aby vypadal?

Backlog Grooming

Také se ptáte k čemu je Backlog Grooming? Cílem tohoto meetingu je zajistit, aby tým rozuměl celému Backlogu. Proto na úplně prvním Groomingu začínáme tím, že Product Owner v 15ti minutách představí vizi produktu /releasu a všechny Epicy. V druhých 15ti minutách představí střední vrstvu Backlogu, tzv. Super User Stories – tedy předpřipravené funkcionality, které přijdou na řadu za několik Sprintů. Nejsou ještě dostatečně malé ani úplně konkrétní, ale už mají obvykle formu User Story. Takových Super User Stories by mělo být připraveno na 5-10 sprintů. A zbývající čas Backlog Groomingu věnuje Product Owner konkrétním User Stories na vrcholu Backlogu. Ty už musí být INVEST, tedy jasné, konkrétní a dostatečně malé, aby se daly kdykoliv naplánovat a v rámci Sprintu dokončit. Takových User Stories potřebujeme v Backlogu na cca 2-3 Sprinty.
Backlog Grooming

Každý další Grooming už většinou Product Owner spolu s týmem prochází User Story podle priorit tak, aby měli pokaždé připraveno dostatek práce pro další Sprinty. Grooming se obvykle dělá v půlce Sprintu, aby v případě potřeby bylo dost času si danou funkcionalitu promyslet a to jak ze strany Product Ownera, tak týmu. Obvyklou součástí Backlog Groomingu je i ohodnocení User Stories Story Pointy, aby se Product Owner mohl rozhodnout na základě komplexity o prioritě, tým si ověřil, že to všichni chápou stejně a společně ev. dodefinovali akceptační kritéria, či User Story rozdělili.
Jak dlouho takový Backlog Grooming trvá? To záleží na přípravě, kterou tým jednotlivým User Stories věnuje, na připravenosti a kvalitě jednotlivých User Stories, a schopnosti efektivně komunikovat. První Groomingy obecně trvají dlouho, další mohou běžně trvat kolem 30-60minut.

Backlog Grooming

Chcete-li Grooming krátký, a navíc nemáte rádi meetingy, můžete zvážit jako tým na fotce ho dělat u tabule ve stoje. Určitě se omezí dlouhé nikam nevedoucí diskuse a posílí příprava týmu. Zároveň fyzická reprezentace umožňuje se zapojit do dodefinování User Stories každému, a nečekáte na Product Ownera až to dopíše do systému. Takže rozhodně doporučuju. Určitě to zkuste.

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ý.