Scrum vadovas | 16. Scrum plėtra

Scrum komanda turėtų sudaryti iki dešimties žmonių. Bet ką daryti, kai didesnė specialistų grupė turi dirbti prie vieno projekto? Arba jei organizacija nusprendžia laikytis agilaus valdymo būdo? Šiai problemai spręsti Scrum kūrėjai pasiūlė Scrum@Scale. Tai architektūra be masto, skirta organizuoti visas komandas pagal Scrum principus.

Scrum masto didinimas – turinys:

1. Įvadas
2. Scrum@Scale
3. Scrum iš Scrum
4. Tolimesnis masto didinimas ir Scrum@Scale klausimai
5. Santrauka

Įvadas

Kai organizacija auga, atsiranda naujų problemų. Pavyzdžiui, darbuotojų efektyvumo sumažėjimas, kurį sukelia sudėtinga vidinė struktūra, sunkus sprendimų priėmimas ar krypties nustatymas. Įmonės, dirbančios agiliai mažų projektų komandos lygyje, dažnai siekia didinti mastą.

Daugelis įmonių puikiai veikia be Scrum masto didinimo. Net jei tuo pačiu metu veikia daug Scrum komandų, joms nereikia koordinacijos, nes grupės veikia nepriklausomai. Tačiau tai nereiškia, kad tai yra multi-komandinis Scrum. Reikalingumas didinti mastą atsiranda tik tada, kai didžioji organizacijos dalis dirba prie vieno produkto ir gali efektyviai sinchronizuoti savo kelias Scrum komandas.

Dauguma organizacijų, kurios priima agilaus valdymo metodus dideliu mastu, pasirenka SAFE modelį, arba Scaled Agile Framework. Tačiau šiandien mes nesusitelksime į SAFE, o aptarsime kitą modelį, vadinamą Scrum@Scale, nes pagal 2021 metų 15-ąjį Agilo būklės ataskaitą, tai yra antras geriausias pasirinkimas tarp įmonių, kurios pasirenka agilaus valdymo metodus.

Scrum@Scale

1996 metais Scrum kūrėjai, Jeff Sutherland ir Ken Schwaber, dirbo prie didelio projekto. Dirbdami jie turėjo problemų, kaip išlaikyti mažesnes Scrum komandas sinchronizuotas. Jie sukūrė būdą, kaip tai padidinti, kurį galiausiai pavadino Scrum@Scale.

Panašiai kaip oficialus Scrum vadovas, buvo Scrum@Scale vadovas, kuris apibrėžia šį masto didinimo būdą kaip:

Rėmas, kuriame veikia Scrum komandų tinklai, laikydamiesi Scrum vadovo, kad išspręstų sudėtingas adaptacines problemas ir kūrybiškai pristatytų produktus su kuo didesne verte.

Pagrindinė Scrum@Scale prielaida yra paprastumas ir efektyvumas. Todėl jo veikla remiasi architektūra be masto. Kitaip tariant, jis naudoja Scrum, kad padidintų Scrum. Tokiu būdu Scrum komanda, sudaryta iš asmenų, veikiančių kaip Produkto savininkas, Scrum meistras arba Kūrėjas, tampa Scrum iš Scrum: komanda, sudaryta iš komandų.

Scrum iš Scrum

Scrum iš Scrum yra Scrum komanda, kurioje žmonės atlieka tradicines Scrum roles. Tačiau kadangi Scrum iš Scrum užduotis yra integruoti kelių Scrum komandų darbo rezultatus, jiems reikia papildomų pareigų:

• Produkto savininkų komanda – grupė Produkto savininkų, kurie susitinka, kad sutartų dėl prioritetų ir sukurtų vieningą produkto viziją
• Pagrindinis produkto savininkas – Scrum komandos Produkto savininkas arba asmuo, kuris išimtinai dirba su Scrum iš Scrum
• Scrum iš Scrum meistras – asmuo, kuris prižiūri Scrum iš Scrum efektyvumą.

Jie susitinka tose pačiose Scrum renginiuose ir naudoja panašius artefaktus.

Tolimesnis masto didinimas ir Scrum@Scale klausimai

Scrum@Scale architektūra be masto reiškia, kad ji leidžia didinti mastą daugiau nei vieną kartą. Jei organizacijai reikia koordinuoti komandas dar didesniu mastu, ji gali sukurti Scrum iš Scrum.

Tačiau Scrum masto didinimas, kaip ir bet kuri kita valdymo metodologija, turi savo trūkumų, ir šiuo atveju jie yra panašūs į pagrindinių Scrum komandų trūkumus, tik proporcingai didesni. Todėl rekomenduojame išsiaiškinti bendradarbiavimo detales kiekvienoje Scrum komandoje prieš pradedant Scrum didesniu mastu. Siūlome didinti Scrum mastą patyrusioms komandoms, turinčioms gerą žinių ir supratimo apie Scrum vertybes ir veikimą.

Scrum masto didinimas – santrauka

Scrum masto didinimas nėra vaikų žaidimas. Tai reikalauja, kad Scrum komandos įgudusiai taikytų Scrum principus ir sinchronizuotų savo užduotis su kitomis Scrum komandomis. Todėl pagrindinis klausimas, į kurį reikia atsakyti, yra: Ar reikia didinti mastą? Vien tai, kad organizacijoje yra daug Scrum komandų, automatiškai nereiškia, kad jų koordinavimas atneš geresnių rezultatų.

Jei organizacija pasirenka didinti Scrum, ji gauna architektūrą be masto, kuri gali būti sėkmingai toliau didinama. Tačiau kiekvienas didinimas lydi sudėtingumo lygio padidėjimą, su kuriuo turi susidoroti Produkto savininkų komanda, Pagrindinis produkto savininkas ir Scrum iš Scrum meistras.

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