Tag: Scrum

Konference Agile Prague 2016

Již pošesté se v září koná konference Agile Prague. Můžete se tedy těšit ve dnech 12.-13. září 2016 na spoustu zajímavých přednášek s Agilní tematikou, praktické case-studies a také několik workshopů. Co konkrétně bych doporučila?

Mám radost, že letos přijede Gojko Adzic, jehož Impact Mapping je velmi užitečný ve všech produktových organizacích.  Těším se na Woody L. Zuilla a jeho Mob programming. Další letošní keynote přednášku bude mít David Laribee na téma The Liberal Arts Programmer. Poslední letošní keynote řečník je Mark Layton, Scrum trenér s kterým jsme vloni organizovala v Praze Globální Scrum Gathering.

Stále žhavé téma je jak použít Scrum v kontextu větší firmy, tedy Scaling Scrum. V loňském roce Bas Vodde přestavil v Praze LeSS (Large-Scale Scrum) Framework a letos na něj naváže Jurgen De Smet, certifikovaný LeSS trenér, se kterým organizujeme následný konferenční workshop právě na téma LeSSu. Když už jsme u LeSSu, tak i Ran G. Nyman se scalingu a LeSSu věnuje.

Letos se věnujeme hodně i témau komunikace (Judith Mills) a coaching (Lisa Cornier a Suzanne Gagnon). Jako tradičně na konferenci bude Open Space, tentokrát ho uvede Olaf Lewitz, z čehož mám radost, protože Olaf vždy mile překvapí s něčím novým. Těším se také na přednášku Danka Kovatche a jeho pohled na Scrum. Gil Zilberfeld má hned dvě přednášky na téma testování a ty si určitě nenechte ujít. Jako každý rok vám několik firem představí své zkušenosti s aplikací Agilních metod, Scrumu a Kanbanu.

Já mám připravený krátký workshop na téma Team Toxins, kde se podíváme jak by měl dobrý tým vypadat a co dělat když náhodou tak dobrý není.

Nebudu tu opisovat celý program, na ten se podívejte na stránky konference AgilePrague. Doufám, že každý z vás si najde svá témata, která vám přijdou zajímavá. Nezapomeňte že inspiraci nezískáte jen posloucháním přednášek, ale i osobní konverzací se speakery a účastníky konference. Prostoru pro networking a diskuze bude hodně a využívejte ho co možná nejvíce. I o tom je konference Agile Prague.

Těším se na konverzace, přednášky a workshopy, ale hlavně na vás všechny – účastníky Agile Prague conference.

 

Co je to produkt a co projekt

Projekt začíná a končí. Produkt je tady ‘donekonečna‘. Pokračuje dalšími fázemi, rozšiřuje se, mění se.  Definice, kterou používá LeSS (Large Scaling Scrum) říká, že produkt by měl být tak široký jak je jen možné, ale stále praktický. Praktičnost obvykle končí hranicemi vaší firmy. Když už byste museli do cross-functional týmů zakomponovat lidi z cizích firem, abyste mohli dodávat end to end funkcionalitu, tak jste asi na hranici produktu. Na druhou stranu, jestliže produkt vnímají zákazníci jako jeden produkt – je to jeden produkt bez ohledu na technologii. Tedy frontend a backend je jeden produkt. Internetové řešení obsahující Web, iPhone a Android aplikaci je jeden produkt. Z druhé strany všechno co má podobný kód a je technicky podobné je jeden produkt.

Továrna na párky

Firmy často nevědí, kdy se na to co dělají, mají dívat jako na jeden produkt (viz výše zmíněná kritéria) a kdy to naopak rozdělit na více celků. Analogie, kterou pro takové rozhodnutí používáme, se jmenuje Továrna na párky. Chodí k vám různé zakázky-projekty. Někdo chce hovězí párky na večeři, někdo grill mix na párty. Někdo chce dokonce vegetariánský párek, někdo pikantní chilli. Když se na to budete dívat projektově, nikdy nepostavíte stabilní cross-functional týmy. A Agile vám nikdy pořádně nebude fungovat. Když ale řeknete, že vaše továrna na párky je továrna na internetová řešení, a na projekt se budete dívat jen jako na velký Epic v Backlogu, bude vše najednou snadné. Máte jeden Backlog, tam se sypou veškeré projekty. Jako každá položka Backlogu prochází Backlog Refinementem a prioritizací. Týmy pak jen berou ty nejdůležitější položky z Backlogu a dodávají je v rámci svého procesu v kvalitě odpovídající Definition of Done.

