Tag: Scrum

Spolupráce dělá lepší organizace

Myslím, že jen málo z vás navštívilo Agile2015 konferenci ve Washingtonu a slyšelo tak keynote – James Tamm “Want Better Collaboration? Don’t be so Defensive!”. Myslím, že to byla jedna z nejzajímavějších přednášek, co jsem za poslední dobu slyšela. O čem mluvil? Vysvětloval, že existují dva typy organizací – červená a zelená. Červená je zaměřená na individuální výkon a soutěživost, zatímco zelená je o spolupráci.

Asi žádná organizace není čistě červená či zelená, ale ty zelenější jsou úspěšnější, a to řádově. Nechci vás ochudit o překvapení, ale podle zdrojů které James uváděl, jsou organizace, kde hlavními hodnotami jsou spolupráce, důvěra, otevřenost, ochota vzít na sebe riziko a zodpovědnost, vzájemná pomoc a optimismus výrazně úspěšnější jak co se týče zisku, tak ceně akcií, tak růstově.

Co takovou organizaci tedy dělá zelenější?

  • Úmysl spolupracovat
  • Pravdomluvnost
  • Vlastní zodpovědnost
  • Uvědomění si vlastních kvalit a nebýt defenzivní
  • Schopnost vyjednávat a řešit problémy

Překvapivě, spoustě organizací nechybí ochota spolupracovat, ale pouze to neumějí. A možná proto mám ráda Agile a Scrum, protože když se dobře aplikuje, Scrum vytváří přesně takovou ‘zelenější’ organizaci a celý Agilní coachig je jen o tom, že učíme lidi opravdu spolupracovat, řešit konflikty společně, bez toho, aniž by jeden druhého zahnali do úzkých. Protože lidi, kteří jsou zahnáni do kouta, jsou defenzivní a místo spolupráce a ‘zeleného‘ chování je u nich vidět bojovnost, předstírání a pomlouvání ostatních. A jestli si myslíte, že se vás to netýká, poslechněte si jeho přednášku. Opravdu stojí za to.

Konference Agile Prague 2015

Jako každý rok je tu konference Agile Prague. Letos už to bude popáté. Můžete se tedy těšit 14.-15.září 2015 na dva dny plné zajímavých přednášek, case-studies, her a workshopů. Když vybíráte vlastní program na konferenci, je těžké říct, co je nejlepší či nejzajímavější. Při představování letošního programu tedy tentokrát pominu hlavní hvězdy, které už možná znáte – o těch najdete více v oficiální sekci o konferenci a soustředím se na ty, kteří vám možná unikli a vyplatí se zajít na jejich přednášku či s nimi strávit čas v rámci přestávek nebo pondělní networking párty – ano, máme přestávky záměrně dlouhé a to hlavně proto, abyste měli příležitost zeptat se speakerů, ale i sebe navzájem na cokoli co vás zajímá.

Ostatně takhle velkou zkušenou Agilní skupinu byste jindy těžko hledali 🙂 a proto letos chystáme i Open Jam session, kde každý může navrhnout téma či se k některému připojit. A v rámci open space formátu diskutovat, ptát se, sdílet zkušenosti. Možná vám to připadá zvláštní, ale ti, co se zúčastnili těchto formátů v minulých letech, hodnotí takovou session jako nejcennější z celé konference.

A teď k doporučením – s kým si dát drink na pondělní networking party.

Senta Jakobsen – chcete-li vědět něco o distribuovaných týmech, rozhodně se přijďte podívat na její přednášku. Ale hlavně popovídejte si s ní během oběda či přestávky. Já jsem při našem posledním setkání na konferenci vyměnila keynote za diskusi s ní u nakonec docela dlouhé snídaně. A to jsem to původně ani v nejmenším neměla v úmyslu.

Bas Vodde – protože zajímavějšího člověka co se scalingu Scrumu týče, byste jen těžko hledali. Takže nevynechte příležitost se s ním seznámit.

Liz Keogh – taky nevíte jak na BDD nebo co to vlastně je? Máte unikátní příležitost to zjistit.

Pawel Brodzinski – je jedním z nejzajímavějších osobností Kanban světa. Je to také leader Lunar Logic, a i kdyby vás zrovna nezajímal Kanban, zeptejte ses ho na to, jak vede tuto firmu. Je to velmi inspirující.

A pro ty, co se rádi vrací k těm, kteří je zaujali – přijede David Hussman, Jurgen Appelo, Andrea Provaglio, Angel Medinilla, či třeba Vasco Duarte.

Ráda vás uvidím na Agile Prague 14.-15.září 2015.

Agile Prague web site
Program Agile Prague 2015
Registrace Agile Prague 2015

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.

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?

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