Agilní projektový management je okouzlující svojí flexibilitou. V zásadě se tolik neliší od základního projektového managementu, jelikož se potýká se stejnými výzvami, ale liší se v přístupu. Začnu definováním důležutých rolí..
Každý projekt musí mít svého vlastníka (“product owner”). Podle autora, vlastník produktu musí úzce spolupracovat se zbytkem týmu a se Scrum Masterem, měl by mít základní technické dovednosti (využívané ve vývoji daného produktu) a hlavně by měl sloužit jako hlavní spojka mezi projektovou skupunou a zakazníky, uživateli, a dalšími stake-holdery.
Agile zavedl tuto roli kvůli problému nesjednocení v klasikém projektovém managementu, který se vyznačuje neustálým předáváním si dokumentace ke schválení, což častokrát doprovázelo, že se odpovědnost za projekt ve velké korporaci úplně vytratila a projekt nikdy nebyl dokončen. Projektový vlastník je proto v agilním přístuju jedinou odpovědnou osobou pro odvedení potřebné práce k dokončení daného projektu. Vlastník je též odpovědný za funkční project backlog, který je nutné neustále aktualizovat a se kterým ostatní musí též pracovat a upravovat ho. Role v sobě kombinuje autoritu k rozhodnutí a také odpovědnost za finální výsledek, ačkoliv je to osoba, která neměla rozhodovat za ostatní, ani uplatňovat přístup laissez-faire. Ideálním způspbem rozhodování je konsensus na všech úrovních projektové skupiny.
Produktovému vlastníku pomáhá takzvaný Scrum Master, který podporuje tým v komunikaci, v řešení problémů, v prioritizaci ale také v dokumentaci. Tato role častokrát plní funkci kouče a dovádí ostatní k pořadovaným výsledkům skrze otázkování. Zatímco je produktový vlastník zainteresovaných hlavně ve výsledcích projektu, Scrum Master se zaobírá hlavně tím, jak využívat Scrum správně a využít agilní metody na maximum.
Ostatní členové projektového týmu by se měli doplňovat navzájem ale rozeveň by měli být schopní se navzájem zastoupit. Správně osazený tým je klíčový pro úspěch projektu a odvíjí se od požadovaných (nebo alespoň primárně očekávaných) výsledcích projektu.
Aby byl projekt agilní, je nutné začít s tou správnou vizí. Ta by měla sjednocovat jednotlivé členy, zároveň by neměla být přiliš konkrétní, aby neubírala možnosti pro kreativitu. Taková vize musí být též dostatečně zajímavá, aby byl zájem na ní pracovat a měla by být zejména co možná nejkratší. Pokud vize neprojde Moorovým testem, je pravděpodobně zbytečně komplexní. Test spočívá v tom, že bychom měli být schopni vizi vysvětlit do 30ti vteřin (tzv. elevator pitch).
Jednoduchost je naprosto klíčová pro agilní přístup, neboť se odvíjí od základního principu rychlích iterací. V agilním řízení je nejdůležitější produkovat inkrementy co nejčastěji, které podléhají následné zpětné vazbě od zákazníků a uživatelů. Z toho důvodu je nutné začínat projekt pouze jen s tím nejnutnějším - s kostrou budoucího produktu, který prozatím nemá předem určenou formu, nicméně měl by mít svůj primární účel.
Vize by se měla specifikovat podle dílčích atributů budoucího produktu, který se snažíme vytvořit. Takových atributů by nemělo být více, než 6, aby se předešlo zbytečné složitosti. Tyto atributy mají odpovídat na nejpalčivější zákaznické potřeby. Jak je zřejmé, v agilním přístupu se uplatňuje umění maximalizace práce, která nemá být udělána.
“People don’t want a quarter-inch drill, they want a quarter-inch hole.”
Na základě těchto potřeb se vytvoří prioritizační řadu, která se konkretizuje a skládá v project backlog, který je DEEP - detailed appropriately, estimated, emergent, prioritised. V praxi to znamená, že na jednom místě uvidíme uspořádané dílčí úkoly, ze kterých bude zřejmé, co je potřeba udělat, pro koho, jaký to přinese benefit, specifikace provedení a estimovaná náročnost. Ve vrchní části backlogu se budou nacházet úkoly s nejvyšší prioritou, to bývají krátké a snadno proveditelné úkoly, úkoly které skrývají velká rizika, nebo úkoly, které jsou podstatné pro oživení projektu.
Jak už jsem zmínila výše, backlog je důležité často aktualizovat na různých schůzkách:
Sprint Planning - stanovení počtu sprintů, délky, prvních cílů, konkretizace prvních úkolů.
Daily Scrum - každodenní schůzky, na kterých se monitoruje progress. měli by se ho účastnit včichni členové týmu, scrum master a v ideálním případě i vlastník produktu.
Sprint Review - mezi jednotlivými sprinty je nutné otestovat nově vytvořený inkrement produktu zákazníky. Na základě jejich zpětné vazby se může produkt dále vylepšovat, což znamná, že je potřeba upravit priority v backlogu.
Sprint Retrospective - Po dokončení projektu je nutné vyhodnotit jak si projektový tým vedl po celou dobu spolupráce, ve jménu učení. V zájmu všech je podat příště ještě lepší výkon.
Všech výše uvedených meetingů by se měli účastnit včichni členové týmu, Scrum Master a v ideálním případě i vlastník produktu. Navíc je nutné stanovit si “the definition of done”, neboli konkrétní specifikace, podle kterých bude jasné posoudit, zda byl úkol opravdu dokončen. Postupný progres projektového týmu se dá průběžne sledovat pomocí Burndown diagramu, za kterého je zřejmé, kolik práce zbývá dokončit do určitého časového úbdobí. Nicméně Sprint Burndown by neměl sloužit pro hodnocení projektové skupiny, jelikož nové uživatelské požadavky vznikají nepředvídatelně a občas mohou na krátký čas zpomalit vývoj produktu. Důležité je vkládat v tým naprostou důvěru a v případě pochyb se prostě zůčastnit jejich Daily Scrum meetingu.
