Management | Zuzi's Blog o Agilu a Scrumu

Co mi přineslo WebExpo 2010 – část 4

Andrea začal svoji přednášku prohlášením: It’s not a technology which makes a difference. Tedy že technologie Vám k úspěchu nepomůže. Potřebujete něco víc. Leadership.

Zamyslete se nad tím v kolika případech manageri okolo vás používají jen tyto dva základní nástroje: Hůl a mrkev. Všechny bonusy jsou o tomto principu. A funguje to? Jen v krizových situacích. Ale většina firem není 100% času v krizové situaci, nebo by alespoň neměli být. A nic jiného z oblasti řízení lidí a motivace neznají.

Andrea měl výbornou hru kdy nechal účastníky zažít, jak se manageri většinou chovají, a jaké to má následky. Co se stane, když je někdo ze systému náhle odebrán, a teď se všichni tváří, že ten člověk nikdy ani neexistoval (Týna v tomto případě z ničeho nic odjela do Dánska a nový manager přišel a nikdo nevěděl proč). Myslím, že se to musí zažít. Dobré na tom je to, že i když nový leader je slabý a vlastně ani leaderem není, systém si najde neformálního leadera a vše funguje dál. Jen ne tak dobře. I pro nového leadera navázat na existenci předchozího leadera a třeba i věci změnit, než se tvářit že ten před ním nikdy neexistoval. Dejte si fotku týmu na nástěnku ke kávovaru a až se někdo zeptá kdo to je, je snadné odpovědět to je Týna, Týna je teď v Dánsku ale předtím to byla naše managerka. Konzistence týmu není narušena. A vše funguje dál.

Na závěr ještě vzpomenu Andreovu radu, že nemůžete úspěšně nasadit Scrum ve firmě kde chybí leadership. Všechnoživé je vždy samoorganizující se. Jen se to často organizuje jinak, než bychom to rádi viděli. Co je tedy největším problémem obecně? “Overusing technical mind“…

Pozvánka na WebExpo 2010

Ráda bych Vám doporučila Agilní sekci na letošním WebExpu, kterou po programové stránce organizuji. Jedná se o v českých podmínkách unikátní akci, kterou by si neměl nechat ujít nikdo, kdo se o agilní metody zajímá.

Konference WebExpo 2010 v září

Třetí ročník konference WebExpo přináší novou sekci zaměřenou na agilní metody. V posledních několika letech výhody agilního přístupu oceňuje čím dál více firem a začínají být často používané i v českých společnostech. Agilní metody se zaměřují na týmovou spolupráci, zavádí efektivní procesy a posilují kvalitu produktu. Agilní sekce WebExpa je vyjímečnou příležitostí dozvědět se více o agilních metodách a vytváří unikátní platformu pro sdílení zkušeností z firem, které agilní metody úspěšně používají, s agilními metodami začínají, či o agilních procesech teprve uvažují.

Během dvou dnů přednášek promluví deset zahraničních odborníků z praxe, přednášky budou zaměřeny jak pro začátečníky tak i pro pokročilé, budou zaměřené na konkrétní agilní praktiky používané vývojáři, testery a teamleadery, ale zhodnotí i význam agilních metod pro managery firem. Program doplňují i dvě panelové diskuze, které jsou výbornou příležitostí konfrontovat vaše zkušenosti s odborníky z českých i zahraničních společností.

Čtvrtek je tradičně vyhražen praktickým půldenním workshopům, kde si můžete vyzkoušet Theory of Constraints spolu s Pierluigi Pugliese, který tento workshop povede. Pierluigi začínal jako programátor v telco sektoru, postupně přešel do role teamleadera a dnes se primárně věnuje konzultacím v různých firmách, kde pomáhá se zaváděním agilních metod. Pierluigi je původem z Itálie a dnes žije v Německu. Kromě již zmíněného workshopu bude mít i přednášku na téma Soft Skill Essentials for Software Craftsmen.

