A Scrum Csapatnak legfeljebb tíz főből kell állnia. De mi a teendő, ha egy nagyobb csoport szakembernek kell dolgoznia egy projekten? Vagy ha a szervezet úgy dönt, hogy agilis menedzsmentet követ? Ennek a problémának a megoldására a Scrum fejlesztők javasolták a Scrum@Scale-t. Ez egy skálázás-mentes architektúra, amely lehetővé teszi, hogy az egész csapatokat a Scrum elvei szerint szervezzük.
Scrum skálázása – tartalomjegyzék:
Bevezetés
Amint egy szervezet növekszik, újfajta problémák merülnek fel. Például a munkavállalók hatékonyságának csökkenése, amelyet a bonyolult belső struktúra, a nehéz döntéshozatal vagy az irányvonal meghatározása okoz. Azok a cégek, amelyek agilis módon működnek a kis projektcsapat szinten, gyakran próbálnak skálázni.
Sok vállalat jól működik anélkül, hogy skálázná a Scrumot. Még ha sok Scrum Csapat is párhuzamosan működik, nem szükséges a koordináció, mivel a csoportok függetlenül működnek. Ez azonban nem jelenti azt, hogy ez egy többcsapatos Scrum. A skálázás szükséglete csak akkor merül fel, amikor a szervezet többsége egy terméken dolgozik, és hatékonyan tudja szinkronizálni a több Scrum Csapatát.
A legtöbb olyan szervezet, amely agilis menedzsment módszereket alkalmaz nagy léptékben, a SAFE modellt, vagyis a Skálázott Agilis Keretrendszert választja. Ma azonban nem a SAFE -ra fogunk összpontosítani, hanem egy másik modellt, a Scrum@Scale -t fogjuk megvitatni, mivel a 2021-es 15. Állapotjelentés az Agilisról szerint ez a második legjobb választás az agilis módszert választó vállalatok körében.
Scrum@Scale
1996-ban a Scrum alkotói, Jeff Sutherland és Ken Schwaber, egy nagy projekten dolgoztak. Miközben ezt tették, nehézségeik adódtak a kisebb Scrum csapatok szinkronizálásával. Kidolgoztak egy módot a skálázásra, amit végül Scrum@Scale-nek neveztek el.
A hivatalos Scrum Útmutatóhoz hasonlóan létezett a Scrum@Scale Útmutató is, amely ezt a munkaskálázási módot a következőképpen határozza meg:
Olyan keretrendszer, amelyben a Scrum Csapatok hálózatai a Scrum Útmutató szerint működnek, hogy összetett adaptív problémákat oldjanak meg, és kreatívan szállítsanak termékeket a lehető legnagyobb értékkel.
A Scrum@Scale alapvető premisszája az egyszerűség és a hatékonyság. Ezért működése skálázás-mentes architektúrára épül. Más szavakkal, a Scrumot használja a Scrum skálázására. Ily módon egy Scrum csapat, amely olyan egyénekből áll, akik Termék Tulajdonos, Scrum Mester vagy Fejlesztő szerepet töltenek be, a Scrumok Scrumjává válik: egy csapat, amely csapatokból áll.
A Scrumok Scrumja
A Scrumok Scrumja egy Scrum csapat, amelyben az emberek a hagyományos Scrum szerepeket töltik be. Azonban mivel a Scrumok Scrumjának feladata több Scrum Csapat munkájának eredményeit integrálni, további posztokra van szüksége:
- Termék Tulajdonos Csapat – egy Termék Tulajdonosokból álló csoport, amely találkozik, hogy megállapodjon a prioritásokról és létrehozzon egy koherens termékvíziót
- Fő Termék Tulajdonos – a Scrum Csapat Termék Tulajdonosa vagy egy olyan személy, aki kizárólag a Scrumok Scrumjával foglalkozik
- Scrumok Scrum Mester – az a személy, aki felügyeli a Scrumok Scrumjának hatékonyságát.
Ugyanazokon a Scrum Eseményeken találkoznak, és hasonló Artefaktumokat használnak.

