💻 Technická agilita pro netechnické Scrum Mastery
🤯 Zrovna dokončuju zpětné vazby na jedno zamýšlecí cvičení, které dělali účastníci aktuálního běhu Agile Master Class.
👉 Každému namlouvám zhruba čtvrthodinovou zprávu 💭, abych dokázala dobře vypíchnout, kde vidím mindsetově silné opěrné body 👍, na kterých mohou v praxi stavět, a které věci potřebujeme v následujících týdnech ještě intenzivněji zvědomovat 👀
Věc, která se objevuje pravidelně napříč všemi běhy? 🤔
❌ Nezvědoměná důležitost technické agility.
Zapomínají ji zmiňovat zejména Scrum Masteři s netechnickým backroundem.
A chápu to - když nerozumíme technickým věcem, může nám připadat, že tohle si tým ošéfuje sám a my se budeme zaměřovat na sluníčkové vztahy ❤️
❗Jenže jako Scrum Masteři tu nejsme od toho, aby se lidé drželi za ruce - jsme tu od toho, aby byla firma díky agilnímu fungování konkurenceschopná a dlouhodobě životaschopná 💪
A pokud týmu trvá násobně dýl, než něco vytvoří, než něco předělá, než něco otestuje nebo než něco vydá, oproti tomu, jak by to mohlo být, kdyby byla řádně poladěná technická agilita, pak je úplně jedno, jak moc happy se při tom všichni cítí - firmě lítají peníze oknem 😩💸🪟
A úplně zbytečně 🙈
➡️ Takže abych to shrnula: technický dluh, nevyhovující architektura kódu, absence automatizovaných testů nebo možnost rychlého průběžného vydávání do produkce, nejsou jen věcí vývojářů - jsou to reálné překážky agility, které mohou dramaticky ovlivnit rychlost a kvalitu doručování. Tudíž i váš píseček 🙂
Ale nebojte se! 🤗 Nemusíte umět programovat, abyste jako Scrum Master mohli efektivně podporovat technickou agilitu svého týmu. Stačí porozumět základním konceptům, které ovlivňují práci vývojářů - a to je přesně to, na co se dnes zaměříme! 🚀
💡 V tomto vydání získáte:
Porozumění, proč je technická agilita tolik důležitá
Pochopení základních pojmů ze světa softwarového vývoje
Seznámení s XP praktikami
Jak tohle všechno do týmu nebo firmy dostat
🍰 Vícevrstevná agilita
Pojďme si na začátek připomenout, že agilita je vícevrstevná:
🛠️ Operační úroveň: toto je základní rovina, kterou si většina lidí vybaví, když se řekne "agile". Jde o to, jak řídíme procesy, jak organizujeme práci v týmech, jakou máme firemní kulturu, jak definujeme role a odpovědnosti.
🎁 Produktová úroveň: jak řídíme produkt, jak děláme discovery proces a jak přistupujeme k zákazníkovi/uživateli - zda dokážeme postupně a v brzkých stádiích dodávat produkt nebo jeho inkrementy, které dodávají reálnou hodnotu.
🚀 Strategická úroveň: jak přistupujeme k inovacím a jak zajišťujeme dlouhodobou konkurenceschopnost firmy - snažíme pochopit, jaké problémy budou naši zákazníci nebo trh v budoucnu řešit a na základě toho inovujeme a upravujeme náš byznys.
👨👩👧👦 Leadershipová úroveň: jakým způsobem přistupujeme k vedení lidí. Jsme Servant lídři? Podporujeme týmy v samo-organizaci a k E2E fungování? Sdílíme informace transparentně? Umožňujeme týmům fungovat skutečně agilně?
💻 Technická úroveň: jakým způsobem přistupujeme k architektuře softwaru, k psaní kódu, k testování, k releasování, k digitalizaci, automatizaci, apod.A technická agilita není jen o používání cool nástrojů - je to o tom, jak rychle a bezpečně může tým reagovat na změny.
➡️ Vzhledem k tomu, že dnes je to právě o této 5. vrstvě, pojďme si ukázat některé možné důsledky slabé technické agility:
🐌 Pomalé doručování nových funkcí
🐞 Více chyb a větší nestabilita
🧯 Více času stráveného hašením požárů
👨👩👧👦 Mnohem více potřebných zaměstnanců, aby se to celé udrželo v chodu
😫 Frustrace na všech stranách
☝️ A teď ta dobrá zpráva: jako Scrum Master můžete hrát klíčovou roli v budování technické agility, i když neumíte napsat jediný řádek kódu! Jen je důležité, abyste rozuměli základním principům technické agility a dokázali je do týmu přinést 🙋♀️
🤔 Rozumíte, o čem se baví vaši vývojáři?
Hele, já sama jsem netechnický Scrum Master. Můj backround je psychologický a sociální 🫂
Když jsem ve svých 30 letech poprvé překročila práh softwarového týmu, přísahám bohu, že jsem neznala každé třetí slovo, které lidé v té firmě vypouštěli z pusy 🙊
Tehdy jsem si musela dělat slovník 📕, abych se jednotlivé pojmy naučila.
🤷♀️ Ale jedna věc je rozumět významu, a druhá pak chápat jejich podstatu.
Proto máme jakou součást Agile Master Class i vysvětlení vývojářských věcí - nejčastějších pojmů a postupů, které můžete v praxi Scrum Mastera v softwarovém týmu zaznamenat.
Do kurzu hlásí i lidé, kteří jsou dosud IT světem nepolíbení, a já cítím povinnost vybavit je i těmito znalostmi, aby následně v praxi netápali a o to rychleji se dokázali i bez předchozí praxe zaběhnout, kdyby by se v budoucnu do softwarového týmu nebo firmy dostali.
➡️ Výhodou pro vás tedy je, že jsou všechny pojmy vysvětleny absolutně lidskou řečí, za použití analogií, které znáte z běžného života 👉 pokud máte půl hodinky a chcete konečně porozumět, o čem se vaši vývojáři (nebo partneři doma 😀) baví, mrkněte na toto video:
Na video se kdyžtak můžete podívat i na tomto odkaze.
🤯 Extreme Programming (XP) není extrémní!
Tedy…v době svého vzniku byl. Ale dnes z hlediska praktik XP (vynechávám teď kompletní framework jako takový) už by se mělo jednat o zcela přirozenou součást fungování agilního týmu!!!
☝️ A pozor - nejenom toho softwarového!
➡️ Původní XP praktiky sice vznikly v programátorském prostředí, ale drtivá většina z nich se dá abstrahovat i do jakýchkoliv jiných agilně fungujících týmů - klidně i na HR! ❤️
❗Jako Scrum Master je potřebujete znát stejně intenzivně jako 12 agilních principů, zcela nehledě na to, v jakém frameworku zrovna s týmem jedete - XP praktiky, nebo přinejmenším část z nich, potřebujete využívat nejen v Extreme Programmingu, ale i ve Scrumu, Kanbanu, Scrumbanu, Lean Startupu i v “nejedemepodleframeworku” agilním prostředí.
Nejprve si je ukažme:
(pokud se vám obrázek zobrazí ve špatné kvalitě, stáhněte si ho ve full rozlišení TADY)
🦉 A proč byste je měli znát?
Abyste dokázali být poslední záchrannou instancí, která je pomůže do týmu dostat, pokud jsou tyto praktiky pro váš tým dosud neznámá věc, nebo jim to přijde jako příliš složitá záležitost na zavedení 🤔
🙈 Jak mám ale tohle všechno do týmu dostat?
V první řadě malá připomínka: i agilnější způsob fungování zavádíme agilně 🙂☝️
1️⃣ Stavíme na reálné potřebě / problému týmu (který i ten tým vnímá jako problém!)
Slyším často o tom, jak je štve, že je každou chvíli nějaké prostředí rozbité?
Že jim vzájemná integrace před releasem zabere obrovské množství času a je to pain?
Že musí čekat dlouhou dobu než si můžou otestovat, jak se jimi provedená změna projeví?
Že je frustrující, jak každá oprava znamená rozbití kódu na třech dalších místech?
Že strašně dlouho trvá, než QA všechno otestují?
Že i malý požadavek od zákazníka znamená několik dní práce celého týmu?
Mám data, která ukazují, že máme někde zásadní bottleneck, který všem způsobuje potíže a jehož odstranění by nás zásadně posunulo?
👉 Výborně - půda pro zlepšení je zasetá! 🤩
2️⃣ Najdeme způsob, jak tým s praktikou/praktikami, které by mohly tuhle věc adresovat, v bezpečném prostředí nenásilně seznámit.
🙋♀️ Já jsem například využila pravidelných pátečních poobědových sedánků s týmem, kde jsme měli vyhrazenou půlhodinku na vzájemný knowledge sharing. Udělala jsem prezentaci (třeba o CI/CD, o Mobování, apod.), kde jsem celý koncept high-level vysvětlila a pak jsme se s týmem bavili o tom, co by jim dávalo/nedávalo smysl, co by to řešilo, jaké další kroky by to obnášelo, a případně jsme se rovnou domluvili na načasování prvního experimentu se zavedením této praktiky.
🙋♀️ Jindy jsem třeba zas domluvila praktický workshop, kde si tým v bezpečném simulačním prostředí pod dohledem zkušeného lektora mohl vyzkoušet psaní unit testů v kombinaci s párovým programováním, které jsme chtěli do týmu zavést. Na konci jsme si udělali podobně laděný debrief.
3️⃣ Pokud je tomu tým nakloněn, navrhneme empirické ověření v praxi
👉 Malý experiment, pomocí kterého si můžeme ověřit, zda a jak konkrétně nám tohle řešení pomůže s naším problémem, a co to pro nás vlastně v praxi bude všechno znamenat.
🙋♀️ Můj postup viz výše 👆
4️⃣ Vyhodnotíme experiment a domluvíme se na dalším kroku/krocích
🙋♀️ Během retrospektiv jsme se pravidelně vraceli k vyhodnocování toho, jak to jde, co to ve skutečnosti nakonec přineslo, ladili jsme další kroky, nebo jsme se rozhodli, že to nakonec nezavedeme, nebo jsme si stanovili pravidla, za jakých podmínek ano a za jakých ne, apod.
❗Všimněte si, že jsem tomu vlastně vůbec nemusela rozumět. Mým úkolem bylo tu myšlenku do týmu vůbec přinést 🌱, dokázat to v hlavách lidí propojit s řešením jejich potřeb/problému 🔗, dát týmu šanci si to v bezpečném prostředí nějakým způsobem osahat 🖐️a pokusit se to následně postupnými kroky do týmu zavést🪜, pokud s tím byl tým ok.
Takže pořád dělám to, co Scrum Master dělá - jsem change agent 🕵️♂️ Ne encyklopedie 😉
5️⃣ Postupně sdílíme zkušenosti s dalšími týmy napříč celou firmou a zavádění podobným způsobem škálujeme na větší systém
💡Dá se pro to využít nějaká platforma pro sdílení napříč firmou: prezentace na pravidelných technických sedánkách, návštěva ve vhodných communities of practice (guilda, chapter), celofiremní retrospektivy, video poslané přes interní newsletter, webinář, younameit…
🧙♂️ Chcete vědět, co všechno se v AMC ještě učíme?
👉 Tohle všechno 🎓
Brány do podzimního běhu 🍁 jsou již otevřeny! 🌈
❗Do konce dubna je přihlášení za sníženou early bird cenu 🐣, poté už za plnou palbu 🙂
Těším se, že se tam na podzim uvidíme!
Váš #️⃣Agilefluencer,
Hanka Jadavan ❤️
