Zavádět agilní metody ve velké korporaci je těžší. Přinejmenším musíte pro agilní přístup nadchnout větší množství lidí, což dá více práce. V podstatě máte dvě možnosti. Buď svoláte velký meeting a na něm oznámíte, že od teď je vaše firma agilní a vše tlačíte silou, nebo budete agilní metody stavět od jednotlivých týmů a necháte lidi, aby si sami vybrali, jakou metodikou projekty chtějí řídit. Ze zkušenosti se dá říct, že fungují oba přístupy, což ale neříká, že oba budou fungovat pro každou firmu. Nakonec stejně časem zvolíte jistý mix obou krajních variant. Příkaz a rychlou změnu celé organizace na agilní si asi můžete dovolit, jen když jste si sami jisti výrazným přínosem takové změny a také když víte jak. Většina firmem si ale přechod na agilní organizaci moc představit neumí, takže začíná spíše opatrně.
Asi ideální je zlatý střed. Vybrat produkt, který bychom zkusili řídit agilně, najít vhodného Product Ownera a Scrum Mastera, vyčlenit ze standardní organizace vývojáře, analytiky a testery které plně alokujeme do pilotního Scrum týmu. Vyplatí se vysvětlit jim v 1-2 denním workshopu jak fungují agilní metody, na čem stojí, že je to spíše filosofie a změna myšlení než striktní proces. Aby to nebyla jen teorie, ale věděli i proč jednotlivé praktiky děláme. Když se tým již od počátku zapojí do vytváření Scrum procesu, přijde si sám na to jak proces adaptovat na své podmínky.
Když je i tohle pro vás nepředstavitelné, dosáhli jste správné úrovně klasického korporátu. Je zajímavé, že i drobná agilní změna zanesená do vašeho zaběhnutého systému může přinést ohromné výsledky. Většině týmů schází napojení na business, a protože pro ně není ze začátku snadné v korporaci udělat stabilní Scrum tým se vším všudy, začne standupy. Na začátek tam chodí jen členové IT týmu. I to je přínosné. Když se tým zaběhne, začne jim víc a víc vadit, že nemají přístup k nikomu za business a že zástupci businessu se standupů neúčastní. Tak je pozvou a oni po větším či menším protestování že na to nemají čas, začnou chodit. Obvykle je ale standup rozvleklý a technicky orientovaný, takže to naše zástupce businessu moc nebaví a brblají, že je to pro ně ztráta času. Z tohoto stavu obvykle vedou dvě změny. Vizualizovat lépe stav práce na přehledné tabuli a připomenout že standup je hlavně o commitmentu, tedy o tom co se dokončilo. A abychom mohli mít commitment kterému business rozumí, je dobře dělit práci na nějaké funkční celky které za nějaké fixní období – tedy Sprint dokončíme. Co se udělá, by se měl domluvit tým s businessem a ne si o tom rozhodovat sám jako doposud.
Je zajímavé, že i takováhle agilní ochutnávka stačí k tomu, aby tým začal fungovat výrazně lépe a vzbudilo to v jeho členech chuť zkusit další věci. Sami se ptají jak že se to ve Scrumu plánuje, jak se ohodnocuje, co je to UserStory, začnou dělat retrospektivu, hledat rovnováhu mezi tradičními projektovými funkcemi a nově definovaným rolemi a zkoušejí si, jak by Scrum v jejich prostředí mohl vypadat. Po nějakém čase je v organizaci dostatečně positivní atmosféra pro postavení plného pilotního Scrum týmu. A to je následně začátek přerodu v agilní organizaci.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Dobrý den.
Nechci svým komentářem nijak pobuřovat, ani hanět. Jsem student pátého ročníku ekonomického oboru. Právě zpracovávám práci na téma inovace – agilní řízení v oblasti ERP systémů.
Měj jsem na vlastní kůži možnost, setkat se s několika modely řízení i přechody mezi jednotlivými.
V článku jsou zmiňovány dvě možnosti přerodu organizace na agilní. Tou první je, že svoláte meeting – bum a firma je agilní. No tak podobně to jednoznačně nejde. Jakémusi meetingu musí nutně předcházet důsledné mapování vnitropodnikových procesů a na základě nich je nutno stanovit cíle, kterých chceme díky agile dosáhnout, ale to je všechno otázka přístupů, které by měly být použity…
DŮLEŽITÉ!!!
Z mého průzkumu v rámci diplomové práce vyvozuji následující závěry. Naprosto ideálním stavem pro přechod na agile je malá organizace, kde doposud skvěle fungoval vodopád a již není možné, aby se konkrétní pracovníci vyznali ve všem a řídili vše. Když tedy přichází noví lidé do firmy, berou agile jako samozřejmost!!! Tito lidé si uvědomují možnost, jako delegovat velkou část tlaku, který cítí na svých bedrech na své týmy, které nebudou podřízenými, ale budou se cítit jako rovnocenný partner. Zde je to ale jako s dítětem. Jakmile mu jednou něco dovolíte, bude to příště samozřejmost. TO ZNAMENÁ, NIKDY ANI V NEJMENŠÍM NÁVRAT K VODOPÁDU. Jinak je vše ztraceno a na agile si jen hrajete, což je dle mého klidně 70 % všech českých firem. Budou Vám tvrdit: “Ano, používáme agilní metody.” Ale už tak nějak zapomenou, že když něco spěchá (znáte to), šéf se zvedne ze židle a jde tým rozbombardovat.
Budu rád, když na toto téma uslyším více názorů, především od těch, kteří jsou členy týmů, ideálně CORE.
Marek Vejrsota
PS: Děkuji za prostor vyjádřit vlastní názor a tak trošku rozhořčení nad aplikací agilních metod u nás. Blog je skvělý, dělejte ho prosím dál!
Ja bych jen polemizovala s tim ze male firky jsou idelani. Jen ty problemy jsou obvykle skryty jinde. A to “jinde” se v takovem pripade jmenuje vetsinou majitel, ktery nic memit nechca, ani delegovat nechce a vznik zmeny na agile tak ani neumozni. Ale tech duvodu proc to ve firmach nejde je milion… kazda si najde svuj. To nejdulezitejsi pak je ze firma asi ani nechce, nema proc. A kdyz je spokojena s tim jak a co dela, tak proc to menit 🙂
Zdravim.
Jsem rad, ze zde zaznela slova o velke dulezitosti KOMUNIKACE. Ta je dulezita VSUDE, pro “klasicky” i “agilni” vyvoj. Z mych zkusenosti v roli PM vim, ze chyby, nedostatek komunikace je pricinou vice nez 80% potizi v projektu a tymova prace je VZDY nutna.
Trochu mi vadi pohled autorky, jak jej chapu ja, ze AGILNI je super a vse muze zachranit a nic jineho na poradny projekt vlastne nelze pouzit…
Jak to vidite vy? Jake mate zkusenosti s vodopadem a s agilnim vyvojem? Setkali jste se s vyvojem na 100% vodopadovym?
Tesim se na reakce… a drzim palce s osvetou.
Agile neni ani sekta, ani zazracna pilulka kterou snite a problemy zmizi…. Skoda, svet by byl o mnoho jednodussi 🙂