Když to mám nějak sesumarizovat, většinou produkt proti současnému stavu rozšiřujeme a stavíme stabilní továrnu, kde týmy mohou spolupracovat na jedné věci. Na druhou stranu takových továren můžete mít ve firmě mnoho. Například když děláte online hru a informační systémy, asi je praktické aby to byly dvě továrny a ne jen jedna.

Jak takovou velkou továrnu organizovat? Na to odpovídá například Large Scaling Scrum LeSS –kdybyste se chtěli o LeSS frameworku dozvědět více, pořádáme 3 denní LeSS workshop při konferenci Agile Prague 2016 v září.

Kanban nebo Scrum

Na letošní Agile Prague konferenci se vyrojilo mnoho CaseStudies na téma Kanban nebo Scrum. A protože konference bude až v září (nečekejte s registrací příliš dlouho, protože máme skoro vyprodáno) tak nevím, o čem budou jednotliví speakeři mluvit. Ale inspirovalo mě to k napsání toho, co vidím v rámci Agilního Coachingu a workshopů až příliš často. Dalo by se to shrnout větou Scrum nás moc nutí se měnit, stát se Agilními nejen jako tým, ale jako celá organizace. A to je moc práce, tak radši přejdeme na Kanban. Tam není tolik pravidel, nemusíme vytvořit žádné další role, a vlastně můžeme dělat to, co do teď a i přesto být Agilní. Odškrtnuto a bez práce. Kanban má totiž hrozně blízko k metodice jen s jedním pravidlem: Dělat všechno dobře. Je to dobrá metodika, stejně jako Kanban, ale většina firem ji nezvládne naimplementovat. Kanban sám o sobě je obsažen v DNA Scrumu. Scrum vznikal až po něm, takže veškeré Kanban principy zakomponoval do svého jádra fungování. Ostatně ani to, že ve Scrumu nemůžete dělat Continuous Delivery, neobstojí. Stačí přeci rozšířit Definition of Done tak, aby obsahovala i nasazení na produkci a tým pak nasazuje v průběhu Sprintu tak, jak jednotlivé UserStory dokončuje. Jestli když už jste tak daleko, že máte funkční cross-functional týmy, které nasazují v průběhu Sprintu na produkci, potřebujete Scrum je těžko říct.  Možná ne, protože máte Agilní mindset a kulturu už dávno tak v kostech, že i doporučení ‘dělejte všechno dobře‘ vyústí v Agilní firmu. Na druhou stranu, v takových firmách kde Scrum zvládli, pomáhá jim, se ho nezbavují jen proto, že jim něco nejde nebo že našli nové jméno.

Samozřejmě existují prostředí, kde je Kanban vhodnější než Scrum. Ale rozhodně to nejsou produktové firmy, ani když dělají hodně maintanance nebo mají prostředí, kde se stakeholdeři nechtějí domluvit, co mají týmy dělat a proč, a neustále se mění priority. Agile nikdy neměl být chaos.

K Agilnímu mindsetu samozřejmě nevede jen Scrum, ale i Kanban a třeba XP. Jen čistě z mé zkušenosti úspěšnost Scrumu na cestě k Agilnímu mindsetu je výrazně vyšší než úspěšnost Kanbanu. Vede tam i cesta přes doporučení ‘dělejte všechno dobře‘. Ale ta je ještě o řád méně úspěšná.

Jsem zvědavá co case-studies na Agile Prague Conference přinesou do diskuse k této tématice. A budu ráda, když se dozvím něco nového a zajímavého na téma proč by se mohlo vyplatit jít od Scrumu ke Kanbanu.

Když už se rozhodnete odhadovat, odhadujte včas

Spousta týmů dělá stejnou chybu. Odhaduje UserStory – položky Backlogu až na Sprint Planningu. Ale to je už pozdě. Odhady by měly sloužit Product Ownerovi k rozhodnutí, jestli chce do dané funkcionality investovat, nebo jestli je moc drahá a je třeba se nad ní ještě zamyslet, probrat se zákazníkem, či rovnou rozdělit, aby tzv. poměr cena/výkon tedy očekávaná business value/effort vyšlo lépe.

