Agilia konference 2016 – potvrzení evropské špičky II.

Tento příspěvek navazuje na shrnutí myšlenek Toma Gilba na téma kvantifikování hodnoty a Catalina Dogaru na téma servant leadershipu z prvního dne Agile Konference 2016. Dalšími řečníky, jejichž přednášky jsem stihl navštívit byli Ahmad Fahmy, Łukasz Węgrzyn a Scott W. Ambler.

Agilia rozhovoryVíc jsem toho z nabitého programu bohužel nestihl. Zbytek času jsme pro vás připravovali a natáčeli rozhovory s některými z hvězd letošní Agilia konference (konkrétně Scott Ambler, Tom Gilb nebo Łukasz Węgrzyn), na které se můžete těšit na stránkách a sociálních sítích Aguarry v následujících měsících 😉

Ahmad Fahmy a jeho zkušenosti z rozsáhlých agilních projektů

Jako úvod k tématu zmínil Ahmad aktuální výsledky Chaos reportu z roku 2015, kde úspěšnost rozsáhlých agilních projektů vykazuje 360% úspěšnost oproti tradičně řízeným rozsáhlým projektům. Důležité pro škálování projektů je neztratit možnost autonomie, zdokonalování se a znalosti smyslu, co a proč dělám. Škálování přes funkce (tj. analýza, vývoj, testování, …) vede ke ztrátě těchto 3 možností.

AhmadPrvním krokem zavádění změny má být podle Ahmada „rozbití“ současného modelu. Ahmad zmiňoval svoji zkušenost, kdy:

  1. v prvním kroku nastavili týmům vzory a omezení (technologie, počty, byznys vazby apod.) tím, že lidem dali za úkol popsat, jak by vypadaly perfektní týmy podle nich.
  2. pak je nechali samotné se zformovat podle těchto vzorů a popsaného ideálního stavu – zcela „překvapivě“ lidé vytvořili úplně něco jiné, zformovali se podle přátel a funkčních rolí 🙂
  3. iterativně a opakovaným poukazováním na omezení a ideál, který si lidé popsali sami se podařilo zformovat něco jako feature týmy (opravdu to nebyl cíl, kam by týmy někdo manipuloval, tak to lidé nakonec viděli jako nejlepší).
  4. týmy jako první kroky navrhly přípravu prostředí, tudíž první 3 měsíce se nevyvíjel produkt a jeho funkčnosti (!!!), ale týmy připravovaly test casy, buildování a celou CI infrastrukturu a reálné dashboardy se semafory ukazující skutečný stav produktu a vývoje.

Ahmad pak celou změnu shrnul do následujících kroků:

  1. Začněte s produktovými týmy: vytvořte týmy, najděte vhodné lidi a role (hlavně role Product Ownera/Product Manažera), poskytněte jim školení a zapracujte je, až pak začněte skutečný vývoj!
  2. Logicky je nutné na úvod počítat s menší velocity než dříve, naučení se novým postupům chvíli trva. Všichni to vědí, ale málokdo to skutečně udělá (buď se neměří, nebo se neřeší, nebo se běžně porušuje závazek ve sprintu, nebo se to nepodaří prodat byznysu z důvodu řešení jen krátkodobého dopadu). Velocity lze ale snadno vizualizovat a rostoucí trend je dobrý argument i pro byznys 😉
  3. Bacha na příliš mnoho změn naráz! Příliš mnoho požadovaných změn v chování způsobí chaos a odmítnutí této cesty týmem (znáte, že?). Dělejte i změny inkrementálně, nejen vývoj produktu – každých několik sprintů jednu změnu, až si sedne, tak další, ostatně to je jeden z hlavních smyslů retrospektiv – inkrementální vylepšování způsobu práce. A pozor na celý kontext: 1-2 releasy ročně stále vedou k vodopádovému myšlení i když máte agilní životní cyklus a praktiky.
  4. Začni pilotním pokusem, jedním týmem, vylaďuj, hledej cesty a refaktoruj jen část organizace, stejně jako s kódem pěkně refaktoruj firmu (stejně jako produkt) část po části!
  5. Změnu začínejte se středním managementem, oni jsou typicky vlastníkem systému a procesů a oni typicky bojují proti změnám nejvíce, protože jsou jimi nejvíc ohroženi. Ano, podpora nejvyššího vedení je důležitá, ale bez středního managementu neproběhne žádná změna úspěšně (viz ponaučení třeba ze Semlerova Podivína).

Łukasz Węgrzyn o agilních kontraktech

