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

Szerző: | 2019. 08. 05. | Agilis szoftverfejlesztés

Olvasási idő:

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

<a href="https://agiluu.hu/author/istvan/" target="_self">Marhefka István</a>

Marhefka István

9 éves koromban kezdtem a programozást, professzionálisan pedig több mint 20 év tapasztalattal rendelkezem szoftvertermékek kifejlesztésében. Jónéhány agilis csapatban dolgoztam különféle szerepkörökben (vezető szoftverfejlesztő, architect, termékfelelős, scrum master stb.), ahol az erős csapatmunkára építve hoztunk létre sikeres termékeket. Dolgoztam magyar KKV-knál, multiknál Magyarországon és Svájcban. Korábbi saját startupom, az amerikai irodát is működtető Be-novative nevű cég, amelyből már exiteltem, a mai napig sikeres. Agilis szervezetfejlesztői és DevOps tanácsadóként 2017 óta dolgozom. Elsősorban hazai kkv-k és nagyvállalatok agilis és digitális transzformációs törekvéseit támogatom.

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!