Retrospektiva – kolečko

Jednou z nejdůležitějších agilních praktik je retrospektiva. Cílem je zapojit tým do rozhodování o procesu, nechat je vyjádřit svůj názor, ale hlavně poslouchat se navzájem a pochopit, že ne každý se dívá na věc stejně. Retrospektivou se učíme a uvědomujeme si, co jsme dělali dobře a co ne. Ideální frekvence je po každém sprintu, aby se problémy zbytečně neprohlubovaly a tým měl pravidelnou a častou možnost zhodnotit, jak sprint probíhal z pohledu každého člena.

Jak retrospektiva vypadá? Možností je několik, ale začneme tou nejjednodušší. Tou je takzvané kolečko kdy všichni členové týmu odpoví na dvě základní otázky:

  • Co se mi líbilo, co co jsme dělali dobře a chtěli bychom v tom pokračovat
  • Co se mi nelíbilo a chtěli bychom to změnit

Nezapomeňte, že retrospektiva je o pocitech, jak jsem to viděl já, co jsem si myslel, jak jsem se cítil. Pocit je osobní, neklade si nároky na to být universální pravdou.

V dobře fungujícím týmu se vám může lehce stát, že nikdo v týmu nemá pocit žádných problémů a že tým subjektivně funguje dobře. Potom se popsaný framework rozšiřuje o další oblast:

  • Co by se mohlo vylepšit nebo zefektivnit

Ideální tým ani proces neexistuje, vždy se dá něco najít, jen je to občas těžké si uvědomit.

Začnete-li s retrospektivou, tým začne přemýšlet o věcech jinak, jednotlivý členové budou mít pocit, že má smysl promluvit a zapojit se. Přestanou být pasivními členy čekajícími na úkoly. A jste zase o krůček blíže k vysněnému ‘self-organized‘ týmu.

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.

Dubnová Agilia

Protože Agilii pořádáme už déle než rok, rozhodla jsem se, že se tentokrát pokusím změnit formát této akce a udělat jí zajímavější a jinou. Dubnová Agilia bude organizována formou ‘Lighting talks‘, tedy krátkých 10min příspěvků jednotlivých účastníků – včetně diskuze. Tématem může být cokoliv, agilní praktiky, zkušenosti, nové metody, doporučení,… . Je to jen na Vás.

Kdy: Středa 14. Dubna v 18:30 / Wednesday April 14th, 6:30pm
Místo: Al Cafetero, Blanická 24, Praha 2.

Program:
1. Michal Aichinger – Od Scrumishe pro maintanence ke Kanbanu/ From Scrumishe for maintanance to Kanban [Seznam]
2. Eduard Kunce – Koucink a agilni metody / Agile and Coaching [CA]
3. Lubos Racansky – Osm sprintů produktového vývoje / 8 Sprints of Product Development [AspectWorks]
4. Igor Kopriva – Od waterfallu ke Scrumu / From Waterfall to Scrum [CA]
5. Rudolf Kutina – Flexible IT in Agile world – Dynamic Data Centers

Přijďte se podívat a zapojte se do diskuze.

Agilní kultura

Jak jsem již psala minule, agile není proces, ale filozofie. A agile také znamená změnu. A to obzvláště pokud uvažujete o jeho zavedení v hierarchicky řízené procesní firmě.
Organizace a firemní kultura, do které se bude agile jen těžko prosazovat:

  • Na vše existuje striktně definovaný proces
  • Hierarchická struktura řízení
  • Předpis je důležitější než dohoda mezi lidmi
  • Individualismus místo spolupráce

Naopak hodnoty definované agilní firemní kulturou budou obsahovat:

  • Spolupráce
  • Důvěra
  • Samoorganizovaný tým (self-oragnized team)
  • Komunikace
  • Sdílení zkušeností a znalostí

Agilní kultura by se dala popsat ještě mnoha výrazy, ale tyhle patří k nejdůležitějším. Zavádíte-li agilní metody, měli byste v první řadě rozumět firemní kultuře a být si vědomi toho, že vhodné kultura změny podpoří, direktivní kultura naopak v podstatě znemožní jejich nasazení.
Co tedy musí být splněno, aby mělo smysl se do zavádění agilních metod pouštět?

  • Věřit v agilní firemní kulturu
  • Přijmout změnu a překonat odpor k ní
  • Věřit v potenciál a schopnosti lidí
  • Být ochoten přijmout riziko
  • Mít TOUHU zkusit agilní metody

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

  1. Přečíst si agilní manifest
  2. Pochopit, že agile není proces, ale filozofie
  3. Jakou máme firemní kulturu a hodnoty?
  4. 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.

