Miért fontos a daily standup? 4 fő kifogás, megoldással

Szerző: | 2019. 08. 05. | Agilis transzformáció az IT-ban

Elég gyakori, hogy a csapattagok nem érzik a daily standup hozzáadott értékét, és csak időfecsérlésnek tartják.

Mike Cohn egy igazi szoftver veterán: a scrum egyik kidolgozója és a Scrum Alliance alapítója is. Számos szakmai könyv szerzőjeként ismeri a világ szakmai közössége. Ő írta a User Stories Applied: For Agile Software Development c. könyvet és az Agile Estimating and Planning c. könyvet is.

A blogján rendszeresen publikál scrummal kapcsolatos praktikákat. Következzék most az ő blogjáról magyarra fordítva egy írása, amely a daily scrummal kapcsolatos kifogásokat oszlatja el.

A daily standuppal szemben felhozott kifogások eloszlatása

Teljes mértékben megértem, hogy egyes csapattagok miért nem szeretnének a napi scrummegbeszéléseken részt venni – én magam sem vagyok oda az értekezletekért -, azonban vannak olyan meetingek, amelyek hasznosak, és megérik a befektetett időt. Ebbe a kategóriába sorolom a jó(l levezetett) napi scrummegbeszéléseket (angolul: daily standup vagy daily scrum).

Ebben a cikkben azt fejtem ki, hogy hogyan kezelem a napi scrumokkal kapcsolatban leggyakrabban felmerülő négy ellenvetést, majd a jó napi scrum ismertetőjegyeire térek rá, hogy senkinek se lehessen kifogása az azokon való részvétellel szemben.

„Így is sokat beszélünk egymással.”

➔ A napi scrum kapcsán az első gyakran hallott ellenvetés az, amikor valaki azt bizonygatja, hogy a csapattagok egyébként is sok mindent megbeszélnek egymással, ezért a napi scrum felesleges időpocsékolás.

Amikor ezt a kifogást hozzák fel nekem, azzal érvelek, hogy bár a csapattagok valóban gyakran beszélnek egymással, de általában nem úgy, hogy mindegyik csapattag jelen van.

A napi scrum pedig pont erre való; sok csapat számára ez az egyetlen alkalom, amikor a csapattagok a teljes csapat előtt tudnak beszélni.

„Csak lényegtelen dolgokról esik szó.”

➔ A napi scrummal szembeni második szokásos ellenvetést olyan csapattagok szokták felhozni, akik úgy érzik, hogy a napi scrumok azért szükségtelenek, mert azokon nem fontos ügyeket beszélnek át.

Elvárások megfogalmazása

Ilyenkor, amikor erre a kifogásra kell felelnem, az az első dolgom, hogy átbeszéljük a kifogást emelő munkatárssal a meetingekkel szemben támasztott észszerű elvárásokat. Nyomatékosan leszögezem, hogy nem mindegyik megbeszélésen merül fel valami őrülten fontos téma, és ez nem is lehet elvárás. Némelyik napi scrum bizony eléggé haszontalannak bizonyulhat; például azok, amelyeken mindenki beszámol az előző napi tisztességesen elvégzett, ámde jelentékenynek nem mondható munkájáról, és az aznapi feladataival kapcsolatban nem merülnek fel problémáik.

Azonban a legtöbb scrum tényleg a csapat hasznára válik… A lényeg pedig az, hogy az a sok napi scrum, ahol fontos dolgok kerülnek megvitatásra, kárpótol a kevésbé gyakori olyan értekezletekért, amelyeken semmilyen fontos dolog nem kerül szóba.

El kell dönteni, hogy a kifogás jogos-e

A második, de az elsőnél fontosabb dolgom akkor, amikor ezzel a kifogással élnek, annak mérlegelése, hogy az indokolt-e. Ugyanis lehet, hogy az. Amennyiben esetleg így lenne, akkor a scrum masternek bizony át kell gondolnia, hogy hogyan tehetné jobbá a meetingeket.