Dalším z pozvaných speakerů je charismatický David Hussman z Minnaepolis, USA, který agilní sekci konference v pátek zahajuje. David je jeden z nejlepších odborníků na agilní metody, organizuje lokální agilní komunitu v USA, pomáhá různým firmám v nasazování efektivních agilních procesů. S důrazem na pochopení aktuální situace daného projektu se vyhýbá obecným a universálním řešením, která jsou často doporučována. David pracuje v těsné spolupráci se softwarovými týmy, vývojáři, teatery i teamleadery. Jeho přednáška Products and People over Process and Dogma je ideálním tématem k zamyšlení nad smyslem agilních metod. Jak David říká v úvodu přednášky – čím dál tím více lidí tráví čas diskuzemi o tom, co to znamená agilní, místo toho aby jednoduše začaly agilní praktiky používat.

Další z přednášek je o tom, jak správně dělat retrospektivu. Jestli se rozhodnete s agilními metodami v praxi začít, retrospektiva by měla být první metodou, kterou do svého týmu zavedete. O problémech retrospektivy bude mluvit belgičan Yves Hanoulle, který je zkušeným agile coachem a jeho přednáška How to make your retrospectives the heart of your agile proces by Vám rozhodně neměla uniknout.

Mezi dalšími pozvanými odborníky je v německu žijící Boris Gloger, kerý kromě plánovaného workshopu bude mluvit v přednášce Scrum for Executives – Six Secrets for Success with Scrum o tom, jak používat Scrum v různých prostředích. Ital Andrea Provaglio se ve své přednášce Beyond Agile podělí o zkušenosti se zaváděním Scrumu. Nenechte si ujít ukázku, jak prodávat agile, kterou bude prezentovat Američan žijící v Polsku Paul Klipp ve své přednášce Selling Agile. O své zkušenosti z praxe se s vámi podělí i Maria Diaconu a Alex Bolboaca z Rumunska v přednášce Software Development = Learning.

Z českých speakerů představí Tomáš Pergler praktickou studii z firmy Seznam.cz, kde se podělí o zkušenosti Seznamu se Scrumem – A Year with Scrum in Seznam.cz. Dalším z českých speakerů je Luboš Král, který se v přednášce Agile acceptance and implementation by East and Western mindsets zaměří na otázky spojené s nasazováním agilních metod v multikulturním prostředí, jak převzaté techniky fungují v české kultuře, co se osvědčilo a co je naopak nutné změnit. Na ukázkách z praxe poukáže na hlavní rozdíly mezi agilními přístupy a klasickými metodami.

Konferenci doplňují dvě panelové diskuze, kde první je zaměřená na Agile z pohledu managementu. Podíváme-li se na největší překážky v zavádění agilních metod, nepochopení managementu bude jednou z nejčastějších příčin jejich neúspěšného nasazení. Pojďme se tedy společně s managery předních českých firem podívat na agilní metody z pohledu jejich managemetu. Diskutovat budou Zuzana Šochová (Managing Director, Lotofidea), Vlastimil Pečínka (R&D Director, Seznam.cz), Jan Bezdíček (Director, Rockwell Automation), Pavel Šuk (Vice President, Kerio Technologies), Martin Rýzl (Software Engineering Manager, Sun Microsystems).

Budete-li mít i po všech vyslechnutých přednáškách nějaké dotazy, panelová diskuze Everything you’ve ever wanted to know about agile methods je ideálním místem pro jejich zodpovězení. Všichni přednášející agilní sekce Vám budou plně k dispozici. Takže přijďte a zeptejte se na vše, co jste kdy chtěli vědět o agilních metodách.

Konference WebExpo se koná již tradičně na půdě ČZU v Praze, tentokrát již 23-25.9. Více informací se dočtete na každý den aktualizovaných stránkách WebExpa.

Posílení týmu – ‘self-organized‘ tým

Jedním z často skloňovaných výrazů je ‘self-organized‘ tým. Týmy přecházející na agilní metody často začínají ranním Scrum meetingem, jako první zaváděnou praktikou. Jistě pomůže při sdílení informací a posílí týmovou spolupráci, ale nedá sám o sobě jednotlivým lidem pocit, že i na jejich názoru záleží, a že je tedy jen na nich, jak si vše zorganizují. K tomu, aby tým byl opravdu zapojen do procesů, je třeba dát všem prostor se k procesu vyjádřit a ovlivnit ho. Proto je důležité dělat retrospektivu. Dalo by se říci, že vlastně nemusíte ani vymýšlet žádný do detailu zpracovaný proces, stačí začít s retrospektivami a proces odpovídající vašemu prostředí vznikne za pomoci lidí v týmu sám. A jako všechno to, kde se sami podílíte na rozhodnutí, je i takto vzniklý proces stabilnější, robustnější a efektivnější.