Výsledky ankety – Jak začít pracovat Agilně (Agile Adoption Survey) 2009

Před casem jsem publikovala anketu Agile Adoption Survey 2009, a nastal čas pro vyhodnocení. Anketa byla součástí mé disertační práce, takže vyhodnocení je tentokrát v angličtině.

Výsledky jsou publikovány včetně detailní sumarizace doporučení a zkušeností jednotlivých respondentů, takže doufám, že budou pro Vás užitečné.

Podrobnosti se dočtete tady.

Používáte Test Driven Development (TDD)?

Jedním z předběžných výsledků ankety (Dotazník Jak začít pracovat Agilně (Agile Adoption Survey) 2009) který je vidět již v průběhu je, že většina lidí považuje Test Driven development (TDD) za příliš složitý na nasazení, jen čtvrtina lidí ho opravdu používá, ale skoro polovina si myslí, že je to užitečná agilní metoda. Proč tomu tak je?

Zkuste si představit třeba automobil, který by někdo vyráběl stejně, jako je píše software. Prostě by se navrhnul, poskládal dohromady, a někdo s dělníků by na půl oka zkouknul, že to vypadá jako automobil. V lepším případě by motor vypadl až někde cestou, dveře by nešly zevnitř otevřít a nádrž na benzín by byla shodou náhod hermeticky uzavřená. O bezpečnosti jízdy ani nemluvě.

Než takový automobil pustíte na silnici…
picture1

nejdříve připravíte testy, třeba tento:
připravit testy

pak testy spustíte…
sputit testy

a teprve když jsou všechny v pořádku, dáte auto zákazníkovi…
hotový výrobek

Takže proč když to můžeme dělat při výrobě automobilu, neděláme to při výrobě software? Myslím, že je to jen zvyk. U softwaru totiž většinou nic moc nehrozí. To že programy nefungují, už jsme si přeci zvykli.

Ale i tak, Test Driven Development (TDD) rozhodně stojí za zamyšlení. Odhlédneme-li od spokojenosti zákazníka, je tu i spousta interních aspektů. Např. máte-li kód plně automaticky testován, snižujete riziko refactoringu a případné chyby, které způsobíte v jiných částech aplikace, najdete hned a sami. A na tom že každý systém jednou potřebuje třeba jen drobný refactoring se asi shodneme. Myslím, že investice do testů na začátku se Vám vrátí velmi brzy.

Proč to tedy nezkusit… Mimochodem, víte, jak se pozná, že už jste opravdu v Test Driven Developmet světě? Než upravíte nějakou funkcionalitu, nejdříve ‘rozbijete‘ test (tedy upravíte ho podle nových požadavků, a spustíte) a teprve až test neprojde, opravíte funkcionalitu tak, aby všechny testy byly v pořádku. Je to jiné, zdá se to být zvláštní, ale funguje to.

Open space diskuze na WebExpu: Vše, co jste kdy chtěli vědět o agilních metodách…

Ráda bych Vás pozvala na WebExpo 2009, kde pořádáme s Agilním konsorciem open space diskuzi:

Vše, co jste kdy chtěli vědět o agilních metodách*

Přijďte se něco dozvědět o agilních metodách, popovídat si, zapojit se do diskuze.
A máte-li již teď nějaké otázky, stačí je přidat jako komentář pod článek. Rádi odpovíme.

Diskuze se bude konat v sobotu 17. října 2009 od 14:15 v prostorách konání konference WebExpo (viz letáčky na místě). A povídat si s vámi budu já, tedy Zuzi Šochová (CERTICON), Petr Olmer (GoodData) a Andrej Zachar (SimpleWay).

___
* ale báli jste se zeptat

Extreme Scrum přednáška na Agileee

První ročník konference Agile Eastern Europe 2009 v Kievě je za námi. Agileee měla dobrou atmosféru a spoustu velmi zajímavých lidí. Mám-li vybrat top 2 přednášející, určitě by to byli J.B.Rainsberger se svojí přednáškou “An Introduction to Agile Through the Theory of Constraints” a David Hussman s přednáškou “Agile Journeys: How Did We Get Here and Where are We Going?”. Budete-li mít někde možnost si je poslechnout, určitě to stojí za to.

Moje přednáška je ke shlédnutí níže. Pojednává o speciální case study kdy byl použit Scrum v extrámním prostředí kde se projekty počítají na hodiny. Řešením specifické situace bylo nasazení Scrum metody a půldenního sprintu. Výsledky byly velmi pozitivní.

Část case study byla také publikována na konferenci SoMeT, 8th International Conference on Software Methodologies, Tools and Techniques.