Az ezeken résztvevők ugyanis gyakran esnek többek között abba a hibába — ami miatt jogos lehet ez a kifogás —, hogy eltérnek a tárgytól, a megbeszélést túl hosszúra nyújtják, vagy nem törődnek azzal, hogy a csapatot alkotó munkatársak nem kovácsolódtak össze egy csapattá. Ez az utóbbi probléma akkor szokott előfordulni, ha a „csapat” olyan egyénekből tevődik össze, akik egymástól teljesen független projekteken dolgoznak.

„Nem lehetne ezt e-mailben elintézni?”

➔ Némelyik csapattag nem azt kifogásolja, hogy naponta kell a csapattársaival egyeztetnie, hanem azt, hogy ezt egy meeting keretében kell tennie. A napi scrumok tartása helyett ők azt javasolják, hogy mindenki naponta küldjön a többieknek egy, a személyes megbeszéléseken általában elhangzó kérdéseket taglaló e-mailt.

Ez a tapasztalataim szerint a gyakorlatban nem igazán működik. A legnagyobb gond ezzel az, hogy a legtöbb ember egyszerűen nem olvassa el az e-mailjeit, vagy ha mégis, akkor is csak egy vagy két nappal később, márpedig így a csapat sokkal lassabban fog választ vagy megoldást találni egy kérdésre vagy problémára.

Ezenkívül egy e-mailezés útján lezavart napi scrum az értekezletek szerves részét képező spontán felmerülő kérdések megvitatását egyszerűen lehetetlenné teszi.

Mi a helyzet a Slackkel és a hasonló csoportmunkaeszközökkel? Sejthető, hogy a válaszom ugyanaz lesz, mint az e-mailezés esetében. Ennek ellenére már találkoztam olyan csapattal, amely a Slack segítségével a „személyes” napi scrummegbeszéléssel teljesen egyenértékű megbeszéléseket folytatott le.

Azt viszont nem tudom, hogy ez az ilyen eszközök új voltának vagy az üzenetküldés kontra e-mail alapvető különbségének köszönhető-e. Továbbra sem tartom a legtöbb csapat szempontjából jó megoldásnak lecserélni a napi scrumra jellemző szóban történő megvitatást egy Slack-szerű eszközön való üzengetésre. Ennek ellenére némelyik csapat esetében, főleg a nagymértékben decentralizált projekteken dolgozó csapatok esetében igenis működőképes alternatíva lehet.

„A megbeszélések túl sokáig tartanak.”

➔ A negyedik és egyben utolsó — általam tárgyalandó — kifogás az szokott lenni, hogy az értekezletek túl sokáig tartanak. Természetesen ezt az észrevételt komolyan kell venni, amennyiben az ön által vezetett megbeszélések tényleg hosszabbak szoktak lenni a gyakorlatilag összes scrumszakértő által javasolt 15 percnél.

Viszont ha a napi scrumjai a 15 perces időkorláton belül véget érnek, akkor meglátásom szerint a legjobb válasz erre az ellenvetésre az, ha visszakérdez, hogy a kifogásoló szerint milyen időkorlát lenne az ideális.

Erre minden bizonnyal hasznos választ kaphatunk, különösen akkor, ha belefoglaljuk a kérdésébe a meeting némelyik előnyét. Például így:

„Szerinted naponta mennyi időt kellene arra szánni, hogy mindannyian összehangoljuk a teendőinket, kiküszöböljük a kommunikációs problémákat, betekintést adjunk egymásnak az éppen elvégzendő feladatainkba, felismerjük és kijavítsuk a hibákat, az egymásba vetett bizalmat kiépítsük, és ne feledkezzünk el a sikerélmény fontosságáról sem?”

A napi scrum a csapattagok számára az egyetlen alkalom, amikor a teljes csapat előtt tudnak beszélni.

A jó napi scrum hét jellemzője

➔ A fenti tanácsok segítségével legyőzhetők a csapattagok által a napi scrumokkal szemben felhozott leggyakoribb ellenvetések. De ami még jobb, azokat megfogadva olyan jó meetingeket lehet majd levezetni, hogy a csapattagok hálásak lesznek értük. A jó napi scrum hét ismertetőjegye a következő.

1. A meeting minden nap ugyanott és ugyanakkor kerül megtartásra