Retrospektiva vás donutí zastavit se a podívat se co jste dělali dobře, a co špatně. A tedy dává prostor ke zlepšení, vytváří podmínky ke změnám, a posiluje proces učení se z toho, co se stalo. Měla by proto probíhat pravidelně, po každém Sprintu. Každý by měl dostat prostor vyjádřit své pocity, jak to vnímal on sám, co se mu líbilo a co by naopak změnil či vylepšil. Nastaví se tak týmu zrcadlo, kde je najednou vidět, co funguje dobře a co ne. A aby jako takové zrcadlo fungovalo, musí mít jednotliví členové stejnou možnost svoje pocity prezentovat. Aniž by je někdo hned opravoval, že nemají pravdu a že s nimi nesouhlasí. Jsou to přeci pocity konkrétního člověka, ne univerzální pravda. A vnímat věci jinak má každý právo.

Aby byla retrospektiva funkční, musí vždy, bez vyjímky, na identifikované problémy následovat akce, která se pokusí problém minimalizovat či odstranit. Řešením může být jak změna identifikovaného procesu, tak i vysvětlení proč takový je. Na spoustu problémů může tým již během retrospektivy pomocí brainstormingu navrhnout řešení, na složitější problémy si můžete vzít čas na rozmyšlenou. Ale něco by se mělo stát a při příští retrospektivě by se mělo vyhodnotit, jestli akce pomohla, či ne. Čím více zapojíte tým do navrhování řešení, tím rychleji se problémy spraví. Tým ví obvykle nejlépe sám, co mu chybí, co je dobré, a co ne.

Co je to agile?

Agilní metody vyžadují nejen aktivní zapojení jednotlivých členů týmu, ale i pochopení těch co agile zavádějí, že agile není jen soubor praktik ale celková filosofie. Jednotlivé praktiky se vzájemně podporují a jen jejich kombinací vznikne synergický efekt.

Jak vůbec poznáme, že náš proces je agilní? Nebo spíš jak poznáme, že není?

Používáte Agile?

Zákazník (co by nemělo nastat externě):

Se zákazníkem komunikuje jen vybraný člen týmu (obvykle project manager, account manager)
Zákazníkovi se prezentuje až hotový produkt
Smlouvou definované požadavky se nemění
Zákazník je nespokojený s výsledkem, či odmítne převzít výsledek

Tým (co by nemělo nastat interně):

Denní status meeting je ztráta času
Věříme, že homeoffice je efektivnější než práce v týmu
Každý člen týmu je zodpovědný za samostatný celek
Co jsme jednou naplánovali, to neměníme
Integrace pouze velkých celků
Psaní automatických testů je ztráta času
Architekt jen navrhuje, ale nekóduje
Testování je separátní aktivita
Nepřesné odhady
Direktivní přidělování úloh
Review je zbytečná formalita

Většina firem, co o agile ví, pravděpodobně některé metody zavedla, ale už se příliš nezabývala pochopením agile jako celku, která se vzájemně podporuje. Co se používá nejčastější? Pravděpodobně to bude Scrum (daily stand-up) meeting, který je jednoduchý na pochopení a za málo energie přináší snadno efekt – tedy komunikace a informovanost v rámci týmu se zlepší. Na druhé straně spektra jsou pravděpodobně odhady v bodech, které jsou relativně těžké na pochopení a proto je většina firem ani nezkusí zavést.

Čím bychom tedy měli začít, abychom byli opravdu agilní?

Přečíst si agilní manifest
Pochopit, že agile není proces, ale filozofie
Jakou máme firemní kulturu a hodnoty?
Akceptovat, že agile přinese jinou firemní kultury

Agile je změna, a jako jakákoliv jiná změna musí být v organizaci či její části dostatek energie a chuti změnu vysvětlit, prosadit a udržet.

Vedou agilní metody ke coachingu?

