Na základě úvah byl zvolen přístup, kdy se pole rozsah strategického projektu Česko.Digital rozdělí do tří částí dle cílové skupiny a vzniknou tak tři agilní týmy, které budou na strategickém projektu pracovat vždy se zaměřením na konkrétní cílovou skupinu. Každý agilní tým bude mít svého product ownera, scrum mastera a všechny kompetence potřebné k dosažení cílů stanovených pro tento tým. Některé kompetence nemusí být přítomny v týmu trvale, je možné si je vypůjčit například z jiného týmu, z poolu dobrovolníků, z placených spolupracovníků apod.
Rozdělením strategického projektu na tři části podle cílové skupiny je dosaženo jednak výraznějšího zaměření product ownera a celého agilního týmu na konkrétní cílovou skupinu a za druhé i vyšší přehlednost jak pro projektový tým, tak i pro ostatní pozorovatele. Všechny tyto projekty jsou řízeny v Jiře.
Následuje odkaz na jednotlivé Jira projekty týmů
Tým Masters
Tým Dobro on Board
Tým Engagement
Jako agilní projektová metodika byl zvolen scrum. Výchozí premisou je, že týmy pracující na strategickém projektu mají vždy společné plánovací meetingy. Důvoden je za prvé snaha sdílet znalosti a zkušenosti nabyté během práce na strategickém projektu a dále rovněž potřeba získat a udržet si alespoň vzdálený přehled o tématech, na kterých pracují jiné týmy. Z důvodu společného plánovacího meetingu je třeba tyto meetingy efektivně řídit. Cílem by bylo, aby na těchto schůzkách byl pouze shrnut předchozí sprint a naplánovan sprint následující. Toho je možno dosáhnout pouze tehdy, pokud se tým na plánovací meeting řádně připraví.
Aktivity typu:
rozmyslet si cíle na další sprint
vytvořit a popsat user stories na další sprint
Diskutovat o obsahu user stories
sladit se s jinými projekty, strategickými cíly
by měly být typicky provedeny před plánovacím meetingem, například v rámci backlog groomingu.
Na plánovacím meetingu budou tedy typicky probíhat tyto aktivity:
Vyhodnocení předchozího sprintu.
Rozhodnutí, zda aktivity započaté, ale nedokončené v předchozím sprintu mají být vráceny do product backlogu, nebo zda mají být přesunuty do následujícího sprintu. Toto rozhodnutí činí typicky product owner daného týmu.
Rozhodnutí, s ohledem na počet nedokončených aktivit převzetých z minulého sprintu a dostupné kapacity týmu na strategický projekt, která témata budou naplánována pro sprint následující.
Potvrzení ze strany týmu, že naplánovaný rozsat aktivit (user stories) je pro ně srozumitelné a na základě jejich aktuálního vědomí i zvládnutelný v příštím sprintu.
Další agilní ceremonie jsou již plně v řežii jednotlivých týmů. Doporučuje se obzvláště:
pravidelné stand-up meetingy - 2-5x týdně, dle kapacity týmu. Každý člen týmu podá odpověď na tři otázky: Co jsem dělal včera/od minule? Co budu dělat dnes/do příštího stand-up meetingu? Co mě momentálně blokuje, s čím potřebuji pomoci?
backlog grooming - spoluvytváření obsahu produktového backlogu pod vedením product ownera. Cílem je mít dostatek plně popsaných user stories pro následujících plánovací meeting.
týmové retrospektivy - cílem je ovlivnit budoucnost na základě minulosti. Jak se nám spolu daří a co můžeme udělat pro to, aby se nám spolu dařilo lépe.
interní sprint review meetingy - prezentace dosažených výsledků product ownerovi, například formou schůzky, nebo i asynchronně přes Slack.
Pro účely strategického vyhodnocování bude vytvořen dle potřeby souhrnný pohled na všechny strategické, a případně nějaké dashboardy.
Je-li potřeba v rámci strategického projektu provést změnu v nějakém ze stávajících (interních) projektů, například v Portálu dobrovolníka, či v jakémkoliv jiném projektu, v dalším textu souhrně označeném jako dodávající projekt, doporučuje se následující postup:
Tým strategického projektu si promyslí zadání a vytvoří si v rámci svého projektu user story s popisem změny a akceptačními kritérii.
Takováto user story bude přiřazena jednomu ze členů týmu, který je zodpovědný za její koordinaci s dodávajícím projektem. V dalším textu označíme tuto osobu jako koordinátora user story.
Tato osoba má pak za úkol vykomunikovat s product ownerem dodávajícího projektu zadání user story, její cíle a případně prioritu. Je-li takováto user story product ownerem dodávajícího projektu akceptována, přebírá product owner zodpovědnost za její dodání dle akceptačních kritérií stanovených ve strategickém projektu. V tento okamžik se vytvoří v produktovém backlogu dodávajícího projektu klon této user story a Jira zajistí, že se klon s původní user story prolinkuje.
Dojde-li k situaci, že product owner dodávajícího projektu user story neakceptuje, je potřeba zjistit důvod a následně user story přepracovat, nebo product ownera přemluvit:)
Jakmile je dodávka ukončena, je uzavřen klon user story ve sprint backlogu dodávajícího projektu a zároveň po otestování/převzetí dodávky koordinátorem user story může být uzavřena i původní user story.
