Tag: Scrum

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 🙂

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

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

Agilní metody řízení projektů – 9. Agilní a Scrum certifikace.

V devátém díle mé video minisérie “Agilní metody řízeni projektů“ se podíváme na Agilní a Scrum certifikace. Na ty, do kterých se vyplatí investovat, pokud chcete na trhu práce zlepšit svojí pozici či plánujete práci v mezinárodním prostředí, anebo vědět, na které se ptát pokud najímáte spolupracovníky do svých Agile a Scrum týmů. Prostě jak říkám jde o Agile a Scrum certifikace, které mají opravdu hodnotu.

Další díl: 10. Zuzana ‘Zuzi’ Šochová.
Předchozí díl: 8. Jak na Agilní transformaci.

Agilní metody řízení projektů – 8. Jak na Agilní transformaci.

V osmém díle mé video minisérie “Agilní metody řízeni projektů“ se zaměřuji na organizaci jako celek. Nebo-li co si představit pod pojmem Agilní transformace, jaké jsou její fáze a jak se firmy transformují na moderní způsoby řízení.

Další díl: 9. Agilní a Scrum certifikace.
Předchozí díl: 7. Agile v marketingu.

Agilní metody řízení projektů – 7. Agile v marketingu.

Sedmý díl mé video minisérie “Agilní metody řízeni projektů“ míří zase jinam a konkrétně na marketing. Marketing je dnes také hodně projektově orientovaný a tak Agile zde má své místo. Dozvíte se tedy, že i marketing může být Agilní. Takže vzhůru na Agile v marketingu.

Další díl: 8. Jak na Agilní transformaci.
Předchozí díl: 6. Agile v HR.

Agilní metody řízení projektů – 6. Agile v HR.

Šestý díl mé video minisérie “Agilní metody řízeni projektů“ se věnuje modernímu HR (Human Resources). Zde se dozvíte, jak na moderní HR a personalistiku, což v mém pojetí znamená Agilní HR. Podíváme se, jak se mění přístup k pozicím, náborům nových zaměstnanců a performance review.

Další díl: 7. Agile v marketingu.
Předchozí díl: 5. Agile v IT.

Agilní metody řízení projektů – 5. Agile v IT.

Pátý díl mé video minisérie “Agilní metody řízeni projektů“ se věnuje IT. Překvapení? Možná trochu jo – Agilní přístup má většina lidí spojen s IT, ale to už dávno neplatí. Business Agility, jeden z buzzwordů co teď hýbe Agilním světem, je toho důkazem. Ale já se zde naopak vracím ke kořenům, kde Agile vznikl. Dozvíte se, jaké jsou praktiky Extreme Programmingu a jak zlepšit práci na IT projektech.

Další díl: 6. Agile v HR.
Předchozí díl: 4. Co je to Kanban?