Kdy je tedy správný čas na odhady? Kdykoli tak, abyste dopředu netrávili čas na věcech hluboko v Backlogu, protože ty se ještě určitě změní, ale také abyste v případě potřeby byli schopni doplňující informace včas zjistit, rozmyslet otázky, které padly při hodnocení, a také měli dostatek času rozmyslet, jak na dané položce Backlogu budete jako tým pracovat.

Jak již jsem říkala v úvodu, na Sprint Planningu je již pozdě, protože jakákoli nejasnost Sprint Planning protahuje donekonečna, nebo vede k nepříliš silnému commitmentu typu ‘no tak uvidíme, kolik toho stihneme, stejně nevíme, co že se to přesně má udělat‘.

Obecně mají být odhady součástí Backlog Refinementu, tedy je můžete dělat kdykoli před Planningem. Prakticky to znamená například jako součást Backlog Groomingu v půlce Sprintu, nebo třeba tři dni před začátkem Sprintu na speciálním Estimation meetingu hned po Standupu. Obě dvě řešení zajišťují dostatek času pro opakování estimace nad nejasnými UserStories a obě dvě možnosti vedou ke kratšímu a kvalitnějšímu Sprint Planningu což je rozhodně dobře.

Různé přístupy ScrumMastera – ScrumMaster State of Mind model

Jako ScrumMaster můžete aplikovat několik přístupů. Jedním z modelů, který je popisuje, je ScrumMaster State of Mind, který jsem popsala ve své knize „The Great ScrumMaster – #ScrumMasterWay“, která je online pro Kindle formát na Amazonu a v papírové podobě je jí možné výhodně získat spolu s registrací na Agile Prague Conference.

ScrumMaster State of Mind

ScrumMaster State of Mind je taková mapa, kam se ScrumMaster může vydat. Řekněme, že nejčastější přístup na začátku transformace je vysvětlovat, učit, sdílet zkušenosti. Efektivní učení je pro tým na začátku Agilní transformace kritické. Když nepochopí, co, a hlavně proč dělají, změna mindsetu a kultury ani nenastane.

Dalším přístupem, který ScrumMasteři obvykle volí je odstraňovat překážky. Přeci musí týmu pomoci, od toho tu jsou. Tady se cítí dobře a je za nimi vidět reálná práce. Bohužel to s sebou nese i nevýhodu. ScrumMateři se tu totiž cítí tak dobře, že se často stanou asistentkami týmu a aktivně si hledají práci. Tým se pak ovšem nerozvíjí, nezlepšuje, ani nepřebírá zodpovědnost.

Třetím kvadrantem kde se ScrumMaster může pohybovat je Facilitace. Spousta ScrumMasterů ji omezí jen na vybrané Scrum meetingy, ale to ovšem zdaleka nestačí. ScrumMaster by měl být schopen facilitovat nejen tyto meetingy, ale v podstatě libovolnou komunikaci. Předejde tak konfliktům v jejich počátku, kdy je ještě snadné je odbourat.

Posledním přístupem, který si jako ScrumMasteři můžete vybrat je Coaching. Tady na rozdíl od prvního kvadrantu nepotřebujete mít žádnou znalost o daném tématu. Coaching je totiž jen o schopnosti klást dobré otázky pomocí kterých ScrumMaster nastaví týmu zrcadlo a zvýší jejich vlastní uvědomění a pomůže jim nalézt jejich vlastní řešení.

ScrumMaster State of Mind model

Jak aplikovat ScrumMaster State of Mind model

Když to shrnu, jako ScrumMaster máte na vybranou čtyři přístupy: učit, odstraňovat překážky, facilitovat, coachovat. Mezi nimi si můžete vybrat podle dané situace. To ale ještě není plný obrázek. Podstatnou část ScrumMaster State of Mind modelu tvoří prostřední část, kde ScrumMaster jen pozoruje. A na základě svého pozorování si vybere, který přístup pro danou situaci použije a pak se zas vrátí a podívá se, jak tento přístup zabral. Když funguje, můžete pokračovat. Když ne, je lepší zvolit jiný přístup.

Dynamika změny kultury

