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.

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

Nešvary a nepochopení Standup meetingu

Standup meeting je tak jednoduchý, že by se dalo říct, že je zbytečné o něm psát blog. Ale čím víc týmů vidím, tím důležitější mi přijde si to celé zopakovat.

Nešvar 1: ScrumMaster meeting řídí

V praxi taková věc má různé podoby. Začíná u čistého zahájení meetingu jako třeba “tak pojďme začít“ – jako kdyby tým nevěděl, že je potřeba aby někdo začal. Další nešvar je vyvolávání jednotlivých lidí a nutkavá potřeba je provázet těmi třemi otázkami. A končí to někde u pocitu že ScrumMaster je tu od toho, aby odešel s úkoly a udělal zápis.

Co má správně dělat ScrumMaster je ale pravý opak. Vysvětlit týmu, že to je jejich meeting a nestát jim dál v cestě. Být přítomný a naslouchat, být připraven facilitovat kdyby to bylo třeba, ale jinak je nechat Standup řídit. Je to tak triviální meeting, že to poběží samo už v druhém Sprintu.

Nešvar 2: Je to status

Standup jako status meeting vychází ze zažitých zvyklostí. Statusy jsme dělali vždy, tak co by tenhle divnej meeting byl. Tým se necítí být vlastníkem, a hledá někoho, komu by reportoval. Většinou se té role ochotně ujme ScrumMaster, v některých případech i Product Owner. Vedlejším efektem je, že členové týmu mají pocit, že musí jít do detailů a vysvětlit, na co vše narazili.

Když se budete řídit doporučením v předchozím bodě a nebudete stát před tabulí uprostřed a poutat na sebe všemožně pozornost, poběží meeting sám.

Nešvar 3: Co jsem to všechno dělal

Když začnete hledat, jak má Standup vypadat, doberete se obvykle třech otázek: Co jsem dělal, co budu dělat, a problémy. Klasický průběh je pak obvykle plný vyprávění, co všechno jednotliví členové dělali a jak strastiplný byl jejich den.

Ale to není to, co nás tady zajímá. Správný formát Standup meetingu je ,co jsem dokončil, co dokončím a identifikace problémů. My totiž věříme, že členové týmu strávili svůj den smysluplně. Není to kontrola, jen rychlý check jak stíháme. Tak rychlý, že do maximálně 5-ti minut jsme hotovi.

Nešvar 4: Nepochopení cíle

Zkuste se členů týmu zeptat, co je cílem Standup meetingu. Obvykle se dozvíte, že odpovědět na tři otázky, co jsme dělali, budeme dělat a identifikovat problémy. Nebo status a reporting. V lepším případě aby ostatní věděli, co jsem dělal a jak na tom jsem. To všechno je maximálně to co na Standupu děláte, ale ani v nejmenším to neodpovídá na otázku proč. A pak se často dostanete do problému, kdy tým říká “Jak teď sedíme spolu, je zbytečné Standup dělat. Řekneme si to vše během dne, přeci s problémy nebudeme čekat na Standup.“ A oni mají pravdu, že?

Jenže ono sdílení informací není cílem, jen prostředkem k rychlé odpovědi na otázku ’Stihneme dokončit, co jsme slíbili – tedy všechny položky Sprint Backlogu v dané kvalitě?‘ A jestli ne, co musíme udělat, abychom toho stihli maximum. Je to takové to pravidelní zastavení se, zamyšlení se jestli chceme něco změnit nebo pokračovat a jedeme dál. Proto se tam žádné detaily neřeší.

Na závěr: Standup je ideální místo kde můžete začít svou cestu ke Scrum 2.0. Tedy nejen naoko přejmenovat staré meetingy a role na nové a navlíknout trička my jsme Scrum tým, ale začít s opravdovou změnou mindsetu, přístupu a kultury. Protože to je teprve ten pravý Scrum.

Jak poznat že se tým zlepšuje

Pro všechny managery, ScrumMastery a ostatní co se mě na to ptají.