E megbeszéléseknek könnyen megvalósíthatónak és teljesíthetőnek kell lenniük, ami a legtöbb csapat számára azt jelenti, hogy azok mindig ugyanabban az időpontban és helyen vannak megtartva.

2. A megbeszélések időben kezdődnek

A pontossághoz való hozzáállásom könyörtelen. Egyszer például le kellett magamat beszélnem arról, hogy felhívjam az orvosomat, amikor úgy számoltam, hogy egy percet késni fogok a megbeszélt időponthoz képest.

De még én is úgy vagyok vele, hogy néhány perc késés egy egész napos ülésről nem olyan nagy ügy. Egy nyolcórás ülésről öt perc késés a teljes ülés 1%-áról való lemaradást jelenti.

Viszont egy napi scrumról való késés már teljesen más tészta. Ha a megbeszélések minden nap öt perccel később kezdődnek, az időben érkező csapattagoknak egy évben összesen 20 órát kell az értekezlet kezdetére várniuk.

3. A megbeszélések nem tartanak tovább 15 percnél

Sok csapat nem véletlenül állómeeting keretében tárgyalja meg a kérdéseket, ugyanis az álldogálás miatt nem feledkezünk meg az időről, így a megbeszélés sem fog túl hosszúra nyúlni.

4. A problémák azonosításra kerülnek, de azok nem a megbeszélés során kerülnek megoldásra

Általános és bevált módszer a kérdéseknek közvetlenül az értekezlet után történő megvitatása (és remélhetőleg ezáltal a rendezése). Ideális esetben a csapatnak csak azon tagjai foglalkoznak egy adott problémával, akiknek a közreműködése szükséges annak megoldásához, a többiek pedig visszaülhetnek az asztalukhoz.

5. A résztvevők mindig a témánál maradnak

A legtöbb csapat ahhoz tartja magát, hogy a napi scrumon mindenki beszámol az utolsó megbeszélés óta elvégzett feladatairól, a következő megbeszélésig elvégzendő feladatairól és a munkájukat esetlegesen megakasztó problémákról. E témákon kívül bármilyen kérdés megvitatását a minimumra kell szorítani.

6. A szabályok betartását az egész csapat fontosnak tartja, nem csak a scrum master

Abban az esetben, ha kizárólag a scrum master törődik a csapat számára a megbeszélések kapcsán meghatározott szabályok követésével, ez azt az érzetet fogja kelteni, hogy azok csak a scrum master kedvéért kerülnek megtartásra. Ez pedig azt fogja eredményezni, hogy egy státuszmeeting jellegét kezdi majd magára ölteni az értekezlet, ahol a résztvevők csak státuszjelentést adnak a scrum master kedvéért.

 7. A teljes csapat, és csakis a csapat tagjai vesznek részt a megbeszélésen

Ideális esetben a csapat valamennyi tagja részt vesz a napi scrumokon. A csapathoz nem tartozó személyek jelenlétét is meg lehet engedni, ám nekik nem szabad beleszólniuk az egyeztetésbe, kivéve akkor, ha az egyik csapattag egy rövid kérdést intéz valamelyikükhöz.

Sok csapat a napi scrum befejezése, de még a résztvevők elvonulása előtt kérdezi meg a csapathoz nem tartozó megfigyelőktől, hogy van-e valamilyen kérdésük vagy hozzáfűznivalójuk. A scrum master vagy az érintett csapattagok ottmaradhatnak, hogy átbeszéljék a felmerülő kérdéseket. A lényeg az, hogy a megfigyelők hozzáfűznivalói ne képezzék a napi scrum részét.

Neked mi a tapasztalatod?

➔ A csapattagok persze a fent összeszedett és általam gyakorinak titulált ellenvetéseken kívül másokat is felhozhatnak. Természetesen a jól levezetett daily standupok az általam fent felsorolt hét lényeges jellemzőnél jóval többel kell bírniuk.

Mi a te tapasztalatod ezzel kapcsolatban? Milyen ellenérveket hallottál eddig, és azokra hogyan reagáltál?

 

Forrás: Mountain Goat Software

Az Agiluu támogatja a szervezeteket, hogy agilisabbá váljanak.

Tetszett az írás? Iratkozz fel a blogra, hogy mindig értesülj az új írásokról!