Pokaždé, když končím nějaký dlouhodobější Agilní coaching nebo enterprise coaching, mám radost, jak to lidem v té firmě jde. Jak se všichni změnili od doby, kdy jsem tam byla poprvé. Co všechno museli v sobě akceptovat a pochopit, aby takovou změnu udělali. Je to prostě úplně jiná firma. Plná energie a optimismu z toho, že to zvládli a dokážou dál vést sami. Nejsou se vším hotovi, ale jsou ready jít dál sami a změnu přístupu dotáhnout. Asi to je důvod proč mě Agilní coaching a enterprise coaching tak baví. Na druhou stranu vždycky, když v nějaké firmě takhle končím, je mi smutno. Smutno z toho, že nemůžu být součástí takové změny kultury. Spousta lidí se za tu dobu stane mými přáteli, se spoustou jsem i dál v kontaktu. Potěší mě, když slyším kam se sami dostali. Mění se, a já jdu zase dál hledat další firmu, které můžu ze změnou kultury a přístupu pomoct.

Od každé firmy se něco naučím, něco co znám musím použít jinak, lépe zformulovat, aplikovat, nakreslit. Dneska mám jeden starý obrázek s lepším vysvětlením. Psala jsem ten koncept už do své nové knihy. Kniha se jmenuje The Great Scrum Master a je průvodcem pro všechny co chtějí změnit kulturu na moderní Agilní organizaci, tedy nejen ScrumMastery, Agilní coache ale i managery a leadery firem. A protože každým použitím všech těch popsaných konceptů se něco učím, tady je nová vylepšená verze popisující dynamiku změny kultury.

Každá změna vytváří takzvanou hranu, kde na jedné straně je prostor, kde se chováme tak, jak jsme zvyklí, jak je nám blízké, jak je u nás obvyklé. Na druhé straně naopak nová kultura, nové zvyklosti, nové chování. Na úplném začátku, když týmu řeknete, že mají přejít na Scrum, jsou v té změně často úplně dole. A cesta na druhou stranu se zdá být nemožná. Tohle nikdy fungovat nebude. Je to celé nesmysl.

Dynamika zmeny kultury - resistence

Jediným lékem je vysvětlování. Tisíckrát kolem dokola. Proč to chceme, co že to vlastně chceme, proč je to pro nás důležité. A po tisíci a prvním pokusu najednou zjistíte, že se tým už Scrum chce, tuší, jak by to mělo vypadat, ale ztrácí se v tom, jak toho nového přístupu a kultury dosáhneme. V ten moment už proti tomu členové týmu neprotestují, ale stále se ztrácí v tom, co že to mají dělat.

Dynamika zmeny kultury - priklady

Lékem je provázet je jednoduchými situacemi, ukazovat příklady patřící do nového světa a naopak na konkrétních příkladech vysvětlovat proč už nechceme dělat to co dříve. Poslední stav kde firmu většinou nechávám pokračovat samotné a naše spolupráce se zvolní, je špička hrany. Není to zdaleka ještě komfortní stav, ale pochopení změny je už tak daleko, že jsou schopni se přes špičku přehoupnout sami. O to větší radost a pocit uspokojení z toho potom mají. Je to jejich změna, ne moje, takže by to tak i mělo být.

Dynamika zmeny kultury - spicka

Každá změna je komplikovanější než jen jedna hrana. Např. změna na Scrum takových hran v sobě obsahuje mnoho. Pro každého člověka jsou zásadní jiné hrany. Změna, kterou někdo překoná hned je pro jiného zásadní a ‘nepřekonatelná‘. Když si tyto odlišnosti uvědomíte, budete se změnou kultury, přístupu a chování výrazně úspěšnější.

Dynamika zmeny kultury - hrany

Na závěr zbývá už jen dodat, že hrany nikdy nezmizí. Jednu překonáte a objeví se nová. A tak to má být. Jestli vás článek zaujal, podívejte se na mojí knihu The Great ScrumMaster, a když se vám bude kniha líbit, doporučte ji svým kolegům a známým, anebo mi napište recenzi na Amazon.

Co dělá ScrumMaster když je tým samoorganizovaný

