Category Archives: Agile

Agilný projekt = Tehly a piesok

Posted on by

Produkty sú pri klasickom projektovom riadení pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov. A aj vrátane “bezpečnostnej vaty 10-15%”. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená “čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no agilný projekt je  realizovaný odlišným spôsobom:

  • Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
  • Plán vždy obsahuje veľké požiadavky, tzv. eposy (v anglickej literatúre sa používa slovo epics). Produktového vlastníka zaujímajú práve eposy vytvárané na základe vízie produktu. Príklad: Správa zákazníkov, Správa produktov, Prehľady.
  • Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Nie pre celý plán, len pre niekoľko iterácií! Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením eposu. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Agilný plán by mal obsahovať  “tehly aj piesok”. Eposy (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily.

Produktový vlastník tak má čas pripravovať eposy dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

Toto je základ dobrého agilného projektového plánu. Ako ale určíme, ktoré eposy potrebujeme skonkretizovať na stories a kedy?

O vlastnosti, ktorú nikto nepotrebuje

Posted on by

Produkovať a pridávať vlastnosti nie je len slovenské…

Produkty boli dlho tvorené s dôrazom na pridávanie novej funkčnosti tak, aby spoločnosť poskytla užívateľom v nových verziách viac a viac. Tento prístup trval pomerne dlho, no začiatkom 21. storočia sa situácia mení.

Používatelia si najviac vážia čas. Potrebujú jednoduché aplikácie, ktoré poskytujú funkčnosť priamo pod prst. Kontextovo. A s príchodom mobilných zariadení sa takýmto aplikáciám darí viac a viac. Doba, kedy panel nástrojov v aplikácii bol prepchaný je dávno preč. Dnes sú v móde veľké ikony, dobrý dizajn aplikácie a hlavne prehľadnosť.

Mimochodom, skúste odpovedať na otázku:

Predstavte si aplikáciu, ktorú používate denne.

Koľko percent vlastností v nej obsiahnutej NEpoužívate?

Odpoveď na túto otázku sa snažil pred niekoľkými rokmi nájsť Scott Ambler zo spoločnosti IBM.

A výsledok? Veľmi pravdepodobne taký ako ste odpovedali aj Vy sami. Tak ako väčšina ľudí na našich školeniach.

Tento výsledok je mrazivý ak si uvedomíte čo všetko vývoj nepoužívaných vlastností znamená. Koľko ľudskej energie sa v podstate vyhodí von oknom. Resp. uloží na disk :).

V tomto obrázku je skrytá odpoveď na komentáre k predchádzajúcim článkom série prečo treba papierik s požiadavkou roztrhať.

Pretože práve v tých 80% vlastností, ktoré nie sú používané, sa skrýva úspora času, úsilia ľudí a samozrejme peňazí.

Tento princíp je známy aj pod anglickou skratkou YAGNI – (you ain’t gonna need it). Nebudete to potrebovať.

Otázkou je ale KTO určí vlastnosti z množiny 20%? A tu nastupuje do procesu vývoja Zákazník. Zákazník, ktorý vie prečo vlastnosť potrebuje, kedy ju potrebuje a vie, nakoľko si vlastnosť cení.

Pretože hodnota vlastnosti je v Agile hlavným atribútom pre určenie priority, poradia:

  • Pretože najviac cenené vlastnosti dodané na trh skôr ako konkurencia znamenajú pre spoločnosť návrat investícií a skorý zisk.
  • Pretože v tom tkvie umenie produktového vlastníka, ktorý zákazníkovi pomôže určiť hodnoty a priority. Pomôže formulovať požiadavky pre vývojový tím.

Pred pár dňami som sa zúčastnil StartUp Campu v Košiciach. Pre mňa najzaujímavejšie zistenie bolo, ako málo sa slovenské spoločnosti a startupy venujú tomu, pre koho tvoria aplikácie, čo je potenciálnym trhom a čo ten trh skutočne chce. Naopak, venujú sa technológiám a nadšene rozprávajú o HTML5, serveroch, službách.