Jestli čekáte, že vám poradím něco snadno změřitelného, tak vás asi zklamu. Tým se zlepšuje pokaždé v jiné oblasti. To nejde dopředu naplánovat. Na druhou stranu, jak to tedy poznáme? Není nad to jít se podívat. Prohodit pár slov. Do něčeho jen tak šťouchnout. Když to uděláte, zjistíte, že je zcela diametrální rozdíl mezi špatným týmem – který moc nefunguje, dobrým týmem – který tak nějak funguje, je ok, ale žádná sláva to není – a tím opravdovým týmem, který funguje skvěle – můžeme mu říkat třeba self-organized tým, Scrum tým, nebo high-performing tým. Dám příklad, o čem mluvím.

Ta úvodní věta, kterou tým polechtáte, může být třeba „ta tabule je dost k ničemu, nic z ní není vidět“… Nebo cokoli co vás zrovna napadne. Jakákoli ‘pitomost’.

‘Špatný tým‘ buď nereaguje vůbec, není to totiž jejich tabule, ani jejich rozhodnutí ji mít. Dělají jen to, co musí. V horším případě začnou na někoho ukazovat prstem, hádat se a říkat, že to oni nic, že to je vina kolegy, ScrumMastera, managera nebo Scrumu jako takového. Je to reakce malého řvoucího vztekajícího se dítěte.

‘OK tým‘ se většinou urazí, protože jak si někdo z venku týmu dovoluje nás kritizovat. Vždyť o nás nic neví. A buď vám vynadají rovnou, což je zdánlivě lepší varianta, protože máte jistou malou možnost to vysvětlit a začít diskusi, ale oni stejně většinou neposlouchají, tak to vyjde nastejno, jako druhá možnost, kdy si jdou následně stěžovat. Oni přeci jsou dobrý tým, všechno jim přeci funguje. Tak co? Je to reakce hodně frustrovaného labilního teenagera.

Je to analogie situace, kdy se jeden náš zaměstnanec rozčiloval, že nedostal prémie. On přeci vykonal všechno, co mu jeho vedoucí zadal. Tak na ně má nárok. Plní vše, co předpisy říkají. Ale to není to, co dneska firmy potřebují od svých lidí. Starají se o ně, dávají jim prostor, rozvíjejí je a očekávají, že budou takzvanými ‘kreativními workery‘, že u své práce budou přemýšlet a přicházet s nápady, jak to, co dělají dělat lépe. O tom je celý Agile a Scrum.

‘Opravdový tým‘ na takové šťouchnutí reaguje jako sebevědomý dospělý člověk, který se dříve nějak rozhodl, za svým rozhodnutím si stojí, ale není to žádný fanatik a rád se dozví, proč má někdo jiný názor. Je ochoten se nad tím zamyslet a ví, že pohled zvenku často vidí věci, které se lidem zevnitř staly neviditelnými. Obvyklá reakce je „no to je zajímavé, my si to nemyslíme, proč si to myslíš?“

Je to vstup do diskuse, kdy obě strany jsou ochotny si naslouchat a něco se dozvědět. Opravdový tým totiž ví, že ‘perfection‘ není stav, ale cesta. A v tomto kontextu vnímají i Agile a Scrum. Neustále hledají, jak se zlepšit.

Agilními ani ‘Scrumovými‘ se nemůžete stát. Je to přístup k životu, práci, činnostem. Je to kultura a filosofie. Stejně jako koupě růžence z vás neudělá věřícího, stejně tak ani Standup a Retrospektiva z vás neudělají Agilní firmu. Jsou to príma věci. Ale není to cíl, jen prostředek.

Jak tedy poznat že se tým zlepšuje? U prvních dvou je to jasné, dáte si pozor, že směřují o stupínek dál. Že z dítěte roste teenager, a z teenagera dospělý člověk. Co ale dál? Řekla bych, že když tohle pochopíte a máte opravdový tým, stane se tato otázka zbytečná, protože je to najednou jasné. Ale pro úplnost u dospělého opravdového týmu hledáme, jestli jsou lidi proaktivní, přicházejí sami s nápady, jak se zlepšit. Jestli mají jeden cíl, nebo bojují každý za sebe a jsou jen skupinou jednotlivců. Jestli vědí, proč se rozhodli tak, jak se rozhodli. Jestli jsou ochotni převzít ownership sami za sebe. Jestli jsou ochotni převzít plnou zodpovědnost (tak jak ji definuje Christopher Avery Responsibility process) za to, co dělají a nevymlouvají se, tedy zodpovědnost v kontextu co s tím uděláme my, aby se to příště nestalo, co změníme u sebe, jak budeme reagovat příště.

