Business Agility

Business agility je jedním z termínů, které se stále častěji skloňují v agilním světě. Agilním světem už totiž dávno nehýbou praktiky, metody a frameworky na úrovni jednotlivých týmů (tedy pořád je potřebujete, abyste mohli vaší agilní cestu začít), ani metody škálování neboli scalingu (které pořád potřebujete, abyste dosáhli impactu na produktu). Obojí je popsané, známé, a nic zásadního se v tomto světě nemění. Už je to vymyšlené a ověřené v prostředích mnoha různých firem. Stačí se zkušenostmi ostatních nechat inspirovat, vybrat z nabídky tu, která existuje a je popsaná a některý přístup aplikovat. Když se ho budete držet, je velká šance, že budete úspěšní, nechám pro jednoduchost tentokrát stranou přístupy, které už na první pohled agilní nejsou a agilního světa si půjčili jen terminologii. Ale ty jsou snadné odhalit. Nepřinášejí žádnou radikální změnu vašeho fungování a jen věci přejmenují.

Když tedy zvolíte něco z agilní kuchyně, a začnete měnit jednotlivé týmy, jejich fungování a mindset, vytváříte podhoubí pro změnu organizace jako takové, protože jednotlivci, kteří jednou zažili pravou týmovou spolupráci, autonomii danou samoorganizací a drive zacílením na business hodnotu a zákazníka už nikdy nechtějí zpět do starého světa, kde sice vše bylo jednoduché a definované, ale o to menší motivaci to přinášelo. Transformace na úrovni týmů aktivizuje zaměstnance a začne změnu kultury odspodu.

Businessový impact, který aplikace scaling přístupů z agilní kuchyně přinese, staví na změně, která se stala na úrovni týmů, ale tentokrát to není změna zaměřená na lidi, ale business výsledky. Když obě tyto změny dáte dohromady, vytvoříte tlak na změnu organizace jako takové. A to jak po stránce kultury, tak fungování businessu. Vzniká tlak na zeštíhlení organizační struktury (až do takzvané flat organizace), rozbití funkčních či systémových funkčních celků (a formování menších autonomních entit které dokážou samy dodat end-to-end hodnotu), a na zjednodušení procesů a odstranění zbytečné byrokracie, která brání flexibilitě a dynamické reakci na potřeby zákazníků a trhu. Zjišťuje se, že agilní organizace, které fungují jako adaptivní síť spolupracujících týmů, která by se spíše než k velkému tankeru s centrálním řízením a hierarchickou strukturou kapitánů a důstojníků dala přirovnat k flotile malých loděk, které samostatně rozhodují a fungují, ale společně jdou za jedním cílem a smyslem existence, jsou daleko lépe přizpůsobené pro řešení komplexních problémů a reakce na změny trhu.

Business Agility mění svět organizací tak jak jsme ho znali. Přináší jinou kulturu, strukturu a styl leadershipu. To, co jste znali, a to, v čem jste vyrůstali se stává nepodstatné a zbytečné. Zkušenosti s řízením tradičních organizací jsou najednou kontraproduktivní a stahují vás zpět do starého světa. Myslíte, že vás se to netýká? Možná. Ostatně kolik firem si to před vámi myslelo také. Jsme přeci úspěšní, máme nejlepší mobilní telefon na světě (Nokia), jsme jednička na trhu s fotografováním (Kodak), máme nejlepší kopírky (Xerox), a můžu pokračovat… Seznam je dlouhý a má jednoho společného jmenovatele. Organizace, které věřily, že se nemusí měnit, protože už jsou úspěšné. Dnes více než kdykoli jindy za posledních sto let je reakce na změnu a schopnost se adaptovat v závislosti na turbulentní změny trhu klíčová. Inovace a kreativita je to, co vás možná zachrání. Takže jestli nechcete skončit na hřbitově firem jako výše zmíněná jména, je na čase se pustit do opravdové agilní transformace. Zapomeňte na milé hochy a slečny, co s vámi budou hrát hry a říkat, že se měnit nemusíte. že si můžete nechat projekty, oddělení, procesy a management tak jako dřív. Jestli to myslíte opravdu, bude to bolet. Ale co vás nezabilo to vás posílí. Ozvěte se. Já nedělám transformace na oko. Dělám ty, co bolí ale fungují.