Nevieme kto bude aplikáciu používať, no chceme robiť radšej marketing pre podporu predaja. Hmmm, predaj, ale KOMU?

Tvoríme produkt agilne

Posted on by

Softvérové produkty tvoríme mnohokrát ako domy. No dá sa to aj inak a lepšie.

Článok bol publikovaný na Zajtra.sk

Story je v Scrume základným prvkom popisujúcim požiadavky. Je to jednoduchý a zrozumiteľný popis o tom kto, čo a prečo danú vlastnosť potrebuje.

Ako ale popísať komplexný systém v takejto jednoduchej forme? Práve táto otázka je často kladená pri prechode na agilný vývoj.

Stavba

Ako staviate dom? Najprv základy, potom prízemie, prvé spochodie, ďalšie poschodia no a nakoniec strecha? Výsledok, teda dom, je odovzdaný ako celok. Až potom ho zákazník začne používať.

Softvérové produkty budujeme často podobne. Po vrstvách. Najprv datábaza.
Potom (celý) dátový model, ktorým presne zmapujeme požiadavky klienta. Potom pridáme vrstvu s obchodným modelom. Potom vrstvu webových služieb no a nakoniec užívateľské rozhranie.

Výsledok je, rovnako ako dom, použiteľný až na konci. Dôsledkom je, že
vznikajú tímy orientované podľa odbornosti. Tímy databázových špecialistov, web dizajnérov, vývojárov služieb a podobne.

Vertikálne?

Softvér sa však dá vytvoriť aj vertikálne. Skúsme vytvoriť iba jednu vlastnosť. Implementujme iba časť databázy popisujúcej danú vlastnosť, potom časť obchodnej logiky, pridajme metódy do webovej služby a sprístupnime užívateľské rozhranie. Vytvorme funkčný blok. Všetko iba pre jednu vlastnosť. Tú dodajme klientovi. Zákazník ju hneď môže začať používať a poskytnúť nám spätnú väzbu.

Až potom pokračujme ďalšou vlastnosťou. Akokeby náš dom bol zostavený z väčších komponent, napr. izieb, ktoré k sebe už iba primontujeme.

Inkrementálne a iteratívne

Takýto inkrementálny vývoj sa dá ešte zlepšiť iteratívnym vývojom. Iteratívny vývoj zdokonalí detaily. Farba na stenách bude v prvej verzii iba biela. Až potom sa rozhodneme pre detaily a pridáme ich. Podobne ako pracuje maliar. Najprv obrys, potom farby, tiene až nakoniec.

Increment vs iterative

Ako nato v softvérovom vývoji? Najprv vytvorte jednoduchý formulár pre zber údajov. No aj s databázovou časťou a webovou službou. Funkčné zadávanie údajov, nielen jednu vrstvu aplikácie. A používateľ môže zadávať údaje bez ohľadu na krásu formulára.

Potom pridajte kontroly. Prispôsobte poradie prvkov lepšej editácii. Zmeňte vzhľad, aby oslovil klienta.

No v tomto momente je to pre klienta už možno zbytočné. Klient totiž potreboval upraviť, zadať, údaje. A to dostal už dávno. Spýtajte sa ho teda ešte predtým, či to skutočne potrebuje.

Záver

Vždy keď píšete novú story na kartičku, vždy si všimnite či na kartičke nie je napísaný technický termín (databáza, webservice, business model a pod.). Ak áno,potom je táto story podozrivá. Pretože pravdepodobne popisuje horizontálnu stavbu domu. Klienta nezaujíma, že ste pridali tabuľku do databázy, ale nemôže ju použiť. Aká je teda hodnota takto implementovanej
vlastnosti?

0

