Od koho a jaká Scrum certifikace má opravdu hodnotu

Za autora Scrumu je považován Ken Schwaber a Jeff Sutherland. První veřejné školení Scrumu ale nakonec prý realizoval Ken Schwaber společně s Mikem Cohnem. Ono to možná nakonec není až tak důležité, kdo byl a nebyl první, důležité je, že všichni tito zakladatelé Scrumu a dnes vlastně Scrum legendy se v té době sdružili pod křídla Scrum Alliance, kterou založili v roce 2002 (zakladatelé byli Ken Schwaber, Mike Cohn a Esther Derby). Tím se vlastně Scrum Alliance stala první certifikační autoritou, která vydávala Scrum certifikace. Vznik certifikací nepřímo zapříčinila firma Xerox, která potřebovala své zaměstnance nejen proškolit ale i ocertifikovat – tak vzniklo CSM – Certified ScrumMaster.

Postupem času se cesty Kena a ostatních z původní Scrum komumity rozešly, Ken Schwaber si založil Scrum.org a Scrum Alliance pokračovala dál v započaté cestě. Obě tyto společnosti vydávají certifikace na Scrum proces, ale postupem času se jejich přístup k certifikacím diametrálně rozešel. Výsledkem je, že Scrum Alliance se drží původního myšlenky, jak certifikace udělovat a jak držet jejich kvalitu a vydává certifikace, které dnes mají na trhu opravdovou hodnotu. Díky tomu také jejich počet prudce roste a i pozice Scrum Alliance na světovém trhu. Je skvělé, že aktivní součástí Scrum Alliance je dodnes Jeff Sutherland, jeden ze spoluautorů Scrumu. Tím je zabezpečena kontinuita, aktuálnost, ale také kvalita. Ostatně podívejte se na poslední aktualizaci Scrum Guidu – je z roku 2016 a stojí za ním Jeff Sutherland (Scrum Alliance) a Ken Schwaber (Scrum.org).

Nikdo neříká, že nemůžete Scrum umět bez certifikace či certifikace je zlatý grál. Samozřejmě není. Ale pokud o certifikaci opravdu uvažujete, tak si dobře rozmyslete, od koho certifikace je. Díky popularitě Scrumu různá uskupení tvářící se jako certifikační autority tuší zisk snadných peněz – vždyť stačí test za pár dolarů a certifikace je vaše. Ale v tomto případě má tak cenu papíru, na kterém je vytištěna. Ostatně takový papír s nápisem Certifikace si můžete vyrobit i sami ve Wordu a bude mít úplně stejnou hodnotu. A je smutné, že do této skupiny se před lety přidal i Scrum.org, když umožnili certifikaci jen za test, čímž sami popřeli cestu, po které po založení šli a zcela opustili tlak na kvalitu a jméno certifikace. Když už ale do nějaké certifikace investujete, vždy je dobré mít certifikaci od někoho, kdo je pod Scrumem opravdu podepsaný, rozumí mu, a jehož certifikace má opravdu světově uznávanou platnost – a zde je aktuálně jen 1 možnost: certifikace od Scrum Alliance.

Scrum Alliance jako první certifikační autorita má díky své dlouhé historii celosvětově rozhodně větší impact a vlastnictví certifikace od Scrum Alliance je rozhodně výborná volba. Navíc v ČR a na Slovensku školení s certifikacemi od Scrum Alliance dlouhodobě a úspěšně pořádá několik společností a tyto certifikace jsou i na našem trhu velmi dobře známé a uznávané. Školení mohou vést pouze certifikovaní trenéři, kteří musí splnit opravdu náročné podmínky. Získání licence Certified Scrum Trainer není vůbec snadné a certifikační proces trvá rok a déle a zdaleka ne každý v něm uspěje. Díky tomu je laťka na kvalitu školení nastavena opravdu vysoko, čímž se drží i vysoký standard certifikací.

