Retrospektív meeting – Miért fontos a visszatekintés?

„A fejlődés elkerülhetetlen: egy mozgásban lévő világban ami nem fejlődik, az hanyatlik.” Jorge Ángel Livraga argentin író, költő és filozófus mondása mára már közhellyé vált, de továbbra is érvényes. Folyamatos mozgásban lévő világunkban természetesen az üzleti világ is folyamatos mozgásban van, ezért a fejlődés érdekében tett erőfeszítés elengedhetetlen fontosságú. A fejlődés egyik legkézenfekvőbb eszköze a múlt tapasztalatain alapuló változtatás. Ez nem új felismerés, az agilitás előtt született módszertanok is tisztában voltak ezzel és számos megoldást, technikát adtak ennek megvalósítására (pl.: lessons learned meetingek, post-mortem meetingek), melyek a retrospektív meeting őseinek is tekinthetőek. Az agilitás két lényeges változást hozott a korábbi megközelítésekhez képest: növelte a múltból való tanulás gyakoriságát és csökkentette a léptékét. Megbízhatóbb, tartósabb fejlődés érhető el gyakori, de kisebb, mint ritka, de nagy változtatásokkal. Ahogy az Agilis Kiáltvány tizenkettedik alapelve fogalmaz: „A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja az működését.”

Miért fontos a visszatekintés?

A visszatekintés nem fontos. Pontosabban nem önmagában, nem önmagáért fontos

A fenti kérdést gyakran megkapjuk tréningeken, tanácsadási alkalmakkor, de nem szerencsés kérdés. Gyakori gondolkodási hiba áll mögötte, a célok és eszközök összetévesztése. A visszatekintő megbeszélés nem cél, csak eszköz, ezért nem önmagában fontos. Mint egy svájci bicska, ha jól használjuk, számos különböző cél eléréséhez nagyban hozzá tudja segíteni mind a csapatot, mind a szervezetet.

A retrospektív hivatalos célja természetesen a fejlődés: a csapat rendszeresen kiértékeli saját működési módját, az elmúlt iteráció (sprint) tapasztalatait, levonja ezekből a tanulságokat, és, ahogy a Scrum Útmutató legfrissebb, 2020-as verziója fogalmaz: „minőség‐ és eredményességnövelő módszereket tervez”, ezzel javítva mind a saját működését, mind az általuk készített terméket.

A jó visszatekintő meetingek nagyban elősegítik, felgyorsítják a csapat valódi csapattá válását a közös célok folyamatos hangsúlyozása, és a közös megoldások keresése által. Ehhez természetesen kulcsszó a „jó”, egy rosszul vezetett visszatekintés könnyen ellentétes hatást érhet el, vádaskodássá, bűnbakkereséssé fajulhat.

Bár mellékhatásnak is tekinthetnénk, érdemesebb célként tekinteni rá: a jó retrospektív nagyban növeli a csapat és a csapattagok motivációját. Dan Pink Motiváció 3.0 elmélete szerint a motiváció egyik alappillére az autonómia. A sikeres retrospektív feltétele, hogy a csapat valóban szabad kezet kapjon a saját működése, saját módszerei definiálásában, természetesen meghatározott keretek között, a szervezet többi részével való együttműködést nem veszélyeztetve.

A retrospektív a szervezet fejlesztésének eszköze is, hiszen, bár a visszatekintés fő fókusza mindig az adott csapat terméke és az adott csapat működése, gyakorta felmerülnek olyan, akár a hatékonyságot, akár a minőségjavítást akadályozó tényezők, melyek a csapat hatáskörén kívül esnek. Ezek megfelelő jelzésével a csapat a teljes szervezet fejlesztését serkentheti.

Ezzel párhuzamosan, ahogy a csapat fejlődik, ahogy nő a hatékonysága, úgy kénytelenek fejlődni a velük együttműködő egyéb szervezeti egységek is, különben egy idő után ők maguk válnak a fejlődés akadályaivá. Komplex üzleti termékek fejlesztésekor például nem ritka, hogy egy idő után a szoftverfejlesztő csapat annyira felgyorsul, hogy lehagyja az üzleti tervezéssel foglalkozókat, akik, ha nem akarják, hogy a fejlesztőcsapat tétlenül üldögéljen, kénytelenek maguk is növelni a hatékonyságukon.

A fentiek miatt a retrospektív egyben egy érzékeny műszer is, ami megmutatja, mennyire komoly a szervezet elköteleződése az agilitás iránt. Csak akkor várhatunk el fejlődést, ha a csapat valóban közös célokért dolgozik, ha megfelelő szintű autonómiájuk van, és ha a szervezet csapaton kívüli része támogatja, segíti őket, és maga is kész a fejlődésre.

Milyen gyakran tartsunk visszatekintést, retrospektív meetinget?

A Scrum Guide javaslata szerint minden sprint végén. Ez a javaslat egyszerre jelent gyakoriságot és rendszerességet. A rendszeresség azért fontos, mert a sprint meetingjeinek előre meghatározott, kiszámítható ütemezése egyrészt meghatározza a csapat bioritmusát is, másrészt a mérhetőség és a hosszú távú tervezés alapjául is szolgál. A gyakoriság pedig, a bevezetőben jelzett inkább gyakran, kicsit, mint ritkán, de nagyot elv mellett egyszerű emberi okokkal is magyarázható: az emlékezetünk véges. Minél ritkább a visszatekintés, annál homályosabbak az emlékek a vizsgált időszak elejéről. Amire nem emlékszünk, abból viszont nem tudunk tanulni.

A legjobb csapat életében is előfordulhatnak olyan időszakok, amikor a retrospektív meeting által igényelt egy-másfél óra fájdalmasan drágának tűnik. Például a cég az olimpia előtt két hónappal váratlanul megnyeri a nyitóünnepség pirotechnikáját és szökőkutait irányító rendszer szállítására kiírt pályázatot. A munka sok, a nyitóünnepség biztos nem kerül elhalasztásra, bele kell húzni, a csapat sajnos még túlórázni is kénytelen. Jó Scrum Masterként ilyenkor nem a módszertani keretek merev kikényszerítése, hanem a kreatív megoldások megtalálása a feladat. Intezív időszakban azonban a fejlődés is még fontosabbá válik. Minél inkább pörög a csapat, annál kevesebb ideje van megállni, levegőt venni és gondolkodni. Minél inkább szorít a határidő, egy jó ötlet annál többet spórolhat. Ilyen esetekre ezért azt szoktuk javasolni, hogy a formális retrospektív meetinget váltsuk ki egy közös ebéddel, ami közben átbeszéljük az elmúlt sprint tapasztalatait is.

Bár nem minden sprint végén, de nagyobb szervezetekben érdemes időnként a csapatnál magasabb szinten (termékszinten, projektszinten, stb.) közös retrospektívet tartani, annak érdekében, hogy az egyes kis csapatok ne csak önmagukban, de közösen is egyre hatékonyabbak legyenek. Ennek a gyakorisága leginkább attól függ, mennyire szorosan kell összedolgozniuk az egyes csapatoknak.

Hogyan lehet a visszatekintésből tanulni?

Érdemes megfigyelni, hogy sem az Agilis kiáltvány, sem a Scrum Útmutató nem a tanulni igét, hanem a hangolni, illeszteni, tervezni igéket használja. Ennek oka valószínűleg az, hogy a tanulás önmagában nem ígér változást, könnyen passzív tudássá is fakulhat. A retrospektív célja az aktív fejlődés, a tanulás ilyen módon tehát cselekvésen keresztül történik. Vagy a korábbi sprintben akár spontán ötletként felmerült sikeres megoldások azonosításával és rendszeresítésével, vagy akár kísérletezéssel. A már említett „gyakran, kicsit” elv egyik nagy előnye a „ritkán, nagyot” hozzáállással szemben az, hogy megengedi a tévesztést. Az a csapat, amelyik évente határoz meg szándéka szerint előremutató változtatásokat, nagyon sokat bukik, ha ezek a változtatások nem bizonyulnak sikeresnek. Ha a csapat kéthetente fejleszt a működésén, abba kényelmesen belefér az, hogy egyes ötletekről kiderüljön, mégsem válnak be. A kísérletezés nemcsak megengedett, hanem egyben javasolt módja is a retrospektíven feltárt problémák kezelésének: ha a csapat nem tud megoldani egy problémát, már az is érték, ha részmegoldásokat talál, vagy akár csak olyan kísérleteket tud azonosítani, amik segíhetnek a probléma kezelésében.

Mit ismételjünk?

Egyetlen dolog van, aminek az ismétlése elengedhetetlen a visszatekintés során, maga a visszatekintés. A rendszeres és gyakori, tehát minden sprint végén megtartott retrospektív meeting. Minden mást: a retrospektív formáját, menetét, technikáját lehet, sőt, érdemes is változtatni. A visszatekintő megbeszélés egyik leggyakoribb buktatója, hogy elfárad, rutinszerűvé válik és emiatt egyre kevesebb ötlet születik. Ennek kivédésére fontos, hogy a Scrum Master folyamatosan új technikákat keressen, amikkel arra serkenti a csapatot, hogy mindig más és más szemszögből tudjanak a működésükre tekinteni. Természetesen nincs szükség minden sprint végén új technika bevetésére, de amint úgy tűnik, hogy az adott megközelítés fáradni kezd, eljött a változtatás ideje. Hogy mennyire igaz az, hogy a rendszerességen és gyakoriságon kívül (természetesen a résztvevők kölcsönös tiszteletén túl) semmi mást nem érdemes kőbe vésni, jól mutatja az is, hogy bár az esemény neve retrospektív, azaz visszatekintés, olykor, például egy nagyobb fejlesztés elején érdemes a múlt helyett a jövőbe tekinteni, és bevetni egy futurespective technikát.