Zamyslite sa teda už na začiatku, pri písaní kartičiek, na výsledok, ktorý je použiteľný. Prinesie vám veľmi skorú spätnú väzbu ešte v čase, keď kód je ešte v hlavách tímu. V čase keď sa dá jednoducho opraviť.

Úlohy alebo aj niečo viac?

Posted on by

Projektový manažment je o ľuďoch, peniazoch a produkte. Tieto tri časti reprezentujú úlohy. Sú ale úlohy postačujúce?

Náš život je riadený úlohami

Aj vy to tak pociťujete? Taká úloha je často definovaná ako odpoveď na otázky:

  • Čo?
  • Kto?
  • Ako?
  • Ako dlho?

Projekty sú tak tvorené množstvom úloh, ktoré navyše navzájom komplikovane súvisia. Navyše úlohy sú vytvárané v projekte veľmi skoro, už počas tvorby projektového plánu kedy nie je celkom jasné čím daný projekt je, kto ho bude riešiť a aký je rozpočet. Skoro nič nie je isté. Poznáte to aj Vy?

Vo firmách, ktoré sú riadené iba úlohami často postrehnete určitý vzor chovania.

Ľudia si ráno typicky otvoria ďalšiu úlohu (v nejakom elektronickom systéme) a keď je dokončia, tak (v lepšom prípade) ju uzavrú a otvoria si ďalšiu. Pracovný život sa tak časom zmení na cyklus OTVOR-VYRIEŠ-UKONČI. Tím zrazu po nejakej dobe nevie odpovedať na otázku PREČO?. Stráca sa tak poznanie produktu, zákazníka a jeho potrieb. Stráca sa tak chápanie prvotných príčin prečo je vlastnosť potrebná, chápanie kontextu riešeného problému. A tieto straty mňa, produktového manažéra, by mali trápiť. Veľmi. Priam bolieť. Tím dokonca nerozumie pre koho vyvíja a ako je to dôležité pre vašu firmu. Ako to zmeniť?

Stories

Prepáčte, že použijem anglický termín, ale zatiaľ som dobrý preklad do slovenčiny nenašiel. ‘Príbeh’ mi v tomto prípade znie čudne.

Story je požiadavka. No, nie tak celkom, ale v podstate sa tak dá chápať.

Požiadavka, ktorá je náročky v agilnom projekte zapísaná inak. Jednoducho a prehľadne. Na kartu, s ktorou sa dá manipulovať. Story je zapísaná v tejto forme:

 

 

Príklad (a môj odkaz pre Zajtra.sk :))

 

Rozdiely voči úlohe? Story jasne popisuje kto, čo a hlavne prečo to potrebuje. Tým, že je popis stručný, je aj požiadavka pomerne presne popísaná a je navyše malá rozsahom. A teda ľahko manažovateľná. Dá sa pomerne ľahko určiť kto je schopný story riešiť a ako dlho bude trvať jej riešenie. Dá sa ľahko implementovať v krátkom časovom intervale a sledovať jej priebeh.

Všimnite si veľmi dôležitú vec. Story nepopisuje AKO problém riešiť. Prečo? Lebo človek, ktorý požiadavku zadáva to nevie. A ani by nemal chcieť vedieť. Nato tu máme lepších expertov, vývojový tím.

Backlog

Bohužiaľ ďalšie anglické slovo. Backlog je utriedeným zoznamom stories.
Na rozdiel od zoznamu úloh je tak backlog popisom produktu, nie činností a aktivít. Tento zoznam nie je len utriedený, ale navyše stories sa líšia v detailoch popisu. Čím dôležitejšie tým presnejšie. Tie najmenej dôležité sú často popísané iba titulkom, napr. Finančná analýza

Backlog je spravovaný produktovým vlastníkom. Iba on určuje dôležitosť, poradie, stories v backlogu. To on pridáva detaily tak, aby najdôležitešie úlohy boli popísané čo najpresnejšie. Tak aby vývojový tím ich vedel implementovať.

Hey dude, where is my backlog?