K získání je několik certifikací, ať nejoblíbenější CSM – Certified ScrumMaster, pro produkťáka CSPO – Certified Scrum Product Owner, či developerská CSD – Certified Scrum Developer či relativní novinka pro managery a leadery organizací CAL1 – Certified Agile Leadership I a následný program CAL2 – Certified Agile Leaderhip II. Jako další level je tu Advanced level, tj. A-CSM a A-CSPO po kterém následuje level professional CSP – Certified Scrum Professional kde držitelé musí prokázat praktickou zkušenost se Scrumem. I tento professional level se dnes dělí na dvě možnosti podle role, tj. CSP-SM a CSP-PO. A následně CTC – Certified Team Coach a CEC – Certified Entrprise Coach kteří spolu s CST – Certified Scrum Trainer jsou těmi pravými pomocníky s Agilní transformací.

Jinak pro představu ScrumAlliance je založená jako non-profit organizace, která se snaží investovat do Agilní a Scrum komunity. Pořádá pravidelně každý rok tři globální Scrum Gatheringy (Evropa, USA, Asie), a spoustu regionálních Gatheringů, coach campů, sponzoruje menší konference, podporuje lokální komunity. Mezi trenéry jsou opravdové legendy, ať už zmiňovaní Jeff Sutherland a JJ Sutherland, Mike Cohn, autoři LeSSu (Large Scale Scrum) Craig Larman a Bass Vodde, Maria Matarelli, která posouvá Agile a Scrum za hranice SW vývoje a zaměřuje se na Agilní marketing, Joe Justice, který je expert na Scrum v HW oblasti, Hendrik Kniberg známý ze Spotify, Roman Pichler, evropská legenda produktového vývoje, a tak bychom mohli pokračovat.

Pokud o certifikaci na Scrum uvažujete, dobře zvažte, jakou certifikaci si vyberete. Rozhodnutí je samozřejmě na vás, ale pokud mohu něco doporučit, vyhněte se tradičním certifikačním agenturám, které certifikují Waterfall – ti Scrumu nerozumí a jejich certifikace v Agilním světě nemá hodnotu. Vyhněte se různým Indickým agenturám s krásnou fotkou sídla v USA. Vyhněte se agenturám, které nabízí certifikaci za test. Agile = Mindset, a to se testem nedá ověřit. A lidé, co se v Agilním světě pohybují, to dobře vědí, a tak tyto certifikáty nemají větší hodnotu než již ten zmíněný kus papíru, co si ve Wordu napíšete sami. Přeji dobrý výběr.

Update: 2019.

Disclaimer: Jsem Certified Scrum Trainer od Scrum Alliance, takže můžete říct, že jsem „zaujatá“. Ale já opravdu věřím, že školeni s certifikacemi od Scrum Alliance vedené jejich certifikovanými trenéry jsou nejlepší a mají na trhu největší hodnotu. Proto neškolím certifikační Scrum školení pro jiná uskupení. Dostávala jsem na toto téma v poslední době opravdu hodně dotazů, doufám že na ně tento blog-post odpověděl.

Knihu The Great ScrumMaster: #ScrumMasterWay vydalo nakladatelství Addison-Wesley

The Great ScrumMaster:#ScrumMasterWay

Začátkem roku 2016 jsme dopsala svoji další knihu The Great ScrumMaster: #ScrumMasterWay, kterou jsem si původně vydala sama jako elektronickou publikaci a distribuovala ji pomocí Amazonu ve verzi pro Kindle a následně si nechala vytisknout i papírovou limitovanou full-color edici v omezeném nákladu. Kniha se prodávala překvapivě hodně dobře a tak jsem si už byla vyzvednout pěkný šek od Amazonu v americkém Wells Fargu – dáte otisk palce a peníze jsou vaše 🙂 A dvakrát vyprodala limitovanou barevnou papírovou edici. Na rozdíl od první knihy Agilní metody řízení projektů (vydal Computer Press v roce 2014) jsem knihu tentokrát záměrně psala anglicky, protože mi přišlo téma výborného Scrum Mastera jako opomíjené a věřila jsem, že mé dlouholeté zkušenosti jsou aplikovatelné celosvětově, nejen u nás v ČR či na Slovensku, a kniha se prosadí. A měla jsem štěstí a tento názor se mnou sdílí i americké nakladatelství Addison-Wesley Professional (součást skupiny Pearson), které patří mezi jedno z největších světových nakladatelství technické literatury, a právě v těchto dnech moji knihu vydává. Mám z toho opravdu velkou radost, že kniha je pod křídly velkého a známého nakladatelství a bude dostupná na celosvětovém trhu.

