Inženýrské postupy

• Párové programování se děje často, protože vývojáři vidí vyšší hodnotu v osobní interakci než v pasivní kontrole kódu. Vývojáři aktivně hledají příležitosti a experimentují s jinými formami párování, jako například mob programming.
• Testování a psaní automatických testů je odpovědností celého týmu. Primární zaměření testerů je zlepšit testovací prostředí, psát pokročilé testy (výkonnostní, penetrační, kouřové atd.) a vzdělávat tým o psaní automatizovaných testů a QA kultuře.
• Je zaveden robustní testovací framework pro testování také výkonu, či zátěže. Testování je zabudováno do prostředí CI a je sledováno na změny. Upozornění se generují, když jsou výsledky mimo přijatelný rozsah. Tým shromažďuje metriky o účinnosti svého testování.
• Tým není blokován nikým jiným (například týmem infrastruktury) od dodávání na produkci kdykoli to je potřeba. CI se používá k praktikování continuous delivery a tým experimentuje s jinými postupy ke zlepšení CD, jako je „Infrastruktura jako kód“.
• „Architecture runway“ a technická vize existují jako vodítko pro design a jsou vlastněny týmem.
• Většina refaktoringu se provádí ve vhodném množství při většině uživatelských příběhů.

Klíčové agilní postupy

• Tým využívá standup jako mechanismus Inspect & Adapt a vítá změnu svého plánu, aby v případě potřeby přinesl větší hodnotu. Tým aktivně experimentuje s novými přístupy k standupu.
• Retrospektivy jsou poháněny teamem a každý člen teamu se aktivně účastní. Formát se čas od času liší, aby se zlepšily výsledky.
• Na review může team prokázat přidanou hodnotu a zúčastní se ho všechny důležité zúčastněné strany a sponzoři, protože review je považováno za důležité. Tým měří kvalitu události a zpětnou vazbu, experimentuje s různými způsoby, jak review uspořádat, a měří dopad.
• Počet aktivních iniciativ v oblasti produktu (nápady k prozkoumání, velikost nevyřízených položek, aktivně vyvíjené funkce, analyzované příběhy) je aktivně udržován na nízké úrovni.
• Tým aktivně využívá informace ze sledování pokroku k odvrácení potenciálních problémů a ke zlepšení procesu. Důraz na dodání podle specifikace se posunul k ověřování byznysové hodnoty, takže sledování pokroku se stává méně relevantní.
• Tým také sleduje metriky zaměřené na systém a jeho prostředí, jako je dodací lhůta, kontrola zdraví týmu, počet vydání atd.

Produkt

• Tým experimentuje s novými způsoby, jak rozložit práci a dokumentovat pracovní úkoly. Osobní konverzace je upřednostňována před detailní dokumentací.
• Tým provádí refinement průběžně a s účastí relevantních zúčastněných stran.
• Product Owner má vizi produktu, ověřuje produktové předpoklady a sdílí získané informace se společností.
• Product Owner má proces kolem organizování svého backlogu, např. systém Kanban pro činnosti objevování a vytváření příběhů. Sledují se metriky, jako je trvání doby releasového cyklu a míra úsilí při tvorbě příběhu.
• Existuje agilní roadmapa, je potvrzena / dohodnuta a je veřejně komunikována.

Škálování

• Společnost se aktivně podílí na snižování počtu položek v backlozích. Většina týmů pracujících na stejném produktu sdílí jeden společný backlog.
• Zdrojový kód je sdílen (alespoň pro skupinu závislých týmů) a neexistuje žádné vlastnictví, které by jednotlivce nutilo žádat o povolení k úpravám.
• Týmy úzce spolupracují a snaží se vyhýbat situacím, kde na sebe musí čekat. Dopad na další týmy je zvažován při každém rozhodnutí.

Teamové prostředí

• Tým je organizován bez cizí pomoci, cítí vlastnictví za svou práci i výkon, žije agilními hodnotami a je inspirací pro ostatní.
• Většina týmu je vyškolena na většinu dovedností potřebných v týmu.
• Tým identifikuje a udržuje informační radiátor sám.
• Členové týmu prožívají kulturu důvěry, vzájemně se podporují při překonávání jednotlivých slabin a členové tahají spolu.