Jak na škálování Scrumu pro více týmů? Ideální je LeSS Large-Scale Scrum

Když zavádíte či ve firmě používáte Scrum, časem se dostanete do situace, kdy potřebujete aplikovat Scrum na něco většího, a nechat spolupracovat více týmů. Obecně to není nic složitého, ale abyste se v tom neztratili, je vhodné si trochu pomoct nějakým frameworkem. U menší produktové firmy je to pořád relativně snadné. Použijete Scrum ve větším, tedy Large-Scale Scrum (LeSS).

Large Scale Scrum - LeSS

LeSS je jednoduchý framework, který staví na principech Scrumu a dále je používá na více týmů. Tedy v kostce máte, jednoho Product Ownera, jeden Product Backlog, jeden produkt, který prezentujete zákazníkům, ale více týmů, kteří ho společně dodávají. Týmy jsou stejně jako v klasickém Scrumu stabilní, self-organized, a cross-functional – tedy každý tým dokáže vzít libovolnou položku z Backlogu a dokončit jí. Musí tedy mít všechny kompetence, které jsou potřeba aby mohli dodat end-to-end hodnotu zákazníkovi podle Definition of Done např. DB, backend, frontend, dokumentace, UX, architektura, automatické testy, uživatelská dokumentace apod.). Takhle jednoduchý koncept platí pro prostředí do osmi spolupracujících cross-functional týmů.

Product Backlog
Pokud jste velká korporace (banka, pojišťovna, nebo prostě jen velká IT firma či firma s velkým IT oddělením), principiálně je to stejné. Jen implementace je výrazně komplexnější a změna náročnější. V takovém případě už si nevystačíte s jednoduchým LeSS frameworkem, ale musíte použít takzvaný LeSS Huge – tedy Large-Scale Scrum pro obrovská prostředí. Pořád máte stabilní, self-organized, a cross-functional týmy, které společně dodávají jeden produkt. Je dobré si uvědomit že produkt není projekt. Projekt je jen jednou položkou Product Backlogu. Více si o tom můžete přečíst tady. Produkt je tedy daleko dlouhodobější a umožňuje postavit stabilnější týmové prostředí.

Large Scale Scrum - LeSS HugeLeSS Huge není až tak odlišný od klasického Large-Scale Scrumu. Co je ale v LeSS Huge složitější je struktura Product Backlogu. Zbytek zůstává stejný. Překvapivě jednoduché, že? Abychom si zachovali takzvaný tah na branku, stále chceme mít jednoho Product Ownera a jeden Backlog. To ale už není tak snadné, a tak vzniká podpůrná struktura takzvaných Area Product Ownerů, kteří pomáhají výše zmíněnému Product Ownerovi s prioritizací. Arey nejsou fixní, ale dynamicky se mění podle potřeb businessu – ostatně stále platí, že týmy jsou cross-functional, takže mohou vzít z Backlogu jakoukoli položku a naplánovat ji do Sprintu. Co neumí, učí se. Obvykle ale nemusí umět vše a věnují se nějaké oblasti (Area). Nezapomeňte ale, že oblast není komponenta a týmy dodávají vždy end-to-end funkcionalitu. Product Backlog je stále jeden, a tak máme pořád focus na ty pro firmu businessově nejdůležitější věci.

Je to jednoduché, a hlavně to funguje. Ale stejně jako Scrum, ani Large-Scale Scrum tedy LeSS není žádná zázračná pilulka. Aby zafungoval vyžaduje změnu myšlení, přístupu a mindsetu. Ale na to jste si v Agilním světě jistě zvykli. 🙂

Co je to produkt a co projekt

Projekt začíná a končí. Produkt je tady ‘donekonečna‘. Pokračuje dalšími fázemi, rozšiřuje se, mění se.  Definice, kterou používá LeSS (Large Scaling Scrum) říká, že produkt by měl být tak široký jak je jen možné, ale stále praktický. Praktičnost obvykle končí hranicemi vaší firmy. Když už byste museli do cross-functional týmů zakomponovat lidi z cizích firem, abyste mohli dodávat end to end funkcionalitu, tak jste asi na hranici produktu. Na druhou stranu, jestliže produkt vnímají zákazníci jako jeden produkt – je to jeden produkt bez ohledu na technologii. Tedy frontend a backend je jeden produkt. Internetové řešení obsahující Web, iPhone a Android aplikaci je jeden produkt. Z druhé strany všechno co má podobný kód a je technicky podobné je jeden produkt.

