Scrum vadovas | 39. Dažniausios klaidos per Sprinto retrospektyvą

Sprinto retrospektyva yra renginys, kuris baigia kiekvieną Sprintą. Ir tuo pačiu metu tai yra viena iš sunkiausių Scrum komandos susitikimų. Dažniausios klaidos, pasitaikančios Sprinto retrospektyvos metu, apima vengimą kalbėti apie jautrias problemas, taip pat konkrečių įsipareigojimų trūkumą, vedančių į jau diagnozuotų problemų sprendimą.

Dažnos klaidos Sprinto retrospektyvos metu – turinys:

1. Įžanga
2. Neužtenkama skaidrumo
3. Dėmesys vienkartinėms problemoms ar sėkmėms
4. Per didelis produkto savininko atstovavimas
5. Savarankiško valdymo problemos
6. Per daug įsipareigojimų
7. Dažnos klaidos Sprinto retrospektyvos metu – santrauka

Įžanga

Klaidos, pasitaikančios Sprinto retrospektyvos metu, deja, yra labai dažnos. Tai yra todėl, kad tai yra vienas iš sunkiausių susitikimų, kurį sėkmingai įgyvendinti reikalauja daug brandos iš komandos. Todėl verta pažvelgti į problemas, kurios dažniausiai pasitaiko kitose komandose, kad galėtumėte lengviau pastebėti jų simptomus, vykdydami Sprinto retrospektyvą savo Scrum komandoje.

Neužtenkama skaidrumo

Pagal Scrum vadovą, kiekvienas Scrum komandos narys privalo būti sąžiningas ir drąsus išreiškiant rūpesčius ir pasakyti savo nuomonę Sprinto retrospektyvos metu. Tačiau praktikoje įsipareigojimas skaidrumui yra labai reikalaujantis. Dėl to Scrum komandos nariai dažnai bando jo išvengti.

Viena problema, kurią sunku pastebėti ir išspręsti, yra vengimas diskutuoti apie pastebėtus trūkumus Scrum komandos darbe. Tai gali sukelti daug rimtesnių problemų ilgainiui.

Todėl Scrum meistro užduotis yra atidžiai stebėti situaciją komandoje ir skatinti visus komandos narius būti proaktyviais nuo pat Sprinto retrospektyvos pradžios.

Dėmesys vienkartinėms problemoms ar sėkmėms

Dar viena problema, kuri gali kilti Sprinto retrospektyvos metu, yra nepakankamas dėmesys ciklinėms ir pasikartojančioms komandos elgsenoms, ir jų poveikiui komandos efektyvumui.

Visada gerai pasveikinti Scrum komandos narius, jei jie pasiekė išskirtinę sėkmę. Tačiau Sprinto peržiūra neturėtų būti skirta jos šventimui. Tas pats pasakytina ir apie nesėkmes. Jei kažkas nepavyko dėl atsitiktinių priežasčių ar jau diagnozuotos klaidos, neverta per daug analizuoti įvykio Sprinto peržiūros metu.

Tačiau kartais komanda skiria didelę dalį Sprinto retrospektyvos tokiems įvykiams. Tačiau turėkite omenyje, kad Sprinto retrospektyvos tikslas yra ieškoti būdų, kaip pagerinti komandos kasdienį darbą. Todėl susitikimas neturėtų suktis aplink vienkartines sėkmes ar problemas, kurios labai tikėtina, kad nepasikartos.

Per didelis produkto savininko atstovavimas

Daugelyje organizacijų produkto savininko pozicija yra lyginama su produkto vadovo pozicija. Produktų savininkas dažnai laikomas Scrum komandos priežiūros asmeniu. Dėl šios priežasties nutinka, kad plėtros komanda nenori kalbėti apie komandos darbo problemas jo buvimo metu.

Štai kodėl taip svarbu kurti tarpusavio pasitikėjimą tarp plėtros komandos ir produkto savininko. Deja, pasitikėjimo kūrimo procesas yra sudėtingas ir ilgas. Todėl kartais gerai, kad produkto savininkas atsisakytų dalyvauti visoje ar dalyje Sprinto retrospektyvos, kad paliktų erdvės likusiai komandai laisvai diskutuoti.

Savarankiško valdymo problemos

Savarankiškas valdymas reiškia, kad Scrum komandos nariai patys priima sprendimus, kas iš jų atliks tam tikras užduotis, kada ir kaip. Sprinto retrospektyvos metu komanda diskutuoja apie žmones, jų sąveiką ir komandos praktikas. Tada ji nusprendžia, kokias problemas reikia išspręsti artėjančiame Sprinto, kaip tai padaryti kartu ir kas prisiims atsakomybę už veiksmų atlikimą.

Jei savarankiško valdymo komandoje kyla rimtesnių problemų, Scrum komandoje gali kilti pagunda atsisakyti atsakomybės.

Kartais komandos nariai nenori dalyvauti diskusijoje ir bando perkelti valdymo atsakomybę ant kažko kito. Tam užkirsti kelią, labai svarbu reguliariai diskutuoti net apie mažas problemas, kad būtų išvengta jų kaupimosi.

Per daug įsipareigojimų

Aktyvi Scrum komanda, veikianti pagal trijų empirizmo pilarų: skaidrumo, tikrinimo ir pritaikymo, gali susidurti su problema, kad vienu metu priima per daug įsipareigojimų.

Jei Scrum komandos priimti įsipareigojimai Sprinto retrospektyvos metu yra per daug, kyla didelė rizika, kad:

• joks įsipareigojimas nebus tinkamai įgyvendintas
• kai kurie įsipareigojimai visai nebus įgyvendinti
• padaryti pokyčiai nebus nuolatiniai

Todėl gera praktika yra nepriimti daugiau nei keturių patobulinimų kiekviename Sprinto. Tai leidžia palaipsniui, bet efektyviai pagerinti komandos našumą.

Dažnos klaidos Sprinto retrospektyvos metu – santrauka

Kadangi Sprinto retrospektyva yra sudėtingas renginys, jos vykdymo metu dažnai kyla problemų. Kad būtų lengviau su jomis susidoroti, verta atkreipti dėmesį į tas, kurios pasitaiko dažniausiai. Dažnos klaidos Sprinto retrospektyvos metu yra:

• nepakankamas skaidrumas – kai Scrum komandos nariai nesugeba sąžiningai spręsti sudėtingesnių komandos situacijų
• dėmesys vienkartinėms problemoms ar sėkmėms – kai Scrum komandos nariai koncentruojasi į sėkmių ir nesėkmių aptarimą, o ne į komandos darbo ilgalaikį efektyvumą
• produkto savininko per didelis atstovavimas – kai Scrum komandos nariai traktuoja produkto savininką su ribotu pasitikėjimu, tarsi jis būtų kažkas išorinis komandai arba priežiūros asmuo
• savarankiško valdymo problemos – kai Scrum komandos nariai bando perkelti atsakomybę už problemas ir sprendimų priėmimą.

Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.