Dlouho mi vrtala hlavou otázka, co dělá ScrumMaster, když je tým samoorganizovaný. Když totiž přijmeme fakt, že cílem ScrumMastera je ‘nedělat nic‘, tedy že se nemá stát ani asistentkou ani maminkou týmu, ale nechat tým se sám organizovat, je tu problém. Co tedy budu dělat, až se mi to podaří? A protože to byla hodně častá otázka, tady je odpověď.

#ScrumMasterWay

#ScrumMasterWay je koncept, který jsem poprvé popsala ve své knize „Great ScrumMaster – #ScrumMasterWay“, která je dostupná pro Kindle formát na Amazonu a někdy během roku bude k dostání i v papírové podobě. #ScrumMasterWay je tedy odpovědí na otázku nejen co dál, ale i co že to vlastně je ScrumMaster.

#ScrumMasterWay: Můj tým

První úroveň je jednoduchá. Jmenuje se ‘Můj tým‘. V tomto vývojovém stádiu se ScrumMaster většinou stará o svůj development tým. Učí členy týmu pracovat ve Scrumu, společně zlepšují své procesy a praktiky. Tato úroveň je klíčová pro úspěch první etapy Agilní transformace. Cca za šest měsíců byste na této úrovni měli dosáhnout svého cíle a tým by měl být víceméně samostatný v rámci definice self-organized). Bez ohledu na to je ale i v pozdějších fázích transformace důležité se týmu a jeho rozvoji věnovat.

#ScrumMasterWay - MyTeam

#ScrumMasterWay: Vztahy

Druhá úroveň #ScrumMasterWay konceptu se zaměřuje na vztahy týmu s okolím. ScrumMaster už se nemusí tolik věnovat rozvoji týmu samotného, protože jeho členové už umí lépe komunikovat, spolupracovat a zlepšují se. V této vývojové fázi se ScrumMaster primárně zaměřuje na bezprostřední okolí development týmu. Jak funguje vazba týmu a Product Ownera? Jak zná zákazníka a chápe business value? Jak řídíme produkt a jaké metody Agile Product Ownershipu používáme? Jak si tým rozumí se svým managerem? A jak se nám spolupracuje s ostatními týmy? To všechno jsou otázky které vedou ke zlepšení okolí týmu a rozšíření principu samoorganizace na větší celek. V této fázi Agilní transformace obvykle nahrazujeme poslední zbytky tradičního mindsetu Agilní kulturou zaměřenou na spolupráci a převzetí zodpovědnosti. Za cca rok byste měli být na dobré cestě a mít čas se jistou část svého dne věnovat i třetí úrovni #ScrumMasterWay konceptu.

#ScrumMasterWay - Relationships

#ScrumMasterWay: Systém

Poslední úroveň #ScrumMasterWay konceptu je zaměřena na systém jako celek. ScrumMasteři se dívají se na celou organizaci nebo její část jako na systém a aplikujete koncepty jako system thinking, organization and relationship coaching, management 3.0, apod., aby self-organizaci rozšířili na úrovni organizace jako takové. V této úrovni je důležité se zaměřit na mindset, kulturu a hodnoty v rámci celé organizace. ScrumMasteři většinou pracují jako tým a dorostli do opravdových leaderů, kteří organizaci posouvají o stupeň dál.

#ScrumMasterWay - Entire System

Pohybovat se na všech třech úrovních #ScrumMasterWay konceptu je náročné. Je to hodně práce, která na ScrumMastera klade vysoké nároky, aby se stal enterprise Agile coachem, zlepšil se ve facilitaci, ale hlavně se stal leaderem, který organizaci posouvá dál. Ač na některých úrovních #ScrumMasterWay  konceptu budete jako ScrumMasteři trávit většinu času, nezapomeňte, že ostatní úrovně jsou neméně důležité.

Agilní Marketing

Už máte Agilní SW část firmy a zajímá vás co dál? Tak můžete začít třeba na marketingu. Agilní Marketing začíná být čím dál tím častěji skloňovaným tématem. Svět se změnil. Je rychlejší, dynamičtější, a vyžaduje zcela jiný přístup k produktu a marketingu. Tradičně marketingová oddělení produkovala jednorázové reklamy, videa, texty. Dnes musíte cíleně produkovat specifický obsah pro každou cílovou skupinu. Je to dlouhodobá aktivita. A výsledky nejsou vidět hned. Proč tomu tak je? Protože chování zákazníků se změnilo. 80% zákazníků si dnes najde a následně vybere produkt samo na internetu ještě předtím, než se setká s prvním obchodníkem. A vy chcete ovlivnit, aby si sami vybrali právě váš produkt. Na to reaguje digitální marketing, který pravidelně a konzistentně generuje zajímavý “kontent”, který případné zájemce přesvědčí.