Agilní metody už jsem si vyzkoušela na všech možných projektech, některé zákazníky jsme scrum naučili a oni ho přijali za svojí metodu vývoje. Takže co dál? Proč je vlastně scrum proces tak úspěšný? Rozhodně to není zavedením agilních praktik samo o sobě. Párové programování, Backlog a Burndown vám možná pomůžou ale ta zásadní změna se děje na úrovni firemní kultury. Mění celé prostředí a vnímání reality zaměstnanci. Ti se stávají více zapojeni do procesu a zainteresováni na výsledku. Má to něco společného s motivací ale je to možná více o převzetí zodpovědnosti a zároveň osobním rozvoji. Můžete stokrát používat všechny agilní metody, ale když nemáte agilní kulturu, efekt bude přinejmenším sporný.

Jak tedy agilní kultura vypadá? Tak určitě vyžaduje zapojení lidí do procesu, iniciativu, tedy vysokou motivaci. Dalo by se říci, že na stupnici podle Maslowa budou lidé hodně vysoko, až v posledním stupni pyramidy, kde klíčovou hodnotou je realizování osobního potenciálu, naplnění a osobního rozvoje. Mezi důležité vlastnosti bude patřit samostatnost, odpovědnost, ale i sebevědomí. Přechod od direktivní kultury je jistě náročný, ale nikoliv nemožný. Když jsem přemýšlela jak naší firemní kulturu, která by rozhodně mohla být považována za agilní, ještě posílit, napadlo mě, že vlastně ideálním nástrojem bude coaching.

Coaching je vlastně o zvyšování úrovně vědomí. Mělo by nás vhodně kladenými otázkami donutit zamyslet se nad danou věcí a už jen tím že se na danou oblast soustředíme, dokážeme často problém odstranit. Krásně je to vidět ve sportu. Absolvovala jsem nedávno coachovací hodinu tenisu a musím říci, že to skvěle funguje. Rozhovor typu: “Jak se ti hraje? No bolí mě trochu ruka, mám pocit, že se nemůžu pořádně napřáhnout. A kde přesně tě bolí? No v zápěstí, takhle… A co by šlo udělat, aby se to zlepšilo? Šla by třeba chytit jinak raketa? Možná takhle… Je to lepší? Jo…. “ výborně fungoval. Zkuste si ho porovnat s klasickou výukou kde je trenér v roli člověka, co neustále opravuje chyby a říká vám, že raketu držíte špatně, že se musíte dívat na míč a dávat rychlé rány. Asi bych skončila s tím, že k tenisu nemám vlohy.

Takže zpět k otázce jak posílit agilní kulturu? Proč tedy nezkusit coaching. Dobrým začátkem by tedy mohl být model GROW (Goal, Reality, Options, What/When/Who/Will), tedy identifikace cílů a to jak krátkodobých tak dlouhodobých, popis aktuálního vnímání reality, brainstorming možností co s tím dělat a na závěr plán co se má kdy a kdo udělat a jaká je vůle to dokončit.

To zní jako dobrý plán, o jeho realizaci ale zase příště.

Waterfall, RUP nebo Agile?

Začínáte projekt a nevíte kterou metodu zvolit? Zkusím se podívat na jednotlivé metody detailněji. Tradiční Waterfall vypadá ideálně. Nejprve si navrhnete, co budete dělat, pak řeknete jak, pak to uděláte, otestujete. Ideální. Snadné. Jen bohužel realita je vždy jiná. Výsledek ukážete zákazníkovi, a on se zatváří zklamaně, řekne, že tohle si nepředstavoval, či že tohle nikdy nechtěl a ať to předěláte. Vás pak na jedné straně čeká dlouhý refactoring a předělávání, a k tomu zákazník, který je nervózní že aplikaci stále nemá. Na druhé straně jsou dlouhé diskuze se zákazníkem, že v jeho původních požadavcích to bylo jinak či nebylo vůbec. A že tento refactoring musí zaplatit extra. Nic neobvyklého, a nic co by se jen blížilo spokojenosti na obou stranách.

Proto vznikl Rational Unified Process (RUP), který si uvědomuje, že není možné celou aplikaci napsat v jednom sekvenčním procesu – ostatně stejně se tak nikdy v reálu nedělo – a že jednotlivé fáze jsou více či méně přítomny periodicky v průběhu celého procesu. RUP se dá v podstatě považovat za pokus přiblížit Waterfall reálnému světu. Pokus to byl dobrý, nicméně spokojenosti zákazníka moc nepřispěl. Návrh vede často k velice komplexní a náročné architektuře, která ztěžuje případný refactoring. Navíc jednotlivé fáze jsou extrémně detailně specifikované, tedy libovolné změna vyžaduje i dlouhý čas na přepsání všech modelů a diagramů.