Továrna na párky

Firmy často nevědí, kdy se na to co dělají, mají dívat jako na jeden produkt (viz výše zmíněná kritéria) a kdy to naopak rozdělit na více celků. Analogie, kterou pro takové rozhodnutí používáme, se jmenuje Továrna na párky. Chodí k vám různé zakázky-projekty. Někdo chce hovězí párky na večeři, někdo grill mix na párty. Někdo chce dokonce vegetariánský párek, někdo pikantní chilli. Když se na to budete dívat projektově, nikdy nepostavíte stabilní cross-functional týmy. A Agile vám nikdy pořádně nebude fungovat. Když ale řeknete, že vaše továrna na párky je továrna na internetová řešení, a na projekt se budete dívat jen jako na velký Epic v Backlogu, bude vše najednou snadné. Máte jeden Backlog, tam se sypou veškeré projekty. Jako každá položka Backlogu prochází Backlog Refinementem a prioritizací. Týmy pak jen berou ty nejdůležitější položky z Backlogu a dodávají je v rámci svého procesu v kvalitě odpovídající Definition of Done.

Když to mám nějak sesumarizovat, většinou produkt proti současnému stavu rozšiřujeme a stavíme stabilní továrnu, kde týmy mohou spolupracovat na jedné věci. Na druhou stranu takových továren můžete mít ve firmě mnoho. Například když děláte online hru a informační systémy, asi je praktické aby to byly dvě továrny a ne jen jedna.

Jak takovou velkou továrnu organizovat? Na to odpovídá například Large Scaling Scrum LeSS –kdybyste se chtěli o LeSS frameworku dozvědět více, pořádáme 3 denní LeSS workshop při konferenci Agile Prague 2016 v září.

Scaling Agile and Scrum

Poslední dobou se vyrojila spousta různých metod jak škálovat Scrum a Agile proces na prostředí velkých produktů. Takže než se chytíte do sítě různých klasicky smýšlejících organizací, které ve Scalingu konečně našly cestu jak naoko aplikovat Scrum, ale praktiky nemuset měnit, tak se zkuste podívat na zcela Agilní přístup jak na to.

Není na tom nic až tak složitého.  Jen musíte rozumět tomu, co je opravdu Scrum. Není to totiž proces jak řídit vývoj, ani něco kvůli čemu máme Backlog a Standupy, ale přístup, filosofie a kultura. Obecně se tomu říká empirický proces. Tedy velice volně definovaná pravidla hry. Každá taková Scrum hra má své hřiště s pevně danými mantinely a pár pravidly jak hrát. Jinak by to byl chaos. Ale už neříká, co přesně v které situaci musíte udělat. K tomu jsou definované best practices. A Scaling Scrum je často ukázkou, jak k tomuto problému lze přistoupit neagilně a nescrumově – tedy kolem Scrum týmů vytvořit složité byrokratické struktury nových rolí, procesů,  meetingů, pojmů.  Viz obrázek, kde ta bílá plocha je to, co je původní Scrum.

Opačný přístup zvolil Bas a Craig s frameworkem LeSS. Stejně tak, jako když Ken kdysi dávno definoval Scrum a měl možnost si zvolit, které praktiky budou součástí Scrumu a které ne, volil spíše méně než více. A protože Scrum je něco, co se stále vyvíjí, je dnes na rozdíl od začátku nedílnou součástí Scrumu Retrospektiva, ale například story pointy, User Stories and Scrum Board jsou jen doporučené praktiky. Proto je Scrum tak úspěšný. Je totiž aplikovatelný úplně kdekoliv. Když se vrátím k LeSS Large-Scale Scrum frameworku, tak přesně to je hlavní filosofií LeSS – ‘Do more with LeSS‘.

