Daily standup in 3 vprašanja
DAILY STANDUP IN 3 VPRAŠANJA

Mnogo razvojnih timov ne prakticira Daily Standup oz. Daily Scrum. Do zavračanja praviloma pride zaradi nerazumevanja funkcije dogodka in njegovih napačnih izvedb. Posledica je prepričanje, da je Daily Scrum zapravljanje časa – in v takšnih okoliščinah pogosto tudi je.

Daily standup in 3 vprašanja

Po zadnjem Scrum Guide (2020) je namen Daily Scruma, citiram:

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

“Slavna” tri vprašanja, ki jih mnogi enačijo z Daily Scrumom, se v Scrum Guide, kot pravilo ne pojavljajo že od revizije leta 2017, ko so bila predstavljena samo še kot predlog. V Scrum Guide 2020 pa sploh niso več omenjena.

|

Standardni format

Običajna oblika treh vprašanj na katera razvojniki odgovorijo na Daily Scrum je:

  • Kaj sem počel/a od prejšnjega Daily Scruma?
  • Kaj planiram početi danes?
  • Kaj me ovira pri napredku?

Vprašanja v takšni obliki resnično zvenijo kot izhodišče za status report, kar nikakor ni namen Daily Scruma.

Še posebej prvo vprašanje lahko v napačnem kontekstu degenerira v “opravičevanje lastnega obstoja“. Ko razvojniki začnejo tekmovati v tem, kdo bo svoje delo prikazal v lepši luči, težava ni v Daily Scrumu, ampak v organizacijski dinamiki. Organizacijsko vzdušje mora omogočati, da lahko razvojnik brez zadrege pove, da ni napredoval proti cilju Sprinta. In to ne samo na enem, ampak na več zaporednih Daily Scrumih. Od ostalih razvojnikov se pričakuje, da (če je to v njihovi moči) razvojniku s težavo (3 vprašanje) po Daily Scrum dogodku ponudijo pomoč. Zakaj po Daily Scrum? Reševanje omenjene blokade je specifična razprava, pri kateri ne morejo konstruktivno sodelovati vsi člani teama in bi bila njihova prisotnost na razpravi zanje izguba časa.

Daily Scrum in 3 vprašanja

Izboljšana tri vprašanja

Prvi predlog za izboljšanje dinamike Daily Scruma, je da teami uporabljajo polno besedilo vprašanj, kot so bila nazadnje predstavljena leta 2017 in ne njihovih skrajšanih verzij.

Polna verzija vprašanj se glasi:

  • Kaj sem počel/a od prejšnjega Daily Scruma, da sem timu pomagal/a napredovati proti cilju Sprinta?
  • Kaj planiram početi danes, da bom timu pomagal/a napredovati proti cilju Sprinta?
  • Kaj me ovira pri napredku, proti cilju Sprinta?

Razlika je referenca na cilj Sprinta. Ostalih razvojnikov ne zanima poročilo o sestankih in izobraževanjih na katerih ste bili včeraj. Relevantne so samo aktivnosti, ki so team približale cilju trenutnega Sprinta. Tako formirana vprašanja razvojnikom pomagajo, da se fokusirajo na poslovni namen Sprinta (Sprint Goal).

Daily Scrum KPIji

“Daily Scrum je mehanizem za zmanjševanje koordinacijskih stroškov, ne za nadzor dela.”

V duhu zgornje trditve lahko Daily Scrum razkrije:

  • blokade med člani teama
  • čakanje na odobritve
  • odvisnosti od drugih teamov
  • potrebo po dodatni ekspertizi

Tudi Daily Scrum ima svoje KPIje, ki jih tim lahko meri, če se razmišlja o spremembi formata ali celo ukinitvi dogodka. V tem primeru, razvojni tim pred in po spremembi meri naslednje KPIje:

  • Število zaznanih blokad na Sprint (3 vprašanje).
  • Povprečni čas od zaznave do rešitve zaznanih blokad.
  • Stabilnost Sprinta. To je število spremenjenih/dodanih/zamenjanih/umaknjenih uporabniških zgodb deljeno s skupnim številom zgodb prevzetih v Sprint.
  • Delež Sprintov, ko team doseže cilj Sprinta.
  • Število koordinacijskih napak na Sprint. To število naj bi učinkovit Daily Scrum zmanjševal.
    Par primerov koordinacijskih napak, ki bi jih lahko šteli med sprintom:
      • dva razvojnika nevede delata isto stvar
      • uporabniška zgodba obstane na task boardu, ker ni jasno, kdo kaj prevzame
      • razvoj je končan, testerji pa niso vedeli, da je zgodba pripravljena na prevzem v testiranje
      • nepredvidena odvisnost od drugega razvojnega tima
      • uporabniška zgodba je šla v razvoj z napačno verzijo acceptance kriterijev
      • integracija ni uspela, ker se timi niso uskladili glede vmesnika
      • uporabniške zgodbe se iz testiranja vračajo v razvoj zaradi napačne interpretacije acceptance kriterijev
|

Dinamika Daily Scrum dogodka

Prisotnost Scrum Mastra (SM) in Product Ownerja (PO) na Daily Scrum dogodku ni potrebna. To še posebej velja za PO. Daily Scrum je dogodek, ki ga razvojniki organizirajo zase.

SM in PO sta načeloma lahko prisotna, ampak naj ne govorita. Še več. Če opazita, da se razvojniki med govorjenjem obračajo proti njima, to pomeni, da so dogodek začeli dojemati kot status report. V takšnem primeru naj se SM in PO enostavno odstranita.