Cesta k tomu cíli nebyla úplně snadná a opravdu velkou zásluhu na tom má Mike Cohn, jedna z legend Scrumu, kterého kniha nadchla a doporučil ji jako další publikaci do své série, které pro Addison-Wesley dělá editora. Takže má kniha je teď součástí série: Addison-Wesley Signature Series (Cohn) a jsem tím velmi poctěna. Když se podíváte na ostatní knihy v sérii, myslím, že jsem ve velmi dobré společnosti 🙂 Od doby doporučení Mika Cohna uběhlo mnoho času, kdy editoři pracovali na textu a grafici vylepšovali mé kreslené obrázky, než se dnes kniha objevila na trhu, ale o to větší z ní mám radost. Všichni udělali výbornou práci a já jsem ráda, že jsem mohla pracovat s takovým týmem profesionálů.

Zuzi Sochova & The Great ScrumMaster: #ScrumMasterWay bookJak již z názvu vyplývá, v knize se primárně věnujeme roli ScrumMastera. Kdo je dobrým ScrumMasterem, co by měl ideální ScrumMaster znát a umět, jak si představuji cestu ScrumMastera od prvních kroků až do excelentního stavu. Prostě jak se stát tím nejlepším ScrumMasterem na světě :). Nejedná se o žádnou suchou teorii, snažila jsem se udělat knihu hodně praktickou, vizuální, s hodně příklady, tak aby to bylo opravdu prakticky použitelné a realizovatelné v běžném životě.

Kniha čerpá z mých reálných zkušeností z mnoha týmů a firem, definuje nový koncept #ScrumMasterWay, který ukazuje ScrumMasterům cestu jak se stát skvělým ScrumMasterem.

Mně se o knize špatně píše, a tak vám radši rovnou doporučím si ji přečíst. Pokud by vás zajímaly další detaily, na stránce greatscrummaster.com se můžete dozvědět o knize více. Knihu je možné objednávat na Amazonu. Jestli se vám kniha bude líbit, prosím doporučte ji svým známým a kolegům anebo mi napište recenzi a pomozte mi tak knihu dostat do světa.

Doufám, že se vám bude kniha líbit.

Agilní Organizace

Organizace se neustále vyvíjí. V době průmyslové revoluce se svět změnil k nepoznání. Z malých businessů začaly vznikat velké továrny. Bylo potřeba řídit velké množství dělníků a to dalo základy managementu, jak ho známe dnes.

Organization 1.0

organization 1.0Typickou strukturou byla hierarchická pyramida. Moc, motivace a směřování v podobě cukru a biče, pevná struktura a strmý žebříček pozic bylo v té době dobrou odpovědí na aktuální situaci.

Svět se změnil, a organizace se snažily řídit lidi stejně jako stroje. Definovaly fixní procesy, role, pravidla. Nebylo to nijak špatně, protože složitost většiny problémů na které organizace narážely, se daly vyřešit stanovením best practices. Obecně se mělo za to, že zaměstnanci jsou stejně jen líná banda flákačů a tak je potřeba pevný řád a kontrola. Většina lidí se pohybovala v tribal leadership levelu 2 “My life sucks“, tedy “Můj život je nanic“.

Organization 2.0

img_0752-300x225Jak šel čas, a prostředí businessu se stávalo složitější, firmy se měnily a hledaly cestu ve specializaci a rozdělení zodpovědností. Všechno se nejprve zanalyzovalo a pak teprve udělalo. Byla snaha složité problémy moderního světa rozsekat na jednoduché činnosti a ty pak řešit best practices na které jsme byli po léta zvyklí.

organization20

Organizace se předháněly v nových procesech a rolích. Stávaly se komplikovanějšími a neohrabanějšími. Hlavní motivací bylo stát se nejlepší na úkor ostatních. Majorita lidí se pohybuje v Tribal Leadersip level 3 “I‘m great, you are not“, tedy “Já jsem nejlepší, a vy ne“. Je to prostředí optimalizující jednotlivce. Jsou v něm manageři, kteří říkají, co mají ostatní dělat. Vzniká “Leader-Follower“ model. Od zaměstnanců se čeká, že se stanou promazanými kolečky složitého stroje.