Co se tedy podle LeSS musí změnit proti jednoduchému obrázku, kde máme jen jeden Scrum tým? Na první pohled nic zásadního. Pořád máme jeden stejný Sprint, jeden ‘potentional shipable product increment‘, jeden kód a continuous integration. Pořád máme cross-functional týmy které dokážou jako tým samostatně dokončit jakoukoli položku z Product Backlogu. Týmy si dělají své vlastní Standupy a Retrospektivy. Pořád máme všichni jeden cíl, dodat hodnotu zákazníkovi. A tak pro jeden produkt máme jeden Product Backlog a jednoho Product Ownera – a nemusíte se bát, zvládne to. On totiž Product Owner nikdy nepracuje sám a i na tom jednoduchém 1-1 obrázku má spoustu pomocníků.

Takže v podstatě jediné, co se změnilo je, že na úrovni development týmů se zajímáme co dělají ostatní týmy, jednotliví členové spolu řeší závislosti. Ne co se týče businessu, protože položky Backlogu jsou nezávislé, ale závislosti v kódu, dané konkrétním řešením dané Story. Dále obvykle posíláme zástupce týmů, aby chodili jako pozorovatelé na Standup ostatních týmů a identifikovali tak včas případné návaznosti a rizika. Na úrovni produktu už není jen na Product Ownerovi, aby před Sprintem vybral priority pro příští Sprint, ale obvykle se takového výběru zúčastní i zástupci týmů, aby zohlednili jejich různé zkušenosti. Nakonec je tu ještě jeden nový meeting – Overall Retrospective – jejímž cílem je udělat retrospektivu na téma jak nám jde spolupráce. A jak se asi dá očekávat, jsou tam ScrumMasteři, Product Owner, a zástupci týmů a koná se vždy po skončení Sprintu.

Nic složitého. A jestli to funguje? Ale jistě. První implementace Scrumu, ve které jsem se ocitla ještě jako vývojář, byla přesně taková. Tři týmy, jeden produkt. Časem jsem byla ScrumMasterem několika týmů právě v takovém uspořádání, tentokrát pro šest týmů. A jako Agilní coach jsem takové uspořádání pomáhala implementovat v mnoha různých firmách. Takže ano, funguje to, je to snadné, je to Agilní, a přináší to výsledky. Jestli jsem vás nepřesvědčila, můžete se podívat na některou z LeSS case studies nebo na detailní popis LeSS Large-Scale Scrum Frameworku.

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

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.

Agile Prague Conference 2014

Jako každý rok je tady doporučení, co byste neměli minout, na konferenci Agile Prague. Těšit se můžete na Lindu Rising, která v Praze na Agile Prague byla před dvěma lety, a osobně její přednášky považuji bez ohledu na téma za vynikající. Ze známých tváří se dále můžete těšit na Andrea Provaglio, který se vrací do Prahy již popáté a tentokrát to bude na téma očekávání – The Expectation. Anebo Kevlin Henney, který kromě přednášek vede i jednodenní workshop na téma Agilní architektury – Architecture with Agility.

Kdo na druhou stranu bude v Praze poprvé a rozhodně stojí za zmínku je Vasco Duarte. Jeastli vás zajímá, o čem to bude, podívejte se na tweety #NoEstimates. Jak to s těmi odhady je vysvětlí v přednášce How to improve software project estimates – The #NoEstimates view.
Několik přednášek se také věnuje tomu, jak aplikovat Agile a Scrum pro více týmů – například keynote, kde Dean Leffingwell mluví o Scaled Agile Framework (SAFe).

Stejně jako předchozí roky se i letos věnujeme developerům i testerům, dáváme prostor i místním firmám, aby mohly prezentovat jak na tom vlastně jsou, v praktických case-studies.
Během konference vám své Agilní certifikace představí i ICAgile, která své certifikace zaměřuje na Agilní metody v širším kontextu než je jen Scrum proces.

Konference není jen o poslouchání talků. Možná nejdůležitější jsou diskuse s ostatními účastníky a speakery. Proto pořádáme první den networking party, kde se můžete seznámit s ostatními a společně prodiskutovat, jaké máte zkušenosti. Druhý den je pro tyto diskuse vyhrazen kromě přestávek a dlouhého oběda open jam session.

Doufám. že se vám program konference i letos bude líbit.