Proč tedy Agilní Marketing… Firmy dnes generují spousty funkcionalit, ale málo z nich se zaměřuje na doručení plnohodnotného zážitku svým zákazníkům. Málokdo dnes zkoumá, jak zákazníci reagují, co se jim líbí, komunikuje s nimi, odpovídá na otázky a stížnosti. Agilní přístup k Marketingu vás přesně k tomu vede.

Jak začít. V podstatě můžete aplikovat standardní Scrum. Postavit cross-functional content tým, ScrumMastera, Content Ownera – lidi z marketingu mají často problém porozumět co je to vlastně produkt, tak se zdá, že ‘kontent‘ je snáze pochopitelný. Společně vymyslíte vizi, popíšete persony a vytvoříte Backlog. Stejně jako u softwarových týmů, je klíčová schopnost prioritizovat business value a aplikovat koncept jednoduchosti (simplicity). Jednotlivé položky backlogu napíšete ve formě UserStory a ty pak content tým ohodnotí třeba pomocí Planning Pokeru. A pak už jen naplánujete Sprint a spolupracujete na vytváření obsahu (contentu). Na konci Sprintu uděláte Retrospektivu a Sprint Review, a pravidelně získáváte zpětnou vazbu od vaší cílové skupiny. Nic složitého, nic co by potřebovalo cokoli specifického a jiného, než je standardní Agilní Manifest a Scrum.

Jestli se o tom chcete dozvědět víc, doporučuji si přečíst knihu Jeff Julian – Agile Marketing: Building Endurance for Your Content Marketing Team, anebo se domluvit na workshopu, který pro vaši firmu rádi uspořádáme.

Scaling Agile and Scrum

Poslední dobou se vyrojila spousta různých metod jak škálovat Scrum a Agile proces na prostředí velkých produktů. Takže než se chytíte do sítě různých klasicky smýšlejících organizací, které ve Scalingu konečně našly cestu jak naoko aplikovat Scrum, ale praktiky nemuset měnit, tak se zkuste podívat na zcela Agilní přístup jak na to.

Není na tom nic až tak složitého.  Jen musíte rozumět tomu, co je opravdu Scrum. Není to totiž proces jak řídit vývoj, ani něco kvůli čemu máme Backlog a Standupy, ale přístup, filosofie a kultura. Obecně se tomu říká empirický proces. Tedy velice volně definovaná pravidla hry. Každá taková Scrum hra má své hřiště s pevně danými mantinely a pár pravidly jak hrát. Jinak by to byl chaos. Ale už neříká, co přesně v které situaci musíte udělat. K tomu jsou definované best practices. A Scaling Scrum je často ukázkou, jak k tomuto problému lze přistoupit neagilně a nescrumově – tedy kolem Scrum týmů vytvořit složité byrokratické struktury nových rolí, procesů,  meetingů, pojmů.  Viz obrázek, kde ta bílá plocha je to, co je původní Scrum.

Opačný přístup zvolil Bas a Craig s frameworkem LeSS. Stejně tak, jako když Ken kdysi dávno definoval Scrum a měl možnost si zvolit, které praktiky budou součástí Scrumu a které ne, volil spíše méně než více. A protože Scrum je něco, co se stále vyvíjí, je dnes na rozdíl od začátku nedílnou součástí Scrumu Retrospektiva, ale například story pointy, User Stories and Scrum Board jsou jen doporučené praktiky. Proto je Scrum tak úspěšný. Je totiž aplikovatelný úplně kdekoliv. Když se vrátím k LeSS Large-Scale Scrum frameworku, tak přesně to je hlavní filosofií LeSS – ‘Do more with LeSS‘.