Asi nikoho nepřekvapí, že budu na tomto místě doporučovat agilní metody. Na rozdíl od předchozí metody, která vsadila na dobrý návrh, jsou agilní metody orientovány na změnu. Návrh by měl být co nejjednodušší, iterace dostatečně krátké, aby se omezilo riziko refactoringu. Navíc zákazník, který vidí každé dva týdny jednu feature a může se k ní přímo vyjádřit, je potom v daleko horší situaci když na konci projektu chce něco jinak. Agilní metody omezují návrh a dokumentaci na nutné minimum, nicméně na druhé straně zapojují testování hned na začátek návrhu (TDD), zavádí automatické testování a kontinuální integraci. Agilní metody jsou navíc založené na spolupráci, a to jak v rámci týmu tak i externě se zákazníkem, což je činí o dost efektivnější.

Na závěr přidávám krátkou tabulku s porovnáním jednotlivých metod:

	Waterfall	RUP	Agile
	Sekvenční	Inkrementální	Iterativní
	Jasně definované requirementy.	Počítá s mírnou změnou requirementů.	Requirementy se konzultují se zákazníkem v průběhu.
	Specifikace se nemění	Specifikace se nemění v rámci inkrementu.	Specifikace se nemění v rámci sprintu.
	Jednotlivé fáze (analýza, design, testování, …) jsou oddělené a sekvenční.	Jednotlivé fáze (analýza, design, testování, …) jsou oddělené, ale běží paralelně.	Nerozděluje projekt na jednotlivé fáze. Každá úloha obsahuje všechny fáze (analýza, design, testování, …).
	Striktně definovaný proces, který nepočítá s žádnou změnou.	Složitý, use-case driven, architecture-centric proces.	Metodologie založená na rychlé reakci na změnu a spolupráci (interní i externí).
	Jednotlivé fáze jsou zdokumentované	Snaha mít vše do detailu zdokumentované.	Dokumentace jen v nejnutnější míře, jednoduchý designe, hlavní metrikou je spokojenost zákazníka.
R I Z I K A	· Nespokojenost zákazníka (něco jiného než chtěl) · Dlouhý refactoring · Nepřesné odhady	· Příliš složitá a náročná architektura · Dlouhý refactoring · Nepřesné odhady	· Náročný na komunikaci a kooperaci · Musí odpovídat firemní kultuře
P O U Ž I T Í	Jasně definovaný a dobře specifikovaný projekt kdy změna je vysoce nepravděpodobná. Zákazník musí perfektně vědět, co chce dopředu. Náročný na zkušenosti jednotlivých engineerů.	Komplexní systémy vyžadující detailní dokumentaci a náročnou architekturu. Změna požadavků je nepravděpodobná. Náročný na zkušenosti jednotlivých engineerů.	Projekt pro běžné zákazníky co často úplně přesně nevědí, co chtějí. Požadavky se mohou měnit v rámci projektu. Cílem je spokojený zákazník. Střední nároky na zkušenosti týmu.

Dva druhy lidí…

Z pohledu managementu jsou jen dva druhy lidí. Jeden, který by se dal charakterizovat slovy ‘co neměřím, to neřídím‘, a pak ti, co se více než na nějaké striktní procesy a čísla spoléhají na svojí intuici a selský rozum. Skupiny jsou to zcela disjunktní, a přesto že spolu mluví, jen velmi těžko si opravdu rozumí. Žijí v odlišném světě. Někde tady se podle mého soudu nachází základní problém zavádění agilních metod řízení.

Např. Scrum je založený na týmové spolupráci, týmové zodpovědnosti, a týmovém rozhodování. Zkuste tedy vysvětlit klasickému managerovi ze staré školy, že zodpovědnost za projekt má tým. On přeci musí mít jednoho člověka. Tomu odpovědnost naloží a ostatní ignoruje. Další obtíž nastane, když se tým rozhodne něco změnit. Vše přeci musí být popsáno procesy a ty se nejenže nemění, ale musí se i dodržovat… Po čase skončíte tak, že děláte (Agilní) interface dovnitř týmu a (klasický procesní) interface svému managerovi. A to samozřejmě bude funkční jen z poloviny. Agilní kultura se tak nevytvoří. A je otázka, jestli to pak celé nebude na úrovni isolovaných praktik, jako když např. místo komplexního systému testování zavedete unit testy. To je sice samo o sobě super, produkt bude trochu lépe otestovaný, ale asi to nezaručí tu pravou kvalitu.