Na závěr varování: jestli z tohoto posledního odstavce uděláte tvrdé metriky typu KPI: A) Každý tým musí vymyslet tři zlepšení týmové práce za kvartál, dvě zlepšení na úrovni produktu a jedno na úrovni firmy. B) Každý člen se musí podílet na fungování alespoň jedné ‘improvement skupiny’. Asi nemusím dál pokračovat. Dopadne to stejně blbě, jako když za metriku kvality týmu použijete zvyšující se nebo striktně konstantní velocity. Zabijete poslední zbytky důvěry a veškeré pokusy o to, vytvořit normální prostředí včetně Agilu a Scrumu skončí neúspěchem.

Myšlenka na závěr… Nenapsala já jsem vlastně návod, jak zabít Agile a Scrum? 🙂 Možná, ale to už umíte i beze mne. Doufám, že vám to pomohlo.

Co mi dal Organization and Relationship Systems Coaching – ORSC

O tom jak se stát Agilní a kde primárně vidím využití Organization and Relationship Systems Coachingu – ORSC jsem psala minule. A protože to bylo hodně obecné, zkusím uvést pár příkladů, co mi to dalo. Celý kurz byl organizován do pěti modulů: Fundamentals, Intelligence, Geography, Path a System Integration. První část jsem měla v Londýně, zbytek v Kanadě. Ostatně cestování mě vždy bavilo, tak proč ne. Jak již jsem psala, Organization and Relationship Systems Coachingu – ORSC je zaměřený na coachování systému – tedy týmu, departmentu, organizace a jeho vztahů. A každá část se na to celé dívala z trochu jiného úhlu. Až závěr – Systém Integration – ve finále propojil všechny pohledy do jednoho. Bylo to celé hodně praktické. Business scénáře střídaly coachovaní soukromých vztahů a problémů v nich.

Tady je pár konceptů, které mě vzhledem k agilním týmům zaujaly (a protože pár už jsem popsala v angličtině, najdu nějaké další):

3^rd Entity

Je metoda, kterou nás učili jako jednu z prvních. Asi proto, že je relativně snadná. Od té doby jsem toto cvičení použila v nejrůznějších podobách a velmi úspěšně. Podstatou je, že jako kouč nechám klienta se podívat na svůj vztah s někým z různých úhlů. Jak situaci vidím já, jak ji vidí druhá strana a jak z ptačí perspektivy vidím náš vztah. Je to coaching, takže nejde o vaše pochopení, ale aby si koučovaný uvědomil jaké má možnosti a co může v dané situaci udělat. Navíc většina konfliktů se dá dobrou komunikací a pochopením druhé strany vyřešit. To celé se dá samozřejmě dělat se skupinou, což je pro mě obvykle to zajímavé.

Allignment coaching

Allignment coaching se používá při řešení konfliktů, kde není snadné dosáhnout dohody. Například rozvody, ale i v business světě třeba přerostlý konflikt mezi kolegy, podřízeným a šéfem, problémy v týmu. Stejně jako obvykle v Organization and Relationship Systems Coachingu nehledáme řešení, ale snažíme se posílit vztah natolik, aby byl dostatečně silný pro to najití vlastního řešení. Důležitou součástí je taková zajímavá drobnost, kdy identifikujete problém a pak ho v nějaké fyzické interpretaci dáte před koučovanou skupinu. My používali například sešit. Když se to udělá dobře, psychologicky to skvěle zafunguje. Zajímavé, že i taková blbost jako sešit, který leží před vámi a reprezentuje váš problém, funguje tak, že vám umožní situaci vidět z jiného úhlu. Samozřejmě je třeba ještě dobře vyventilovat frustraci, než začneme něco dávat dohromady. A pár dalších věcí, ale celkově je allignment coaching velmi zajímavá praktika. A funguje – ostatně věci, které mi zatím nešly, tady nepíšu 🙂