Kde je backlog v agilnom projekte? No predsa na tabuli! Všimnite si prvý stĺpec s názvom Product backlog. Všimli ste si to keď ste čítali minulý diel o viditeľnosti?

Každá sivá kartička popisuje story. Potrebujete zmeniť prioritu? Presňte kartu vyššie alebo nižšie. Na základe čoho? Na základe obchodnej hodnoty vlastnosti.

Tipy

  • Story by mala byť implementovaná maximálne počas polovice iterácie.
  • Story by mala mať aj akceptačné kritéria. Tie sú malým kontraktom. Zvyčajne zapísané počas plánovacích mítingov spolu so zákazníkom, produktovým vlastníkom a tímom.
  • Nezaoberajte sa odpoveďami na otázku AKO. V Scrume budete mať inú príležitosť kedy sa to spýtať. Nie pri definovaní produktu.
  • Story je buď dokončená alebo nie. Neakceptujte Dokončená na 90%. Už len 2 minúty.
  • Dokončená môže mať rôzny výklad. Dohodnite sa čo znamená HOTOVO.
  • Detaily v popise story pridávajte tak NESKORO ako sa dá. Predpokladajte zmenu. Ušetrite čas, ktorý strávite pri podrobnej špecifikácii požiadavky na vývoj. Aj tak sa požiadavka zmení.
  • A na záver najdôležitejšie. Každú novú požiadavku zapíšte na papierik a roztrhajte ho. Pretože iba 20% vlastností je použitých užívateľmi aplikácií. Ostatné je nepotrebný odpad.

Linky

Článok bol publikovaný na Zajtra.sk

Viditeľnosť v projekte je kľúčová

Posted on by

Sledovanie úloh, ich priradenia a progresu je v klasickom manažmente zväčša úlohou projektového manažéra. V agile/scrume je to ale úloha celého tímu. Prečo? Lebo manažment agilného projektu je založený na spolupráci ľudí (viď Roly).

Kľúčom je viditeľnosť, pretože podporuje dôveru klienta, manažmentu a aj ľudí v tíme samotnom. Koľkokrát ste mali pocit, že robíte podstatne viac ako kolega sediaci vedľa Vás? Je to ale skutočne tak? Projektový manažéri možno majú prehľad, no často táto viditeľnosť chýba na úrovni tímu.

Tabuľa

Zabudnite na Microsoft Project. Viditeľnosť projektu pre všetkých v ňom nie je možná. Použite jednoduchú tabuľu rozdelenú na viacero stĺpcov. Každý stĺpec popisuje stav úlohy.

Obrovskou výhodou je, že Vám stačí len letmý pohľad a okamžite viete stav projektu.

  • Máte viac papierikov na ľavej strane? Pravdepodobne je toho pred Vami ešte veľa.
  • Je veľa papierikov v strede? Máte veľa vecí otvorených. A je ich dokonca viac ako členov tímu? Pravdepodobne by ste si mali prečítať niečo o Getting Things Done (GTD).

Navyše ak takáto tabuľa je v miestnosti, v ktorej je aj tím, tak zmenu, resp. progress, v projekte postrehnete už len periférne keď kolega vstane a presunie papierik.

Distribuovaný tím?

Hmm, pre distribuovaný tím nebude asi jednoduché dosiahnuť takýto vizuálny manažment.

Niektorí sa snažia tabuľu fotiť, potom fotky posielať alebo zdieľať cez wiki do inej lokácie. Výsledok? Nepoužiteľné, pretože vidíte iba rozloženie papierikov, nie detaily. Jediným riešením je dobrá elektronická aplikácia.

Stačí vidieť a byť videný?