Jak tedy přesvědčit managery co nikdy nic jiného nezažili, že Agilní metody mohou fungovat dříve, než vás utlučou svými formálními performance measurementy? A jde to vůbec? Nebo takové metody a kultura funguje jen ve firmách s opravdovými leadery, co upřednostňují dlouhodobý cíl před krátkodobým ziskem? Na závěr, k těm procesům, si neodpustím otázku. Máte ve firmě ISO? A pomáhá vám nějak v tom být lepší, kvalitnější a úspěšnější?

Paradoxně mám pocit, že se všude mluví o tom, jak přesvědčit zákazníka. Pro většinu firem ale musí být daleko těžší přesvědčit svoje vlastní lidi. Myslím, že přesvědčit zákazníka je o mnoho snazší, než si získat podporu formalistů a striktně procesně založených lidí.

Zajímal by mě Váš názor a zkušenosti. Takže prosím o diskuzi, ať už tady veřejně, nebo emailem.

Zavádíme Agilní metody agilně

Jistě jste si už mnohokrát zkusili zavádět v praxi nějaké novinky. Obvyklý postup je začít prezentací, ukázat o čem nový způsob práce je, co jsou jeho výhody, jaká jsou očekávání. Začnete-li takto ‘po staru‘ prezentovat Agilní metody, pravděpodobně se dočkáte spousty připomínek, že metody jsou moc americké, ve vašem případě z nejrůznějších důvodů nevhodné, přinesou spousty overheadu a sníží efektivitu. Proto se mě osvědčilo zavádět Agilní metody ‘agilně‘, tedy po částech a takříkajíc plíživě.

Základ je nikomu v týmu neříkat, že od teď nastane změna a bude se pracovat jinak. Lidé obecně změnu nemají rádi. Naopak. Vše je při starém, jen zavedeme každý den krátký meeting. Začneme neformálně, nějakou historkou, statusem projektu (stejně si všichni stěžují, že chtějí vědět co se děje) a postupně se začneme ptát jednotlivých lidí na to, co dělali včera a budou dělat dnes… zní to povědomě? Asi ano. A máme Scrum či Stand-up meeting tak jak má být. Tým si pozvolna zvykne, a ani mu to nepřijde. Vcelku snadný začátek.

K tomu aby se opravdu začalo plánovat v bodech sice nějaké vysvětlování potřebujete, ale když už umíte pěkně Scrum meetingy, znáte status jednotlivých úloh a i to jak vám jdou od ruky, máte pro to informace, co potřebujete. Mě se osvědčilo koncept seznamu úloh (nemusíte mu hned říkat backlog) vysvětlit, vysvětlit že ohodnocení odpovídá náročnosti a že ho budeme dělat v bodech. Pak už stačí nechat odhadovat úlohy jednotlivé členy týmu, klidně v hodinách, ale toto ohodnocení hned převádět na body. Složitější celky odhadnete sami. Po čase, kdy budete body vysvětlovat na konkrétních úlohách lidé koncept vstřebají a budou ho umět sami používat.

Dalším krokem je vytvořit plán na nějaké iterace (sprinty), ze začátku ho uděláte vy, později jeho vytváření delegujete na tým. A rovnou jim můžete dát burndown na nástěnku. Když budete mít týmů víc a podpoříte soutěživost, o pozornost máte postaráno. Někde během tohoto procesu zavedete prezentace zákazníkovi (customer demo) a začnete se ho ptát na zpětnou vazbu a priority. A to už máme v podstatě celý Scrum proces, aniž by o tom někdo věděl. A když už vám to tak pěkně funguje, můžete metody pojmenovat a dopilovat jejich formu.