Organization 3.0

Leader-follower V současnosti, kdy už svět není ani jednoduchý ani komplikovaný ale komplexní, je třeba umět na změny reagovat. Být dostatečně flexibilní, Agilní, chcete-li. Moderní organizace je uzpůsobená tak, aby neustále hledala a optimalizovala business hodnotu. Už není tak důležité, jak efektivně pracují jednotlivci. Podstatný je celkový výsledek a přínos. Komplexita moderního světa s sebou přinesla takovou složitost, že již není možné věci rozmyslet, popsat procesy, vytvořit zodpovědné role.

Agile organization 3.0Organizace potřebují tvořit adaptivní sítě, které jsou inovativní a kreativní a rychle reagují na změnu prostředí. Odpovědnost se z jednotlivce přenáší na týmy.
Současně s tím je třeba změnit leadership model z “Leader-Follower“ na “Leader-Leader“ kde týmy samy přebírají zodpovědnost a rozhodování v rámci firemní strategie do svých rukou a pomáhají organizaci stát se flexibilní.

Leader-Leader model

Tribal leadership model se postupně mění a většina lidí v takové organizaci jsou v levelu 4 “We are great“ tedy “My jsme nejlepší“. Firma již není tvořena nezávislými specialisty ale týmy, které dohromady tvoří systém. Systém, který je dynamický, flexibilní a dobře reaguje na komplexitu okolního světa. Je to jediná cesta, jak dlouhodobě uspět v současném komplexním světě. Moderní organizace jsou Agilní. Jsou tvořeny z lidí, kteří se vzájemně ovlivňují a spolu v rámci komplexního systému celé organizace reagují na okolní svět. Je to jiný svět, než na který jsme byli zvyklí. Ale je to jediná cesta jak reagovat na to co se děje kolem nás a být dlouhodobě úspěšní.

Agile Organization
Agile Organization

Jak začít?

– Organizace je tak dobrá, jak dobré má leadery. Upřednostňujte “Leader-Leader” leadership model a tvořte kulturu Tribal Leadership modelu “We are great!” tedy “My jsme nejlepší“.

– Decentralizujte, tvořte sítě and komunity. Umožněte autonomní rozhodování v rámci dobře definovaného prostoru.

– přečtěte si mojí knihu The Great ScrumMaster – #ScrumMasterWay která je dobrým průvodcem nejen pro ScrumMastery ale i leadery, managery a ředitele organizace která se chce stát Agilní Organizací 3.0.

Žádný meeting ve Scrumu není klasický status meeting

Víte, že žádný meeting ve Scrumu není klasickým status meetingem?

Daily Scrum (Standup meeting)

Začněme Standupem, kde antipaternem je, že jednotliví členové týmu reportují, co všechno dělali a co dělat budou. Asi aby je ScrumMaster nebo ostatní členové mohli kontrolovat.

Standup je tu ale proto, aby se tým a jeho členové každý den rychle zastavili a řekli si, jestli jdou správným směrem a jestli ještě stále věří tomu, že zvládnou dodat Sprint Goal. Proto nekontrolujeme, čím trávili čas, ale soustřeďujeme se na to, co je hotovo, a jak budou spolupracovat na tom, co mají teprve dokončit.

Sprint Review

Dalším v řadě je Sprint Review, kde antipatern je prezentovat, které konkrétní UserStory se dokončily a které ne. Spousta týmů status dotáhla do dokonalosti a dokonce ukazuje prezentaci a jakési grafy a vyhodnocuje úspěch a neúspěch Sprintu.

Sprint Review je tu ale proto, abyste ukázali Potentional Shipable Product Increment – tedy to, co tým dokončil – zákazníkovi a získali na základě toho zpětnou vazbu. Ta je potom cenným vstupem pro Backlog Refinement a pomáhá vám dodat úspěšný produkt.

Retrospektiva

Do třetice je tu Retrospektiva, kde antipaternem je začínat Retrospektivu tím že procházíte jednotlivé body z minula a hodnotíte, jak se vám povedly dokončit a jestli zabraly na daný problém.