Role

A na závěr jedna z těch složitějších věcí. Pozadí konfliktů je často zapříčiněno špatným rozložením rolí a očekávání od nich. Jeden modul jsme se tedy věnovali tomu, jak role kterou mám, nemusí odpovídat tomu, kterou roli chci mít nebo mám mít, a jaký vliv má taková situace na systém. Příkladem může být změna z klasické individuální práce specialisty vývojáře na týmově orientovaného člena development Scrum týmu. Pro některé týmy je to snadné, pro jiné zcela nepřestavitelné jak to teď nově ve Scrumu bude fungovat. A podobné scénáře jsme ORSC nástroji řešili. Celé je to o to složitější, že role mají několik úrovní – nejen tu primární (např.: developer / tester), ale vnitřní (odpovídající vlastnostem), skryté (v podobě psychologických aspektů osobnosti, kterých má v sobě každý několik) a takzvané duchy (kterými může být někdo, kdo už u nás dávno není (např. bývalý šéf Honza, šikovný tester Karel, protivný analytik Franta). A to vše pravděpodobně má vliv na tým jako takový. Některé role jsou nejasné, jiné v systému chybí, některé další sice teoreticky existují, ale nikdo je nevykonává. To v běžných situacích není problém a týmy se sami přizpůsobí, ale existují situace, kde už to z nějakého důvodu nejde tak snadno a pak přichází na řadu tento specifický coaching, který týmu odkrývá, kde mají problém.

A to samozřejmě zdaleka není vše. Navíc žádný z těchto ORSC nástrojů se obvykle nepoužívá izolovaně. Některé jsou vhodné pro řešení konfliktů, jiné zprostředkovávají pochopení situace z různých úhlů, další cílí na zlepšení, kreativitu, ujasnění si smyslu našeho směřování. Je to hodně rozmanité. Ale to coaching je vždy. Z osobního či týmového coachingu se posouváme na enterprise level, tedy můžeme mluvit o enterprise coaching a enterprise coachovi.

Jak vybudovat Agilní organizaci – Organization and Relationship Systems Coaching (ORSC)

Nedávno jsem prošla docela náročným, a to jak časově tak komplexitou, tréninkem Organization and Relationship System Coaching – ORSC. K čemu je to dobré? Umět posunout firmu na další level. Není to zaměřené na jednotlivce, ale na týmy, oddělení a celé organizace. A není to ani explicitně specializované na Agilní prostředí, nicméně je to v obecné rovině zaměřené přímo na ‘Level 3‘ mé práce, tedy jak posunout firmu, která už Agilní je, na další level. Ale začněme pro jistotu od začátku. Zkusím v rychlosti na jednoduchém modelu vysvětlit, jak vlastně dneska pracuji. A pokud to již znáte, můžete přeskočit rovnou na ‘Level 3: Next level‘.

Level 1: Školení týmu

Obvykle to začíná workshopem. Jako první krok uděláme dvoudenní školení pro jeden pilotní tým nebo samozřejmě i rovnou všechny vaše týmy, když už máte jasno v tom, že Agile je ta cesta, kterou se chcete vydat. Předcházet může půldenní workshop s managementem, kde si ujasníme očekávání od takové změny. Projdeme přehled Agilních přístupů, praktik a metod, kde se na závěr společně domluvíme, jak začneme. Je to o předávání zkušeností s Agilními přístupy, ale hlavně o nastartování změny mindstetu a celkové kultury. Na jak dlouho to je? Stačí dva dny prakticky vedeného workshopu.

Level 2: Transformace

Když už nějaký základ máte a chcete pokračovat dál, je tu fáze zvaná Agilní transformace. Co to znamená? Že jste se rozhodli, že do toho opravdu jdete. Že vaše očekávání od takové změny je dostatečně velké a díky nim dokážete změnu dotáhnout do konce, jinými slovy že vám to stojí za to. A nikdo nesliboval, že to půjde samo, ani že to bude snadné. Každá změna něco stojí, takže i při Agilní transformaci budeme narážet na spoustu nedorozumění, nepochopení, resistence, překážek, ale samozřejmě i úspěchů již na úplném začátku.

Agilní coaching se zaměřuje převážně na Scrum Mastery, Product Ownery a managery. Je to o facilitaci, coachingu, vysvětlování Agilních praktik, a hlavně praktických doporučení. Je to fáze, která má změnu dotáhnout do konce tak, aby vám přešla do krve, aby byla dlouhodobě udržitelná a prostě fungovala. Zkušenosti z Agilních týmů v různých prostředích je tu zcela klíčové. S čistou teorií si tu nevystačíme. Jak dlouho taková fáze trvá? No obvykle 3 měsíce až rok, v závislosti na kontextu a velikosti firmy. Intenzita obvykle jeden den za Sprint.

Recharge

No a následuje třetí level … Ne však vždy rovnou po Agilní transformaci, ale často je mezi těmito dvěma levely takzvaná ‘Recharge‘ perioda, kdy firma pokračuje sama, spokojená s tím jak se transformace povedla. Pozvolna se zlepšuje, zkouší nové věci, posouvá se dál. Po nějaké době ale získá pocit, že by byl třeba nový pohled, že by bylo potřeba to posunout o level dál. A je čas na Level 3 a Organization and Relationship Systems Coaching.

Level 3: Next level

Poslední fáze tzv. Next Level vás posune vždy o kus dál. Obvykle se jedná o firmy, které už Agilní jsou, rozumí konkrétním metodám nejen po povrchu, ale mají i vlastní zkušenost. Ale v podstatě můžeme takhle pomoct jakékoli firmě či týmu bez ohledu na to jestli jsou Agilní či ne. Použité principy a postupy postě fungují obecně, což je fajn. Je to chvíle, kdy vám to jde, ale někde v kostech cítíte, že by to mohlo jít lépe. V takový okamžik přichází na řadu coaching na úrovni systému. Tedy týmu, oddělení, nebo organizaci jako celku. Samozřejmě v Agilním světě jsou tyto metody doplněné znalostmi a zkušenostmi z Agilního světa. Na rozdíl od individuálního coachingu tu klientem nejsou jednotlivci, ale páry a skupiny, tedy systém. Nezaměřujeme se na vyřešení konkrétních problémů jednotlivců, ale na celou entitu a vytvoření, zlepšení či upevnění vztahů mezi jednotlivými lidmi, protože dobře fungující systém si takové problémy už zvládne vyřešit sám. V rámci Organization and Relationship Systems Coachingu se díváme na tým, oddělení, nebo firmu z ptačí perspektivy a v rámci coachingu takovým entitám pomáháme vidět věci jinýma očima. V podstatě coach nastaví celému systému zrcadlo, ve kterém nejsou detaily ani individuální pohledy jednotlivců na věc, ale je vidět jak celý systém funguje. A právě ORSC je frameworkem, který na takové úrovni pomáhá coachům pracovat. Není to snadné, chce to tréning. Ale funguje to skvěle. Věci, se kterými klasickými metodami nejde hnout, se najednou odblokují.

Jak jsem již psala, Organization and Relationship Systems Coaching – ORSC je framework který je zaměřený na páry a skupiny. Spektrum použití je opravdu široké. Pomáhá úspěšně řešit konflikty ať již v osobním životě, nebo pracovním. Je výborný pro zvýšení motivace, posílení aktivity týmů, pomáhá takové týmy tvořit.

A tak třebaže ORSC není přímo zaměřený na Agilní svět, je v tomto prostředí výborně použitelný. Protože o čem jiném je Agile než o schopnosti spolupracovat a vytvořit dobrý tým – ať už se zaměříte na development tým, Scrum tým, celý produktový tým, nebo virtuální týmy které jdou přes celou organizaci a starají se například o lepší Continuous Integration nebo testing. V tomto kontextu je OSRC ideálním souborem nástrojů jak takový Agilní tým postavit a udělat rychle efektivní a funkční.

Tahle fáze je obvykle periodická. Může probíhat s frekvencí 3 dny dva až třikrát do roka, nebo intenzivněji, řekněme den v týdnu po dobu 3-6ti měsíců s následným delším rechargem. ‘Perfection’ totiž není cíl, ale cesta. Tedy řečeno jinými slovy, ideální tým neexistuje, ale pokaždé je tu nějaký prostor jak se zlepšit. Japonci tomu říkají Kaizen, Agile a Scrum to nazývá continuous improvement. Ale v každém případě je tady v každý okamžik prostor pro změnu a zlepšení. A takový prostor v této fázi hledáme a využíváme.

Planning meeeting na 30 minut – část 2

Jak jsme již říkali v minulém článku, celý Planning meeting se komfortně vejde do 30ti minut. Pojďme se tedy podívat, jak vypadá jeho druhá část. Tým má vybrané User Story na tabuli a v rámci této fáze rozpadá jednotlivé funkcionality na konkrétní činnosti, které nebudou podle jejich předpokladu větší, než aby šly dokončit v rámci jednoho dne.

Na rozpadu pracuje celý tým najednou a paralelně plní tabuli lístečky s jednodenními tásky. Když jednotliví členové týmu rozpad dokončí, společně revidují, jestli na něco nezapomněli. Stejně jako v minulém případě, je dobré se podívat kolik tásků na tabuli vzniklo. Obecně platí, že User Story s vyšším ohodnocením se rozpadá na více drobných aktivit než menší User Story.

Ale není to matematika. Jestli jste naplánovali Sprint Backlog, kde počet lístečků odpovídá práci týmu na dva dny, máte buď příliš nízký commitment, nebo jsou jednotlivé tásky výrazně větší než jeden den, a nebo vám některé aktivity zcela chybí. Naopak, naplánovali-li jste tásků stejně jako je dnů*počet členů týmu, máte vysokou pravděpodobnost, že to nestihnete. Vždycky se něco protáhne a na něco jsme vždy zapomněli. Polovina tohoto čísla může být reálná.

Když jako tým souhlasíte s rozpadem, podíváme se ještě jednou na výsledný Sprint Backlog a eventuálně ho upravíme (přidáme / ubereme nějakou User Story) a o výsledném commitmentu informujeme Product Ownera.

Nutnou podmínkou takového rychlého Planningu je dobrá příprava. Tým nesmí vidět User Story poprvé na Planningu – už se s nimi dobře seznámil na Backlog Groomingu, kde je i ohodnotil. Zanedbat se nesmí ani příprava na rozpad User Stories na jednotlivé aktivity. Tým zná prioroty pro další Sprint několik dní dopředu a může si tak zavčas popovídat o řešení a připravit se na jejich rozpad.

Zkuste a uvidíte, že to není zas tak těžké, a že to funguje. A navíc, jako bonus ušetříte spoustu času a získáte kvalitnější Sprint commitment.

Planning meeeting na 30 minut – část 1

Často s týmy diskutuji na téma, že Scrum jsou jen samé meetingy. A tak začínám tím, že s nimi projdu, jak mají být jednotlivé meetingy dlouhé. Většinou se zasekneme na Planningu, který byste měli v pohodě zvládnout za 30 minut. Jak takový planning vypadá? Tým si nejdříve v cca 15 minutách vybere, které User Story z priorit Product Ownera by mohl dokončit. Ideální je, když opravdu fyzicky vybírá, které z kartiček na stole dá na svoji Scrum tabuli. Jednotlivé User Story a jejich business hodnotu si může tým ještě upřesnit s Product Ownerem, ale výběr je na nich.

Je tedy nasnadě, že jich Product Owner musí přinést dostatek, aby bylo z čeho vybírat. Tým tím přebírá větší zodpovědnost, a také musí produktu po všech stránkách více rozumět, než když jen bere User Stories jednu po druhé podle přesných priorit Product Ownera. Zároveň je to také často efektivnější, protože tým může vybrané User Story přizpůsobit svým zkušenostem a znalostem a optimalizovat tak dokončenou funkcionalitu v rámci priorit Product Ownera.

Fyzická reprezentace ve formě kartiček jako obvykle pomůže. Usnadňuje to týmu převzít kolektivní ownership a zodpovědnost za výběr. Jak jednotliví členové týmu navrhují, které User Stories by tým mohl stihnout, někde se to ve výběru zastaví. A členové týmu si již nejsou jisti, jestli by další věc stihli nebo ne.

Tým si může ještě udělat rychlá cross-check obvyklé velocity, když vyšlo řádově jiné číslo, tak je to dobrý indikátor k zamyšlení se, co nás vede k tomu, že toho tentokrát stihneme dvojnásobek, nebo naopak polovinu, a případné revizi návrhu Sprint Backlogu.

Tady první část Planningu končí, Product Owner i Scrum Master nechávají tým pokračovat druhou 15ti minutovou částí a odchází.

Jako včerejší počasí

Na jednoduchý problém existuje jednoduchá pomoc. Tým neustále overcommituje. Tedy slíbí sedm User Stories a dodá čtyři. Příští Sprint slíbí osm a dodá jen tři, další se zaváže dodat sedm a dodá pět. A tak to pokračuje Sprint po Sprintu. Když se zeptáte co s tím tým dělal, obvykle odpoví, že to řešili na retrospektivě a že příště už se to povede.

Jak dobře odhadovat, kolik se nám toho vejde do Sprintu? Tak předně věřte tomu, že obvyklé věci se dějí obvykle a výjimečné jen výjimečně. Tedy, že když několik sprintů za sebou dodáváte méně, než plánujete, tak se tak asi bude dít i v budoucnu. Důvody pro to se mohou různit, ale na úrovni týmu a Sprintu to vždycky vyjde.

Existuje rychlá medicína. Příští Sprint si do Sprint Backlog vezměte přesně tolik, kolik jste minule stihli dokončit. Takzvaně “včerejší počasí“. Ostatně říká se, že kdyby předpověď počasí byla dělaná podle včerejšího dne, že bude přesnější, než když se ji snažíme odhadovat. Nevím, jak s počasím, ale tady to funguje a výsledek se dostaví okamžitě. A teď, když už to umíme, tak se můžeme pozvolna zaměřit na to, jak rychlost týmu zvednout. Je to první úspěch a na tom se dá stavět. A můžete začít tím, že ho společně zajdete oslavit.

Deset let s Agilem

Kdo by to byl řekl, jak ten čas letí. Tuhle jsem si uvědomila, že to je 10 let, co jsem poprvé potkala Agilní metody. Vše se seběhlo rychle a jak už to tak bývá, tak to bylo hodně i dílem náhody.

Po návratu z dovolené v Etiopii na konci února 2005 jsem se dozvěděla, že za tři týdny odjíždím do USA k našemu zákazníkovi, firmě Medtronic (kdo Medtronic nezná, tak je to jeden z největších světových výrobců zdravotní techniky, fakt velký kolos, kótovaný na burze – MDT). No a než jsem se rozkoukala, byla jsem v Minneapolis, kde má Medtronic headquarter. Spolu se mnou přijelo několik kolegů z Holandské pobočky a společně jsme se měli zapojit do týmů a pomáhat s vývojem aplikací pro kardiostimulátory a defibrilátory. Což je samo o sobě docela legrace. Jenže v Medtronicu v té době začala probíhat docela zásadní změna a to přechod k Agilnímu způsobu vývoje. A já jsem dostala šanci být u toho hned od začátku, takže tak trochu štěstí, i když v té době bychom to asi s kolegou úplně štěstím nenazvali. Šlo to rychle, v podstatně větším stylu než v nějaké malé firmě kde se o všem strašně dlouho diskutuje a řeší se, co by na to který developer či tester řekli. Ale zas na druhou stranu měli jasno v tom, proč to dělají, co očekávají a dali nám podporu výborného Agilního kouče. Začínali jsme rovnou aplikovat Scrum pro více týmů spolupracujících na jednom produktu, učili se spolupracovat, posilovali cross-functionalitu týmů, párově programovali, učili se jak nastavit continuous integration, aplikovali základní Extreme programming (XP) principy a později i Test Driven Development (TDD).

Po návratu do Prahy jsem měla za úkol postavit dva týmy a naučit je Scrum, aby spolupráce úspěšně mohla pokračovat. Tady se ukázalo, jak v různých kulturách jsou různé věci akceptovány různě. Ale po překonání úvodní nejistoty a resistence nám to docela fungovalo. Samozřejmě to prostředí mezinárodní spolupráce a life-critical segmentu nebylo snadné. Distribuované týmy, práce v různých časových zónách, synchronizace více týmů, spolupráce několika Scrum Masterů. Prostě komplexní prostředí, se všemi klady i zápory.

To že jsem se Agile a Scrum neučila v male firmičce či startupu o 10 lidech, ale ve velké korporaci se mi v podstatě hodí do teď. A bylo dobře i mít zkušenost z life-critical segmentu. Člověk si hned vyzkoušel, jak takové věci fungují ve složitém prostředí a následná aplikace na menší firmy už to vlastně všechno jen zjednodušovala. Byla to super škola a zkušenost.

Když jsem nakonec začala pracovat jako Agilní Coach ve své vlastní firmě, byly to zkušenosti k nezaplacení. Jak šel čas, pomáhala jsem malým startupům, firmám které rychle vyrostly, různým korporacím, produktovým firmám i společnostem dodávajícím služby v oblasti vývoje SW. V množství různorodých klientů byly i marketingové firmy, operations týmy, HW firmy. Pracovala jsem s distribuovanými týmy USA-Evropa-Asie. Takže 3 časové zóny a hlavně kulturní rozdíly. Přeci jen Vietnam či Indie je kulturně hodně odlišné prostředí a to se v implementaci Agilních přístupů projeví. I přes časté cesty do zahraničí mám stále většinu práce doma v Praze, hodně jsem i v Brně a na Slovensku.

S kolegy jsme před několika lety založili Agilní Asociaci (agilniasociace.cz), kde v rámci lokální Agilní komunity umožňujeme sdílení zkušeností z Agilního světa. Pořádáme pravidelná otevřená setkání tzv. open café a každoroční konferenci Agile Prague (agileprague.com). Ale tu určitě znáte – a kdyby náhodou ne, letos bude 14-15. září v Praze na Pankráci.

Sama se snažím hodně cestovat na různé konference, sbírat nápady jak pro týmy, kterým pomáhám Agilní metody pochopit, tak právě i pro konferenci Agile Prague. Jedna z nejzajímavějších zkušeností byla přednáška na konferenci Agile 2012 v Texasu – pravděpodobně největší Agilní konferenci na světě. Přednášela jsem i na několika Scrum Gathering konferencích, kde je většina přednášek praktická, formou mini-workshopů. Své zkušenosti s Agilními metodami jsem se snažila shrnout v knize “Agilní metody řízení projektů”, která se během půl roku vyprodala, takže musel být vydán dotisk. Bylo docela příjemné zjištění, že ta kniha hodně lidem pomohla a často si ji chválí. V loňském roce jsem se zase profesně posunula dál, díky získání certifikace od Scrum Alliance – Certifikovaný Scrum Trenér (CST – Certified Scrum Trainer) tak mohu také školit certifikační kurzy, jako například certifikovaný ScrumMaster (CSM – Certified ScrumMaster). Nejde ani tak o certifikaci, které můžu školit, ale o možnost být součástí Scrum světové špičky. Začala jsem vlastně náhodou a jsem ráda, že se mi tím složitým procesem podařilo úspěšně projít.

Je to až neuvěřitelné, co se za těch deset let všechno událo. Za to, že se vše povedlo, ale musím poděkovat hlavně i vám všem, kteří jste mě během těch let pomohli – ať již jako zákazníci anebo kamarádi při některé z mnou/námi pořádaných akcí. Díky moc!

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.