Hledáte-li rady jak začít s Agilními metodami, většinou začínají komplexní teorií, kterou stejně tým bez vyzkoušení nepochopí a hlavně všemi metodami najednou (neboť jinak by to přeci nebylo dost agilní, to by nebyl ten pravý Scrum proces). Výše zmíněný postup je jen alternativou, která vám umožní dělat změnu procesu, aniž by to bylo vnímáno jako změna procesu. Jsou to jen takové drobné novinky, takové malé vrtochy našeho projekt managera, to přejde, chvíli budeme chodit na meetingy a on se třeba unaví…

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

Příběh MBA

Nastal čas zase zhodnotit, co vše Vám může přinést MBA program. Business knowhow, kontakty, titul… Ale také i zajímavý pohled na změnu. Na to jak dělat prezentaci, jak přednášet. A jak ne. Doposud byli všichni lektoři ze Sheffield Hallam nudní patroni přednášející suchou teorii. SWOT, PESEL, Porter desetkrát jinak. Teoretické frameworky, jejichž použití v praxi bylo diskutabilní. Nemám jim to za zlé. Přecijen jsme na akademické půdě. Některé přinesly nové nápady a pohledy na věc, některé neuchopitelné, jiné jasné. Po roce a půl musím zhodnotit formu assignmentů jako velmi vhodnou. Critically evaluate… Nutí totiž tyto teoretické frameworky použít v praxi a zamyslet se nad jejich smyslem, což je často přínosné. Čeští lektoři naopak přináší osobní zkušenosti z praxe, takže vše tvoří konzistentní celek.

Poslední modul byl jiný. Také hýřil teorií, ale taknějak lidštěji. Donutilo mě to zamyslet se nad tím, jak se dá přednášet a co můžete lidem dát, když změníte formu prezentace. A jak moc velký je rozdíl, když čtete a neprezentujete. Představte si dvě prezentace. Jednu, kde lektorka čte (a jako Angličanka umí číst velmi rychle i v angličtině). Bez ohledu na obsah, je to zcela k ničemu. Přestanete vnímat po pár větách. Nejde to zastavit, rozlišit myšlenky, je to nekončící monotónní proud slov. Na druhé straně přednášky, kvůli kterým toto píšu. John Darwin z Sheffield Hallam University. Vynikající řečník. Začne videem o tučňácích. Příběhem, ve kterém je v pár minutách vše co potřebujete vědět o změně. Jak na ní. Co nevynechat a na co se zaměřit. Vše ve formě příběhu. Nedá se zapomenout. Zůstává někde v paměti. Doporučuji. Jmenuje se to Our Iceberg Is Melting. Je v něm vše. Vše co je třeba znát. Někdy uprostřed, kdy už jsou všichni unavení, začínal přednášku spotem Columbia Business School. How to manage… Just for fun…

Udělat z pohledu informací zajímavou přednášku, plnou teorie a dat je snažší. Ne lehké. Musíte tomu rozumět, mít dostatek znalostí. Ale udělat přednášku tak že vám informace uvíznou v paměti jen tak mimoděk, aniž byste zaznamenali, že se učíte teorii, to není jen tak. Vyprávět příběh či pohádku vyžaduje možná více invence a kreativity. A odvahy. Ale výsledek je řádově lepší. Nevím, jestli je možné každou přednášku proložit videem, vtipem, hudbou. Ale rozhodně se o to příště pokusím.

Jestli se také rádi učíte z příkladů, teorie vás nudí, připadá vám neuchopitelná a máte radši příběhy, zkusím doporučit dvě knihy, co jsem v poslední době četla. Jedna pojednává o změně tradičního pohledu na řízení fabriky. Ředitel co musí změnit styl myšlení a řízení výroby dřív, než mu fabriku zavřou. Vše se mu hroutí a on neví kam dál. Eliyahu M. Goldratt – The Goal. Vynikající kniha. Příběh co říká vše a je samozřejmě v obecné rovině přenositelný na jakoukoliv oblast.

Druhým objevem je FISH! Vypráví příběh jak změnit ”toxic energy dump” na místo, kde každý rád pracuje. Vychází z úspěšného modelu rybího trhu v Seattlu. Příběh, který musíte prožít, abyste pochopili hlavní principy FISH! Philosophy – Play, Choose Your Attitude, Make Their Day, Be There. Vše je na Vás, a je jen Vaše rozhodnutí, jak se k tomu postavíte.