Nie, nestačí. Ak by manažment projektu mal byť iba v presúvaní papierikov, tak v podstate nemáte tím.
Základom je komunikácia. Scrum preto odporúča jednoduchú techniku nazývanú denný standup:

  • Tím sa stretne pred tabuľou každý deň v ten istý čas, ktorý vyhovuje všetkým.
  • Každý člen tímu má jednu minútu na zodpovedanie troch otázok. Len jednu minútu nič viac. Čas je najcennejším.
  • Na čom som pracoval včera?
  • Na čom budem pracovať dnes?
  • Aké mám problémy?
  • Potrebujte prebrať viacero detailov? Pokračujte na inej porade a len tí, ktorí majú čo povedať. NIe celý tím.

Zo začiatku vám to bude pripadať ako ďalšia zbytočná porada, ale pri dobrej organizácii je tento míting veľmi efektívnźm spôsobom zdieľania informácii o stave projektu. Najdôležitejšie pre mňa pri tomto spôsobe je, že mnoho informácií vám prejde cez hlavu. Informácie, ktoré sa vynoria v momente keď ich budete potrebovať. Tzv. AHA moment.

Tipy

  • Papierik presúvajte v momente, keď sa mení stav úlohy, nie raz týždenne.
  • Použite rôzne farby pre rôzne typy úloh.
  • Niektoré tímy používajú farbu podľa toho, kto na úlohe pracuje. V agilnom projekte ale chceme mať tím multidisciplínnym, a preto ja osobne to neodporúčam.
  • Indikujte problémy s úlohou vizuálne. Pripnite farebný špendlík, resp. malý červený papierik.
  • Rôzne tvary zlepšia prehľad.
  • Rozdeľte stĺpce na viacero stĺpcov ak váš process je komplikovanejší.
  • Vyhradťte si čas tabule na tzv. parking lot. Parkovisko úloh, ktoré tím nie je schopný samostatne riešiť, resp. nie je zatiaľ jasné čo s úlohou.
  • Tabuľa nie je len pre IT projekty. Obrázok hore zobrazuje úlohy operation tímu.
  • Vytlačte si malé fotky alebo avatarov reprezentujúcich členov tímu. Urobte niečo pre rozveselenie.
  • Používate dovolenkovú aplikáciu? Dajte fotky dovolenkujúcich do samostatnej časti tabule. Jendoduché nie?

Užitočné odkazy

A nakoniec otázka, ktorú by ste sa mali spýtať pred odchodom z práce.

Článok bol publikovaný na http://www.zajtra.sk/zivot/340/manazment-projektu-inak-klucom-je-viditelnost.

Workshop Scrum v reálnom živote, 7.4., Bratislava

Posted on by

Chcete produkovať rýchlejšie a kvalitnejšie ako konkurencia? Komplikujú Vám časté zmeny projektov život?

Scrum, agilný projektový framework, mení spôsob vývoja a dodávania produktov s výrazným zameraním na prispôsobenie sa meniacim sa požiadavkám zákazníka, skrátenie cyklu vývoja, zlepšenie tímov a zvýšenie kvality.

Registrovať

Workshop Scrum prakticky umožní Vašim tímom pochopiť základy frameworku, roly a ich zodpovednosti, agilné postupy pri vývoji a agilné metriky. Naučíte sa ako pracovať s množstvom požiadaviek a ako odhadnúť agilný projekt.

Scrum spoznáte praktickými príkladmi a hrami, ktoré budete môcť aplikovať aj vo svojich tímoch. Táto forma je overená stovkami účastníkov v minulých rokoch.

Prečo?

  • Pochopíte Scrum, roly a ceremónie. Dozviete sa o agilných princípoch a iných metódach.
  • Aplikujete Scrum prakticky počas workshopu.
  • Naučiť sa plánovať s prispôsobením sa častým zmenám.
  • Spoznáte spôsoby prioritizácie požiadaviek Vašich zákazníkov podľa obchodnej hodnoty.
  • Porozumiete ako je potrebné zmeniť myslenie pre zrýchlenie vývoja.
  • Naučíte sa praktické hry a príklady, ktoré pomôžu Vašim tímom pri adaptácii agile.