Daily Scrum je z razlogom omejen na 15 minut. Ta dogodek je za razvojnike predvsem formalno dopolnilo osmotske komunikacije, ki idealno, v kolociranem teamu že funkcionira. Razvojniki se med seboj obvestijo kaj delajo, kaj planirajo in kaj jih ovira pri doseganju cilja Sprinta. In to je to. Razprave in planiranja, ki so posledica teh informacij, se izvajajo po Daily Scrumu v krogu relevantnih oseb. Kdo je relevanten za nadaljnjo razpravo, pa vsakdo zase izve na Daily Scrumu. Ni namreč dolgočasnejše zadeve kot biti prisiljen poslušati 20 minutne debate med par razvojniki, ki je specifična zanje in je za ostale prisotne irelevantna. Da bi se temu izognili, obstaja omejitev 15 minut in pravilo, da se razprave izvajajo po dogodku.

Daily Scrum omogoča transparentnost dela in s tem (po dogodku) združevanje relevantnih (za problem) razvojnikov v skupine, ki rešujejo razkrite probleme. Od tod izvira rahlo zavajajoča trditev, da je: “Daily Scrum priložnost za planiranje in prilagajanje Sprint backloga”.

  • Planiranje je v kontekstu zgornje izjave mišljeno zgolj kot planiranje planiranja. Člani se dogovorijo za koga bi bilo ta dan najbolj smiselno, da delajo skupaj in kateri razvojniki bojo delali samostojno.
  • Prilagajanje Sprint Backloga je pa samo posledica novih spoznanj. Če na primer neformalna skupina, ki se je oblikovala po Daily Scrumu ugotovi, da je za dosego cilja Sprinta potreben še nek korak, ga bojo dodali na taskboard. Isto velja za spreminjanje prioritet uporabniških zgodb znotraj Sprinta ali njihovo zamenjavo z optimalnejšimi – seveda dokler te spremembe podpirajo doseganje cilja Sprinta.
|

Ostali Daily Scrum formati

Omenimo še to, da mnogi Kanban teami namesto treh vprašanj, za Daily Standup uspešno uporabljajo format Walk the Board. Dogodek v tem formatu je običajno daljši, rezultat pa podoben. Razlika je predvsem v tem, da se metoda Walk the Board osredotoča na identifikacijo blokiranih in počasi napredujočih kartic ter načinov za pospešitev njihovega pretoka skozi razvojni proces.

Poleg omenjenih formatov obstajajo tudi takšni, ki se fokusirajo na določen faktor, kot na primer Risk-focused Daily Scrum, Blockers-first Daily Scrum ali Swarming Daily Scrum.

Da bi bil Daily Scrum, v kakršni koli obliki, produktiven, mora organizacija ustvariti vzdušje varnosti. Člani teamov se ne smejo bati izražati svojih mnenj zaradi strahu, da bi to vplivalo na njihovo pozicijo ali, da bi se zaradi tega kdo iz njih norčeval. Ustvarjalna participacija je na vrhu Maslowove hierarhije potreb. Če želimo, da je prisotna, se mora organizacija  potruditi, da pokrije nižje nivoje (fiziološki, varnost, pripadnost in spoštovanje).

|

DAILY SCRUM - KAKO NAPREJ?

Tri vprašanja niso zapoved, so pa dober temelj za učinkovit Daily Standup. Razvojnim timom bi priporočil, da namesto da na novo izumljajo kolo, uporabijo ta format in poskrbijo, da bojo ostali organizacijski faktorji podpirali funkcionalnost dogodka. Disfunkcija Daily Scruma je pogosto odraz organizacijskih disfunkcij, ki jih spreminjanje formata Daily Scruma ne bo rešilo.

V prejšnjem članku sem opisoval Scrum vzorce. Da tema nebi obvisela v zraku, za Daily Scrum obstaja nekaj zelo koristnih vzorcev. Nekateri niso daljši kot eno vrstico.

Vzorci povezani z Daily Scrumom:

Ostale objave

Scrum vzorci - duh Scruma
Napredni pristopi
admin

SCRUM VZORCI – DUH SCRUMA

“Scrum is a light-weight process framework which is simple to understand but difficult to master.” Zgornja trditev je uveljavljena mantra Agilnih praktikov, konzultantov in evangelistov. Je resnična, a sama po sebi ne prinaša vrednosti. Scrum vzorci nadgrajujejo framework s praktičnimi

Članek »
Scrumban
Osnove
admin

KAJ JE SCRUMBAN

Člani teamov, nezadovoljni s Scrumom, včasih pravijo, da bodo “kar prešaltali na Scrumban”, ker tam ni potrebno planirati. To je pogosto prepričanje. Scrumban bo nekako ohranil vse prednosti Scruma, rešil pa nas bo dolgočasnega ocenjevanja velikosti uporabniških zgodb in planiranja

Članek »
Adaptive leadership
Delo s teamom
admin

ADAPTIVE LEADERSHIP SKOZI RAZVOJ TEAMA

V nedavnem članku smo spoznali Tuckmanov model razvoja teamov. Prispevek se je osredotočal na sam model in značilnosti teamske dinamike v določenih fazah. Tokrat bomo temo nadgradili z vpogledom v to, kako razvoj teama izgleda s stališča “servant leaderja“. Adaptive

Članek »
CFD interpretacije
Orodja
admin

CFD INTERPRETACIJE

Cumulative Flow Diagram (CFD) se s pridom uporablja v večini Agilnih frameworkov. Populariziral ga je Kanban, kjer je  “Visualize the flow” ena od šestih vodilnih praks. CFD prikazuje količino dela, ki se trenutno nahaja v določeni fazi razvojnega cikla in

Članek »
Shopping Cart
Scroll to Top