Na tento příspěvek jsem se hodně těšil, protože problematiku znám, mám s ní praktické zkušenosti a tak mě zajímalo, jak bude právník danou problematiku prezentovat IT a management lidem a zda představí jiné modely agilních kontraktů, než znám. Lukasz moje vysoké očekávání rozhodně naplnil a navíc ještě hodně pobavil 🙂

CfTpQ-2WwAAmXXb

Typický právník požaduje dobu trvání, plán a rozpočet jako hlavní části kontraktu, protože je jednoduché je kontrolovat, ověřit a případně jejich neplnění penalizovat.

Toto je typický právnický postoj slovy Lukasze. Žádná spolupráce, žádné my, žádná společná cesta.

Kontrakty se vytváří pro potřebu sporů a válečných vřav u soudu, proto je snaha o jejich neprůstřelnost, úplnost a jsou tak strašně složité a nesrozumitelné. Klíčová domněnka za tímto postojem je, že všechno se pos**e, pardon pokazí. Rizik je ale v reálném světě vývoje IT produktů a služeb tolik, že stejně není možné je všechny v kontraktu popsat.

Proto je klíčová změna postoje:

  • z původního: vyhrát soud v případě problémů
  • na nové: doručit společně a úspěšně projekt

Klíčové prvky tohoto postoje, které se zrcadlí v agilním kontraktu, jsou pak následující:

  • změnová procedura – změna, její akceptace a průběh. Vše nemusí být na papíře a už vůbec ne dodatek smlouvy, klidně to může být emailové potvrzení, závěr v zápisu z diskuse se zákazníkem.
  • právní autorizace schválit změnu – ideálně je tou rolí PO, který může říct ano/ne na určitou změnu.
  • budování vzájemné důvěry – kontrakt by měl obsahovat procedury spolupráce (JAK budeme schvalovat plán, JAK budeme akceptovat doručené, JAK na zmíněné změny – klidně i referencí na Scrum s doplněnými detaily schvalování a akceptací) a možnosti exit pointů na obou stranách (kdy a jak lze ukončit spolupráci, komu připadne zdrojový kód, co IPRs, data apod.).

Scott W. Ambler o důležitosti kontextu pro volbu modelu vývoje

Scott začal tím, že se snažíme dávat závodní motory (agilní jen oddělení vývoje) do traktorů (zbytek organizace) a pak jsme překvapeni 🙂 v přirovnání pokračoval a zdůraznil, že potřebujeme nejen závodní auto jako celek, ale i celý podpůrný tým mechaniků, inženýrů a dalších, abychom byli schopni vyhrát závod.

ScottScott představil principy DAD (Disciplined Agile Delivery Framework), které stojí na zkušenosti, znalosti kontextu a informovaném výběru, ne napředepsaných praktikách, které musím „slepě“ dodržovat:

  1. Empirie je lepší než teorie (ano princip Agilního manifestu), takže DAD je empirický rozhodovací framework.
  2. Záleží na kontextu – tým a jeho zkušenosti, lidské vlastnosti, používané technologie, množství legacy kódu, velikost týmu, distribuovanost, omezení domény a její složitosti, toto vše má vliv na potřeby procesu a prostředí týmu. Rozhodně všem nebude pasovat to stejné, jak se o to snažíme často v praxi.
  3. Smyslem jsou opakovatelné výsledky, ne opakovatelný proces (bez výsledků).
  4. Informovaný, ne náhodný výběr modelu vývoje – vyberu proces a praktiky podle bodu 2 s vědomím všech možností (Agile sprinty/Scrum, Lean neustálé flow/kanban, Lean Startup/výzkum a rychlé doručení, CI).
  5. IT oddělení typicky obsahují více modelů životního cyklu, nejen jeden (logicky, mají jiné potřeby: vývoj, provoz, maintenance).
  6. Organizace jsou složitým adaptivním systémem, opakovatelný 1-size-fits-all proces tedy nedává smysl, jelikož se i organizace a její cíle neustále vyvíjí. Napojte váš proces vývoje na cíle firmy, definujte komunikační rozhraní na ostatní týmy a neustále je podle měnících se potřeb přizpůsobujte (ano, zase ta retrospektiva, která k tomu má sloužit ;)).
  7. Tým vlastní svůj proces a podle potřeb ho mění (respektujíc při tom například regulační omezení firmy a vazby na další týmy a produkty), což často v korporacích není pravda.
  8. Optimalizujte tok hodnoty (produktu) daným procesem vývoje, ne vytváření dokumentů.
  9. Snažte se přijmout změny a naučte se s nimi pracovat, o tom ostatně byly všechny předchozí body 😉

Víc jsem toho opravdu nestihl, ale další shrnutí i z jiných přednášek a workshopů konference napsal Vojta Bárta.

Příspěvek byl publikován v rubrice Články se štítky , , , , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *