Category: Management

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂

Top 5 bodů co dělá Agilní transformaci úspěšnou

1.    Proč?

Asi úplně nejdůležitější je mít cíl. Proč byste se vůbec měli měnit. Protože jestli vše funguje dobře, firma prospívá a je businesově úspěšná, možná si nechte to, co máte. Ne každý musí být Agilní. Když najdete dostatečně kritický důvod pro změnu, určitě se vám to podaří. Důvody pro Agilní transformaci tedy musejí být strategické z pohledu organizace.

2.    Postoj a pochopení managementu

Druhým střípkem do mozaiky úspěšné Agilní transformace je pochopení managementu. Co tedy management musí pochopit? V první řadě že Agile je změna mindsetu – tedy kultury, přístupu k věcem, myšlení. Není to jen další proces, který bezmyšlenkovitě implementujete a je to. Bude to stát hodně energie na všech vrstvách firmy. Aby se transformace podařila, musíte ve firmě musíte budovat silný Agile Leadership a pomoci managementu se do transformace zapojit, být její součástí a řídit její směr.

3.    Definice Produktu

Dalším důležitým bodem je vědět co děláme. Agilní svět opouští tolik oblíbené projekty a plánuje práci pomocí Product Backlogu. Staví na dobrých Product Ownerech, kteří mají vizi a vědí čeho chceme jako firma dosáhnout.

4.    Experimenty

Dalším bodem, který je pro úspěch Agilní transformace nutný je ochota experimentovat. Určitě si říkáte, že na tom nic není. Ale kolik z vás je ochotno přijmout, že hodně experimentů se nepodaří a jsou tak dobrou příležitostí pro zlepšení? Kolik z vás bere chybu jako příležitost k poučení se? To vše je vlastně Inspect and Adapt princip, který je podstatou celého Scrumu. Experimentujete a hledáte cestu? V produktu i vlastním fungování? Pak jste Agilní. Odmítáte takovou možnost jen připustit a hledáte jednoduché recepty? V Agilní transformaci nic takového nenajdete.

5.    Trpělivost a odvaha

V neposlední řadě je to trpělivost a odvaha. Trpělivost proto, že taková změna se nestane přes noc a pro velkou korporaci je Agile cesta která trvá několik let a vlastně nikdy úplně nekončí. Agile je o neustálém hledání lepší cesty, neustálém zlepšování. Dobrá zpráva je, že výsledky přijdou hned jak se na cestu dáte, tedy už po pár Sprintech. Odvahu proto, že budete dělat věci jinak než dřív, a dost možná i jinak než ostatní kolem vás. A to odvahy vyžaduje docela dost. Budu vám držet palce 🙂

Pozvánka na Agile Prague Conference 2018

Jako každý rok bych vás ráda pozvala na konferenci Agile Praguekterá bude 10-11. září v Praze. Agile Prague je každoročně největší událostí Agilního světa a stejně jako poslední roky má bohatý program. Tématem letošního roku je Business Agility, tedy Agile v rámci organizace jako takové. Každý den začínáme dvěmi keynoty, dále pak program kombinuje krátké talky, case-studies a workshopy/hry. V poledne máte kromě oběda i možnost zapojit se do openspace, kde program vzniká na místě a kdokoli z vás může nabídnout jakékoli téma o které se chce podělit nebo se o něm něco dozvědět. Věnovat se budeme velkým transformacím, kultuře týmů, produktům a scalingu, co to je Agilní organizace a jak funguje, jak se v Agilním světě liší role managera a co to je Agilní Leadership. Prostě inspirace bude hodně.

AgilePragueConference

Namátkou zmíním Romana Pichlera který bude mluvit o tom, jak navrhnout produkt, který uživatelé chtějí, tématu UX a dobrému designu se bude věnovat Liam Hutchinson, David Hussman nás v rámci své keynote provede discovery fází produktu. Ostatně kdyby vás to téma zajímalo, David má ve středu po konferenci jednodenní workshop na toto téma.

Case-studies jsou studnicí inspirace, mým tipem na case-study o velmi Agilní firmě s otevřenými platy a společným strategickým řízením od Anny Obukhove a Alexeye Voronina. Nechte se inspirovat. Není to jednoduchá cesta, ale je fascinující, slyšet jejich story.

Agile již dávno není jen o SW developmentu. Je o celkové změně mindsetu, myšlení, organizace, leadershipu. A na to téma bude také úvodní keynota kde se Yves Hanoulle spolu s Kristynou Lukasovou podívají na to, jak vlastně funguje spolupráce, komunikace a interakce. Z pohledu organizace pak doporučím Evana Leybourna, Marshu Shenk a Mika Lebera.

AgilePragueConferenceKaždé odpoledne máme současně běžící i hry a workshopy, tentokrát na téma Moderního Managementu, Designu her a spolupráce v týmu.

A na závěr to nejlepší. Kdybyste si zrovna náhodou nevybrali, paralelně ke všem talkům, přestávkám a obědům poběží i Coaches Clinic, kde máte možnost získat zcela zdarma Agile coaching od zkušených Agilních Coachů z celého světa.

Myslím, že se je na co těšit. Doufám, že se tam v září potkáme🙂

Český překlad Scrum Guidu

V rámci české agilní komunity vznikl český překlad Scrum Guidu, tedy ‘Průvodce Scrumem‘. Takže kdyby se vám nechtělo Scrum Guide číst v originále, tohle je poměrně povedená aktuální česká verze, která zachovává normálně používané termíny Scrumu, takže se nemusíte bát, že byste se v ztratili překladu jako já nedávno, když jsem dostala od vydavatele českou verzi své knihy The Great ScrumMaster: #ScrumMasterWay na review a musela se dívat do angličtiny co že to vlastně píšu. Takže nejen Scrum Guide, ale i kniha bude. Už jsem ji přepsala zpět do původního významu a čekam na finalni versi od Computer Press. Jupiiii 🙂

Asi o to víc oceňuji práci, kterou si s tím autorky překladu (viz poslední stranka dokumentu) daly. Když k němu budete mít nějaké připomínky, budou určitě rády za feedback a slibují, že ho zohlední. Děkujeme 🙂

Business Agility

V poslední době se mimo IT obor často skloňuje termín Business Agility. Co si tedy pod Business Agility představit? Já jsem se tady hodně věnovala Agilním metodám v IT tak, jak se s nimi začínalo. Ale doba se posunula, Agilní metody se osvědčily a tak více a více slyšíme o aplikaci Agile mimo IT, o zapojeni businessu, o aplikaci Agile na úrovni organizace. V kostce tedy Business Agility. Organizace hledají způsob, jak přistupovat ke svému businessu tak, aby byly flexibilní, efektivní a rychleji reagovaly na změny. Agile v rámci IT je jen částí úspěchu. Aktivní zapojení businessu a agilní strategické řízení firmy je důležité, aby organizace byly schopny efektivně přežít z dlouhodobého hlediska v prostředí, které je obecně globálně rychle se měnící, turbulentní a není tak předvídatelné, jako to bylo v minulosti. Nevěříte? Malá statistika: přibližně 70% společností, které byly v žebříčku Fortune 1000 před 10 lety, z něj zmizelo, nestačily se přizpůsobit změněnému prostředí – digitalizace, všudepřítomný internet, mobilita.

Adaptabilita, flexibilita a vyváženost jsou tři klíčové elementy Business Agility.

Business Agility je organizační změna, která funguje bez ohledu na podstatu businessu, kde organizace působí. Business Agility je vlastně Agilita z pohledu organizace jako celku, je změna kultury a fungování celé organizace, její schopnost se adaptovat, zregenerovat, rychle se změnit na základě vnitřních, ale hlavně vnějších změn. Není to ale žádný chaos, Agilní firma má na rozdíl od mnoha klasických firem velmi jasně definovaný směr. Funguje jako flotila malých lodí, které všechny plují za jedním cílem, ale mají v rámci své mise autonomní řízení. Řízení se stane daleko dynamičtější, než jsme zvyklí z prostředí ročních plánů, iterace businessu se točí v krátkých cyklech, základem všeho jsou samoorganizující se týmy, které samozřejmě obsahují business, přináší inovace a evoluce, ale také změnu leadershipu. Můžete namítnout, že to není nic nového. No není. Je to jen ten stejný Agile přefrázovaný do jiných slov, která jsou více uchopitelná businessem a managementem a má tím pádem potenciál transformovat firmu z úplně jiné strany.

A na závěr, co je opakem Agilní firmy? Firma byrokratická, hierarchická, procesní. Prostě firma s klasickým fixním řízením, pevnými strukturami, kde každá změna musí být schválena na vyšších úrovních a autonomie neexistuje.

Může být banka Agilní?

V podstatě většinou je odpověď že ne. Taková banka má moc peněz a nic ji nenutí se změnit. Proto většina Agilních transformací v bankách končí neúspěchem. Tedy vlastně ani neúspěch to není. Vlastně se jen jaksi vytratí do ztracena a organizace se potichounku polehounku vrátí k původnímu stylu práce. Jedna nejmenovaná velká Americká banka nedávno vyhlásila v pořadí již třináctý pokus (jak někteří mí kolegové spočítali). Budeme jim všichni držet palce, třeba se jim to povede, ostatně 13 není jen tak ledajaké číslo.

Je to ostatně vidět už z dálky. S ohromným humbukem se “začne transformovat“, ale celá Agilní transformace jde jen po povrchu. Na venek se hartusí triby, squady, Scrum of Scrums, devopsem, nebo čímkoli co zrovna frčí jako nablýskaný label, ale v reálu se nic nemění. A tak jak rychle to přišlo, zase to odejde.

Ale jako všude i tady existují vyjímky. Jediná banka, u které jsem viděla kdy reálnou změnu, je DBS v Singapore. Ostatně posuďte sami. Paul Cobban měl na to téma výbornou přednášku na loňské Business Agility konferenci. Nechte se inspirovat tím co v rámci své osmileté agilní cesty dosáhli. A jak k takové Agilní cestě přistupovali (všimněte si, že ji nenazývají transformací ale cestou). Je z toho vidět Agilní mindset. A to bohužel zdaleka není obvyklé.

Klíčem úspěchu byly asi tyto tři body:

  • Pocit urgence (nejhorší banka v regionu)
  • Smysl existence (making banking joyful)
  • Agilní mindset a leadership (Agile je cesta)

Ale protože ty se opakují pořád dokola a nikam nevedou, došlo mi, že to jsou jen vstupní parametry. Takzvané prerequisity, příčina úspěchu je jinde a najdete ji na úplném konci, na posledním slidu. (A teď to video musíte opravdu dokoukat.) Souhlasíte? Bez toho to nepůjde. A právě tohle většině “Agilních transformací“ chybí.

Agilní HR – Strategie a role HR v Agilní firmě

Nedávno jsem psala o Agilním HR. Je to jedno z oddělení, která při Agilní transformaci často zůstávají pozadu. Pokud se ale organizace mění a zavádí se novou kulturu a mindset a směřujeme k moderní Agilní firmě, bez změny přístupu k zaměstnancům se taková změna stejně neobejde. Když je totiž HR dobře vedeno, podporuje všechna ostatní oddělení ve firmě a změna mindsetu je tak výrazně snažší.

Pokud budujeme Agilní HR, je dobré nadefinovat strategii, tak aby byla v souladu s Agilním přístupem. Co by tedy taková strategie mohla obsahovat?

  • Zaměřit se na leadery ve všech úrovních firmy tak, aby fungovali jako koučové a pomáhali ostatním se stát leadery. Věnovat se jejich rozvoji a podpořit je na jejich cestě stát se Agilním leaderem.
  • Podpořit týmovou spolupráci a samoorganizaci v rámci týmu. Dobře fungující tým si dokáže 80 % svých problémů vyřešit sám. Umožněte jim převzít za věci zodpovědnost a dejte jim prostor přijít s novými myšlenkami v rámci sdílené vize a strategie firmy.
  • Vytvořit kreativní prostředí kde podporujeme experimenty a inovace. Posílit pocit bezpečí, protože v prostředí strachu nikdo neexperimentuje a lidi jen zakonzervují status quo.
  • Transparentně komunikovat cíle firmy, otevřeně sdílet informace o aktivitách, které týmy dělají a zapojení lidí do jejich návrhu.
  • Vytvořit platformu pro pravidelný feedback a zapojit do něj všechny úrovně firmy. Podpořit spolupráci se zákazníky uvnitř i vně firmy.
  • Umožnit vznik pracovních skupin takzvaných komunit, které se na dobrovolné bázi věnuji nějaké oblasti a hledají cesty, jak ji zlepšit.
  • Vytvořit systém interního vzdělávání, mentoringu a pair-workingu fokusovaný na všechny úrovně firmy.
  • Oddělit systém platů od pozice. Umožnit lidem, aby se bez ohledu na pozici mohli stát leaderem libovolné iniciativy. Transparentní komunikace a otevřená zpětná vazba od kolegů zajistí, že iniciativy budou smysluplné a přínosem pro firmu.

Strategie Agilního HR představuje novou, vznikající cestu, jak si HR může definovat svoje cíle a roli v Agilní firmě. Nebojte se měnit zaběhnuté status quo, dejte lidem prostor, otevřeně o všem komunikujte a podporujte transparentní přístup na všech úrovních firmy. Ostatně bychom ve výsledku místo Human Resources v Agilní firmě mohli mluvit spíše o Human Relations, co myslíte?

Mimochodem, na stejné téma jsem udělala i video (Agile @ HR) v rámci série Agilní metody řízení projektů.

 

 

Digitalizace a Agilní svět

Jak se postupně mění technologie, tak se mění i svět kolem nás. Zažité postupy, zvyky, styl práce, business. V této souvislosti se mluví o Digitalizaci (Digitalization), která vše změní.

Nebude se jednat o první zlomový moment v moderní historii lidstva. První zásadní zlom nastal s vynálezem parního stroje, kterým začala tzv. velká průmyslová revoluce. Byl to okamžik, kdy se ukázalo, že lidská síla není jediná, která dokáže katalyzovat progres společnosti a měnit ji. Nastal rozmach manufaktur, továren, průmyslu. Další změna nastala s vytvořením globálních sítí elektrického napětí, které umožnily rozvoj technologií a globalizace. Moderní zařízení byla dostupná kdekoli na světě. Dalším zlomem byl vznik počítačů, které opětně změnily zažité postupy – osobní zábavu, komunikaci, organizaci práce. Nyní jsme na prahu další zásadní změny, která přináší digitalizaci.

Digitalizace spojuje dohromady fyzický a digitální svět. A to ve všech průmyslových odvětvích. Vytváří se nové závislosti a vazby, které nikdy neexistovaly a do popředí se dostávají nehmotná data, která se stávají zcela zásadní a cenná. Hezký příklad těchto vazeb ilustruje následující příklad: už dnes počítače generují velká množství dat a mluvíme o Big Data. Data přichází ze všech možných zařízení (dalším buzzwordem,  který se spolu s digitalizací skloňuje je Internet of Things), a oba tyto trendy budou urychlovat rozvoj umělé inteligence a strojového učení, aby Internet of Things dobře fungovalo, a tím se vlastně stane základem a motorem znalostí pro Robotiku, která zpět změní styl práce a pracovní trh. Vše se hezky propojuje. Bavíme se o autonomním řízení, které třeba dnes úspěšně v testovacím provozu používá Google a Uber, o doručení balíčku malým dronem, o službách, které si dnes ani nestihneme představit. Součástí je i veškerá sdílená ekonomika, kterou digitalizace umožnila, jako je Uber a Airbnb. Ale třeba i online nákupy, internetové bankovnictví, a podobně, které v podstatě úplně změnily celý business, chování zákazníků a to, kde vnímají hodnotu.

Některé zmíněné věci nám již plně přešly do krve, jiné považujeme za hodně přitažené za vlasy. To je ale v pořádku, každé nové odvětví má mnoho experimentů, které se ukáží jako slepá větev, nebo se překonají. Kdo ví, možná po čase zjistíme že celá slavná digitalizace byla jen bublina. Ale zatím, digitalizace posiluje důvody pro zavedení Agilních metod, kdy firmy musí ještě rychleji reagovat na změny, zkracují cyklus mezi nápadem a uvedením na trh, zrychlují inovace. V tomto kontextu je vlastně každá firma budoucnosti IT firmou. Co by dnes byla banka bez internetového bankovnictví, Uber, Airbnb nebo Boooking bez mobilních aplikací a Amazon bez eshopu. Digitalizace rozšiřuje klasický core business o IT nejen jako jeho podporu, ale jako centrální klíčovou oblast, bez kterého by nemohly firmy ani jejich služby existovat.

Definition of Done

Přestože Definition of Done (DoD) je velice jednoduchý artefakt Scrumu, spousta týmů s ním zápasí.  V podstatě je to definice toho, co musí splňovat úlohy, abyste je mohli nazvat “hotovými” – tedy “done”. Je to v podstatě takový checklist definující kvalitu, kterou musí všechny úlohy na konci Sprintu splňovat, abychom je mohli považovat za hotové a ukázat je v rámci Sprint Review. Nesplňují-li některé položky Backlogu všechny části Definition of Done, nejsou hotové a musí zpět do Product Backlogu. Primárním smyslem je konzistence. Aby bylo jasné, v jakém stavu dodaný produkt je. Definition of Done vzniká jako dohoda mezi development týmem a Product Ownerem a je stejná pro všechny položky Backlogu. Na rozdíl od Akceptačních kritérií, která jsou u každé položky Backlogu různá, protože jsou funkční specifikací, je Definition of Done stejná pro všechny položky Backlogu abychom věděli, co kvalitativně musí každá funkcionalita splňovat. V dlouhodobém horizontu můžete tuto dohodu mezi týmem a Product Ownerem změnit a Definition of Done rozšířit o další pravidla a celkovou kvalitu produktu tak zvednout, ale rozhodně by se neměla měnit ze Sprintu na Sprint.

Jak taková definition of Done může vypadat?

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Běží na test serveru
  • Akceptováno Product Ownerem

Můžete jí samozřejmě udělat specifičtější:

  • Implementováno podle Product Backlog Item (User Story) definice
  • Automaticky otestováno (unit, functional tests)
  • Review (jiným členem týmu)
  • Dokumentace (interní)
  • Beží na test serveru
  • Akceptováno Product Ownerem

A jak již bylo zmíněno, Definition of Done se vyvíjí a časem zpřísňuje:

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Uživatelská dokumentace
  • Přeloženo do čínštiny, francouzštiny a němčiny
  • Běží na produkci
  • Obsahuje businessové metriky
  • Akceptováno Product Ownerem

V takovém případě jsme v podstatě implementovali Continuous Delivery, neboť jednotlivé funkční celky jsou releasovány na produkci už v průběhu Sprintu kdykoliv je tým dokončí – tedy splní všechny části Definition od Done. Takhle přísnou definition of Done mají týmy, které potřebují získávat zpětnou vazbu od zákazníků v reálném čase a rychle na ni reagovat. Proto businessové metriky, které měří chování zákazníka a porovnávají je s očekáváním jsou nutnou součástí takového prostředí.

Čím Agilnější vaše organizace je, tím přísnější je obvykle Definition of Done. Nezapomeňte ale, že každá Definition of Done je vždy dohodou mezi businessem a týmem a musí tedy odpovídat potřebám vašeho businessu. Přísnější není vždy lepší. 🙂 Žádná nebo slabá Definition of Done na druhou stranu zase vede k chaosu a totální ztrátě předvídatelnosti. A to byste asi nechtěli. Jako vždy v Agilu a Scrumu hledáme balanc, a tak konkrétní podobu Definition of Done musíte sami najít pomocí krátkých experimentů a principu Inspect and Adapt – tedy být Agilní.

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. 🙂