További skálázás és Scrum@Scale kérdések
A Scrum@Scale skálázás-mentes architektúrája azt jelenti, hogy lehetővé teszi a skálázást több mint egyszer. Ha egy szervezetnek szüksége van a csapatok koordinálására még nagyobb léptékben, létrehozhatja a Scrumok Scrumját.
Azonban a Scrum skálázása, mint bármely más menedzsment módszertan, rendelkezik hibákkal, és ebben az esetben ezek hasonlóak az alap Scrum Csapatok hibáihoz, csak arányosan nagyobbak. Ezért javasoljuk, hogy dolgozzák ki a részleteket a kollaborációról minden Scrum Csapaton belül, mielőtt nagyobb léptékben kezdenék el a Scrumot. Azt javasoljuk, hogy a Scrumot tapasztalt csapatok számára skálázzák, akik jól ismerik és értik a Scrum értékeit és működését.

Scrum skálázása – összefoglalás
A Scrum skálázása nem gyerekjáték. Megköveteli, hogy a Scrum Csapatok ügyesen alkalmazzák a Scrum elveit, és szinkronizálják feladataikat más Scrum Csapatokkal. Ezért az alapvető kérdés, amire válaszolni kell: Szükséges a skálázás? Csak azért, mert sok Scrum Csapat van egy szervezetben, nem jelenti automatikusan azt, hogy a koordinálás jobb eredményeket hoz.
Ha egy szervezet úgy dönt, hogy kiterjeszti a Scrumot, egy skálázás-mentes architektúrát nyer, amelyet sikeresen tovább lehet skálázni. Azonban minden kiterjesztés a komplexitás szintjének növekedésével jár, amellyel a Termék Tulajdonos Csapatnak, a Fő Termék Tulajdonosnak és a Scrumok Scrum Mesterének kell foglalkoznia.
Ha tetszik a tartalmunk, csatlakozzon aktív közösségünkhöz a Facebookon, Twitteren, LinkedIn-en, Instagramon, YouTube-on, Pinterest-en.
Caroline Becker
Projektmenedzserként Caroline szakértő az új módszerek megtalálásában, amelyek a legjobb munkafolyamatok megtervezésére és a folyamatok optimalizálására szolgálnak. Szervezési készségei és a nyomás alatt végzett munka iránti képessége teszik őt a legalkalmasabb személyré, aki bonyolult projekteket valóra tud váltani.
Scrum Guide:
- Alapfogalmak, szerepek és fogalmak szótára
- Mi a Scrum?
- Scrum értékek
- Hogyan valósítsuk meg a Scrumot a vállalatunkban?
- Scrum Csapat - mi az és hogyan működik?
- Ki a terméktulajdonos?
- A Product Owner leggyakoribb hibái
- Ki a Scrum Master?
- A Scrum Master leggyakoribb hibái
- Milyen statisztikákat és mutatókat kell nyomon követnie a Scrum Masternek?
- Scrum fejlesztőcsapat
- A fejlesztők leggyakoribb hibái
- Scrum artefaktumok
- Skálázott Scrum
- Sprint Hátralék
- Mi az a termék hátralék?
- Mik azok a felhasználói történetek?
- A legjobb Felhasználói Történet létrehozása az INVEST elv alapján
- A leggyakoribb felhasználói történet hibák
- Felhasználói történet elfogadási kritériumok
- Becslés és Történetpontok a Scrum-ban
- Tervezési Póker
- Csapatbecslési játék
- Növekmény meghatározása
- Scrum események
- Mi az a Burndown Diagram?
- A burndown diagram előnyei és hátrányai
- Kanban táblák a Scrum és Scrumban keretrendszerben
- Sebesség a Scrum-ban - A Fejlesztő Csapat Sebessége
- Napi Scrum
- Sprint tervezés
- Sprint értékelés
- Mi az a Sprint Retrospektív?
- A Sprint Retrospektív során elkövetett gyakori hibák
- Termék Backlog ápolása
- Hogyan kell létrehozni és értelmezni egy burndown diagramot?
- Mi az a Sprint a Scrum-ban?
- A Terméktulajdonos és a Scrum Master közötti együttműködés
- Scrum Csapat Kötelezettségek - Termék Cél, Sprint Cél és Teljesítési Meghatározás
- A jó Scrum Master jellemzői