Retrospektiva ale má být kreativním workshopem, kde se tým zamýšlí nad tím, co by chtěli změnit, co jim vyhovuje, co naopak chtějí zlepšit. Aby fungovala, musíte se na sebe umět podívat jinýma očima, z venku. A když začnete statusem, tak ten nadhled ztratíte a v další fázi pak jen zopakujete, co vám zbylo z minula. Máte-li pocit, že se věci nehýbou kupředu, určitě to na další retrospektivě zazní znovu i bez opakování. A status těch pár Action Items z minula můžete dát na tabuli a skouknout na Standupu.

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.

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.

Složitost světa

Trvalo mi to dlouho, ale nakonec jsem se dobrala porozumění Cynefin frameworku. David Snowden o něm dokáže krásně vědecky vyprávět, ale většinou jsem se v tom někde ztratila a aplikace jeho teorie mi unikala. Takže se pojďme podívat, o čem to celé je, laicky řečeno.  Složitost světa lze klasifikovat několika kategoriemi.

Jasný, triviální

To je svět, kde je na první pohled zřejmé, co máte udělat. Nemusíte to analyzovat ani přemýšlet. Prostě to víte. Je to svět, na který se dá napsat kuchařka. Je to práce u pásu.

Složitý

Tady už se musíte zamyslet. Udělat analýzu. Vymyslet, jak na to. Na základě informací co máte, se rozhodnout. To je svět waterfallu. To je svět, kde si myslíme, že když vše dobře rozmyslíme, tak to pak stačí jen udělat podle plánu.

Komplexní

Tohle je svět, kdy jsme si poprvé přiznali, že nevíme, co se stane. Může to být tak, ale i zcela jinak. Může přijít překvapení.‘Jeejej. On zákazník vlastně nepotřebuje detailní přehledy pro mzdy, přestože je celou dobu chtěl.. jeeejej.. on to vlastně používá jinak, divně, aha, to ale znamená že musíme udělat něco jiného.‘ Určitě jste to zažili. A tady přichází na řadu Agilní přístup s filosofií ‘Inspect and Adapt‘.  Nevíme, máme nějaké nápady, nějaké hypotézy. Tak si je pojďme otestovat a teprve na základě zpětné vazby se rozhodneme.

Chaos

Pak je tu chaos. David Snowden jako příklad uvádí dětskou párty. Ještě jsem žádnou nepořádala, ale asi si to umím představit. Veškeré pokusy to nějak řídit selhávají a vy se omezujete jen na minimalizaci dopadu katastrof, které již nastaly nebo by mohly nastat. I tady se můžete občas se svým softwarem octnout. Třeba když vám spadne produkce a vy se chaoticky jeden přes druhého snažíte ji zase nahodit a tím rozbíjíte další a další věci.

Disorder

Posledním stavem je cosi těžko definovaného uprostřed. Nevýhodou je, že se těžko pozná, do které kategorie daná situace spadá. Zdá se to být snadné, ale… pojďme se raději zamyslet… hmmm těžko říct, zkusíme to… není to zbytečné tím trávit čas… je to přeci snadné, tak to pojďme hned udělat. V takové situaci týmy inklinují k jednoduchým řešením, která ovšem nejsou vždy nejlepším řešením složitých problémů.

Typickým příkladem je nová UserStory v průběhu Sprintu. Je to potřeba, tak to pojďme hned udělat.  Bez ohledu na Scrum. Jenže když tomuto klamu podlehnete, obvykle zjistíte, že to nebylo tak snadné, že to má další konsekvence a výsledek je, že často neuděláte nic a ještě rozbijete něco kolem.

Complexity - Cynefin

SW vývoj

Dalo by se říct, že existují příklady jednoduchého SW např. web pro restauraci, složitého jako web pro konferenci a komplexního pro nový produkt. Ale kdykoliv jsem se snažila dát příklad takové aplikace, zjistila jsem, že ani zdánlivě snadná věc s pár uživateli není v kategorii jednoduchá. A ze zkušenosti s různými většími SW produkty se zdá, že ač některá zadání vypadají snadně, nebo ne moc složitě, většinou končí mnoha iteracemi změn. Tedy jsou v kategorii ‘komplexní’. Tak proč se na ně raději nepřipravit a nepoužít na vývoj SW již od začátku proces, který je vhodný na komplexní problémy – tedy Agile a Scrum. 🙂