Co se tedy podle LeSS musí změnit proti jednoduchému obrázku, kde máme jen jeden Scrum tým? Na první pohled nic zásadního. Pořád máme jeden stejný Sprint, jeden ‘potentional shipable product increment‘, jeden kód a continuous integration. Pořád máme cross-functional týmy které dokážou jako tým samostatně dokončit jakoukoli položku z Product Backlogu. Týmy si dělají své vlastní Standupy a Retrospektivy. Pořád máme všichni jeden cíl, dodat hodnotu zákazníkovi. A tak pro jeden produkt máme jeden Product Backlog a jednoho Product Ownera – a nemusíte se bát, zvládne to. On totiž Product Owner nikdy nepracuje sám a i na tom jednoduchém 1-1 obrázku má spoustu pomocníků.

Takže v podstatě jediné, co se změnilo je, že na úrovni development týmů se zajímáme co dělají ostatní týmy, jednotliví členové spolu řeší závislosti. Ne co se týče businessu, protože položky Backlogu jsou nezávislé, ale závislosti v kódu, dané konkrétním řešením dané Story. Dále obvykle posíláme zástupce týmů, aby chodili jako pozorovatelé na Standup ostatních týmů a identifikovali tak včas případné návaznosti a rizika. Na úrovni produktu už není jen na Product Ownerovi, aby před Sprintem vybral priority pro příští Sprint, ale obvykle se takového výběru zúčastní i zástupci týmů, aby zohlednili jejich různé zkušenosti. Nakonec je tu ještě jeden nový meeting – Overall Retrospective – jejímž cílem je udělat retrospektivu na téma jak nám jde spolupráce. A jak se asi dá očekávat, jsou tam ScrumMasteři, Product Owner, a zástupci týmů a koná se vždy po skončení Sprintu.

Nic složitého. A jestli to funguje? Ale jistě. První implementace Scrumu, ve které jsem se ocitla ještě jako vývojář, byla přesně taková. Tři týmy, jeden produkt. Časem jsem byla ScrumMasterem několika týmů právě v takovém uspořádání, tentokrát pro šest týmů. A jako Agilní coach jsem takové uspořádání pomáhala implementovat v mnoha různých firmách. Takže ano, funguje to, je to snadné, je to Agilní, a přináší to výsledky. Jestli jsem vás nepřesvědčila, můžete se podívat na některou z LeSS case studies nebo na detailní popis LeSS Large-Scale Scrum Frameworku.

Global Scrum Gathering® Prague 2015

Tak máme za sebou Global Scrum Gathering, tentokrát dokonce v Praze. Jaké to bylo být chairem takové velké konference (přes 600 Agilních nadšenců z celého světa)? Upřímně, byla to zábava. Bylo příjemným překvapením pracovat s profi týmem, který se stará o logistiku, a věnovat se jen programu a účastníkům.  Takže suma sumárum, skvělé. Jsem moc ráda, že jsem dostala příležitost takovou akci pořádat a ovlivnit její průběh. S výsledkem jsem byla moc spokojená.

Co mě zaujalo? Kolik lidí mluvilo o tom, že nestačí Scrum na úrovni týmů ale, že je nutné se na organizaci dívat jako na systém. Že se organizace jako taková se musí změnit. A že Taylorismus je mrtvý, prostě se přežil. V době digitálních technologií a globalizace tento skvělý management styl z doby industriální revoluce prostě selhává.  A to je stále pro mnoho lidí těžké zjištění. Drží se toho, co kdysi fungovalo jak klíšťata. Jinými slovy dávno jednou na mrtvém koni. Jsou jako zombie (jak jistě víte, správný zombie neví o tom, že je mrtvý…). Je třeba si přiznat, že svět už není jen složitý, jako býval, ale je komplexní. Přináší překvapení. A na ty nelze reagovat procesem a standardizací. Ale nástroji jako System Thinking a Organization and Relationship Systems Coaching.

Global Scrum Gathering je opravdu unikátní akce. Jezdí na ní experti a profesionálové z celého světa. Škoda že tam nebylo moc Čechů, jen přibližně 15 účastníků. Doufala jsem, že i místní nadšenci si nenechají příležitost se taková akce zúčastnit. Důvodem malé lokální účasti je asi cena. A tak na závěr moje doporučení. Je to drahé – ale určitě to co dostanete, stojí za vynaložené peníze a čas. Takže rozhodně doporučuji některý z příštích Global Scrum Gatheringů.