Pre koho?

  • Senior manažment – ak uvažujete o transformáci Vašej spoločnosti
  • Produktový manažment –  ak potrebujete pracovať s množstvom požiadaviek a chcete dodávať kvalitné produkty načas.
  • Projektový manažment – ak chcete riešiť dilemu trojúholníka rozpočet , rozsah a čas.
  • Vývojári, testeri a iné roly v tíme

Zažite Scrum prakticky!

Agilná transformácia formou hry

Posted on by

Keď pred pár týždňami nás kontaktoval Zsolt Zsuffa z Budapešte ohľadom participácie na Agile Meetupe, ponúkli sme rôzne témy krátkeho školenia. S prekvapením sa však Zsolt priamo spýtal na agilné hry. Zaujali ho naše skúsenosti a výsledky a tak chcel skúsiť touto formou stmeliť aj agilnú komunitu v Maďarsku. Pre nás to bola možnosť konečne po prezentáciách urobiť aj niečo praktické, čo ľudia budú môcť vyskúšať aj vo vlastných firmách.

Prechod na agilné technológie je  v dnešnej dobe aktuálnym v mnohých spoločnostiach. Spoločnosti sú zväčša zamerané len na výsledky, ktoré sa dajú merať. V mnohých prípadoch však chýba niečo oveľa dôležitejšie, čo agile priam vyžaduje – zmena myslenia. Táto zmena vyžaduje čas a skúsenosti. Nedá sa naučiť, musí sa zažiť. Je to dospievanie. V takomto prípade je zlyhanie dokonca cennou skúsenosťou, ktorú chceme zažiť často a skoro, hlavne ak ste na začiatku transformácie.

Agilné hry sa stávajú (podobne ako v živote dieťaťa) katalyzátorom vývoja a stávajú sa tak lepidlom ktoré prepája teóriu s praxou. Sú možnosťou ako sa naučiť robiť agile na príkladoch. S pomocou kouča takto tímy nemôžu zlyhať pri učení ako agile robiť.

Hry hrajeme počas tréningov na Slovensku aj v zahraničí už niekoľko rokov. V Budapešti sme sa zamerali na hry vybrané pre transformáciu spoločností na agile:

  • vytvorenie tímu a jeho samoorganizácia
  • pochopenie problémov a zvyraznenie ich podobnosti v celom softvérovom priemysle
  • identifikácia dôvodov prečo agile vzniklo
  • naučenie sa ako robiť agile, ako pracovať v časových iteráciách, ako samoorganizovať nielen tím, ale aj prácu, prečo je jednoduché zadanie požiadavky často efektívnejšie než dlhé dokumenty
  • ako sa zlepšiť použitím retrospektívy

Originál viď ScrumDesk: Serious Play – accelerate your transition to Agile

Agile games (for Budapest meetup)

View more presentations from ScrumDesk.

Ako uspieť, ak ste už raz začali

Posted on by

obal.succeeding.with.agile

Nie vždy sa mi stáva, že sa mi dostane do rúk kniha, ktorá by dokázala posunúť môj názor na nejakú vec naraz vo viacerých smeroch. Tentokrát som mal  opäť raz šťastie, keď som natrafil na Succeeding with Agile od Mike Cohna. Je niekoľko vecí, ktoré sa dajú o tejto knihe povedať, a jedna z nich je, že ak to myslíte s agilnými metódami vážne, tak čas strávený jej čítaním nebude určite premrhaný.

Táto kniha nie je pre ľudí, ktorí si kladú otázku: „Čo sú to agilné metódy?“, alebo „Ako vlastne vyzerá Scrum?“. Autor predpokladá, že na to už máte odpovede a vedie diskusiu viac do hĺbky adaptácie agility. Je to kniha hlavne pre ľudí, ktorí čo-to o agilných metóda vedia, niečo si aj skúsili a narazili na rôzne druhy prekážok. Jej čítaním totiž veľmi ľahko zistíte, že vaše problémy nie sú až tak unikátne ako možno vyzerajú a ich riešenie už existuje. Zaujímavé sú napríklad takzvané „časté námietky“ ľudí voči agilným metódam a Mikové odpovede na ne. Niektoré vám možno budú pripadať povedomé…

Kniha je rozdelená na päť častí, pričom v prvej autor vysvetľuje základné fakty o adaptácii Scrumu. Nečakajte ale vysvetlenie toho, čo je to sprint. Namiesto toho Mike prezentuje 5-krokový proces, ktorý je vhodný k adaptácii Scrumu a vzory šírenia agilných praktík medzi tímami. Okrem toho zavádza pre mňa veľmi príslovečný pojem „organizačná gravitácia“ – t.j. pôsobenie (sily) zvyšku organizácie voči prechode tímu na agilnú metódu. Ak prekonáte túto silu, dostanete sa na orbit (úspešná a trvalá adaptácia), ak nie, stiahne vás to späť.

Druhá časť pojednáva o jednotlivcoch. Hneď prvá kapitola vás naučí poradiť si s odporom k zmene (veľmi dobré čítanie na túto tému je aj kniha „Pocit naliehavosti“ od John P. Kottera). Ďalšie kapitoly informujú o tom, ako zaviesť nové roly, ktoré so sebou Scrum prináša (vytvorením alebo transformáciou klasických existujúcich) a ako ľudom vštiepiť technické praktiky, ktoré sú pre agilný vývoj nutné.

V tretej časti si berie na mušku fungovanie tímov. Od štruktúry tímu, cez budovanie spolupráce až po podporu samoorganizovanosti v tíme. V tejto kapitole tiež môžete nájsť informácie o tom, ako by mal vyzerať váš backlog, sprint, plánovanie a čo robiť, aby  ste do vášho produktu zapiekli dostatočné množstvo kvality.

Štvrtá časť je zameraná na väčšie organizácie. Mike prezentuje svoje znalosti ako sa vysporiadať s veľmi veľkými projektmi alebo ako zaviesť Scrum do distribuovaného prostredia. Zvláštna kapitola je venovaná spoluexistencii agilných metód s inými (klasickými) metódami v jednej organizácii. Ak ste niekedy stáli pred problémom ako riadiť projekt, ktorý je vo vnútri agilný a navonok klasický-sekvenčný, tak v tejto kapitole nájdete zopár dobrý postrehov.

Posledná časť je najkratšia, ale o to silnejšia. Mike v nej vstupuje do oblasti, o ktorej som ja osobne zatiaľ veľa literatúry nevidel, a to meranie agility. Ako veľmi ja náš tím agilný? Kde sme v porovnaní s obdobím pred rokom alebo v porovnaní s inými tímami? Ako veľa hodnoty sme dodali zákazníkovi? Ak vás trápia tieto alebo podobné otázky, tak v tejto kapitole by ste mohli nájsť zopár drahokamov medzi riadkami. Osobne ma prekvapilo, aké jednoduché praktiky sa dajú použiť, aby sme zistili, akú veľkú hodnotu dodáva tím zákazníkovi (niektoré z nich sme v našom tíme vyskúšali, a bolo naozaj zaujímavé sledovať ako zopár jednoduchých obrázkov vyjasnilo pomery).

Kniha Succeeding with Agile je určená ľudom, ktorí agilné metódy skúšajú a boria sa s rôznymi problémami, ktoré takáto adaptácia prináša. Je určená pre bojovníkov, ktorí sa rozhodli bojovať s organizačnou gravitáciou, aj pre zvedavcov, ktorí by sa už radi dozvedeli niečo viac, ako ponúka základné video o Scrume na Youtube. Je cítiť, že Mike do knihy vložil svoje dlhoročné skúsenosti a že píše o veciach, ktorým rozumie. Preto by táto kniha mala byť v knižnici každej spoločnosti, ktorá to s agilitou myslí vážne.