11 leggyakoribb ok a Scaled Agile Framework (SAFe) használatára, és hogyan lehet ezt kezelni egy nem skálázott Scrummal

És miért hatékonyabb ez, mint a SAFe használata

A több csoporttal való együttmûködés hatékonyságának kiküszöbölésére gyakran valaki javasolja egy méretezési keret bevezetését. Több csapattal, mindenféle probléma felmerül. A méretezési keret bemutatása tökéletes megoldásnak tűnik. Jobb?

Az ilyen keretek legismertebb példája a Scaled Agile Framework (SAFe). A programnövekedés szintjén a SAFe előterjeszti a Scrum-ot mint a terméklépések létrehozásának egyik módját. Ezzel a Scrum adaptált változata gyakran része a SAFe-nek.

Amikor az emberek bemutatják a SAFe-t, további eseményeket, tárgyakat, szerepeket és szabályokat vezetnek be. Ez tovább növeli környezetük bonyolultságát, ami saját kihívásokat és problémákat hozhat fel. Az emberek által a SAFe-rel bevezetett kockázatok gyakran nagyobbak, mint azok a problémák, amelyeket meg akarnak oldani a SAFe-rel.

A SAFe használatának leggyakoribb okait azonban csak a Scrum használatával lehet megoldani, mindegy, hogy könnyű. Most megmutatom, hogy nincs szüksége SAFe-re a leggyakoribb méretezési problémák megoldásához.

A CocaParisienne készítette a Pixabay-nél

1. Csapatközi függőségek kezelése a növekedés elérése érdekében

Ha több csapat dolgozik ugyanazon a terméken, akkor ezek a csapatok gyakran függnek egymástól. Az A csapat intézkedéseket kérhet a B-csapattól és fordítva. A SAFe segítségével azonosíthatja az ilyen típusú függőségeket a programnövekedés tervezése során, általában több sprintre tekintve.

A Scrum remekül távolíthatja el ezt a problémát:

„A fejlesztői csoportok többfunkciósak, és minden olyan készséggel rendelkeznek, mint egy csapat, amely a termékjavítás létrehozásához szükséges;” - Scrum Guide 2017

Minden fejlesztőcsoportnak képesnek kell lennie arra, hogy kézbesítse a termék egy darabját. Ha léteznek függőségek a csapatok között, korlátozzák őket erre, akkor vizsgálják meg a csapatok átszervezésének módját, hogy a függőségek már ne legyenek ott. Ezzel a SAFe használatának első oka eltűnik.

2. A látástól a termékig / a vállalati szint összehangolása a csapat szintjével

Gyakran egy termékképet hoznak létre a Scrum csapatoktól távol, ahol az értékes termékeket építik. A SAFe-vel további rétegek vannak (portfólióhoz és / vagy nagy megoldásokhoz), amelyek célja, hogy elősegítsék a látás lecsökkentését a csapat hátralévő részében.

Így lehet megoldani ezt a Scrummal:

„A Termékmaradék mindent megrendel, amelyről ismert, hogy a termékben szükség van. Az egyetlen követelményforrás a termék bármilyen módosításához. ” - Scrum Guide 2017

Igen, a Termék Hátralévő ponton bemutathatja, hogyan szeretne látásról értékelni az értéket. Gyakran látja, hogy csak azokat a tételeket naplózza, amelyek a következő néhány sprinthez szükségesek. A Scrum útmutató azonban nagyon egyértelmű, hogy mindennek, amelyről tudott, hogy szükség van, ott kell lennie. Nem kell teljesen kitalálni, van olyan homályos cikk, amely a munka nagy darabjait képviseli.

3. Igazítsa a termék döntéshozóit és a termék tulajdonosát

A termék irányával kapcsolatos döntések gyakran a terméktulajdonos hatáskörén kívül esnek. A SAFe ezt olyan szerepekkel látja el, mint az üzleti tulajdonos és az epikus tulajdonos.

Így oldhatja meg csak Scrummal:

"A terméktulajdonos felel a termék értékének maximalizálásáért, amely a fejlesztői csapat munkájából származik." - Scrum Guide 2017

Ha engedélyezi a terméktulajdonos felelõsségét a termék értékének maximalizálásáért, akkor nincs szüksége a SAFe-ben meghatározott további szerepekre.

Most más helyzetben lehet, ahol a termékért és a termékmaradékért való felelősség külön van. Ha azonban több csapattal rendelkező termékkörnyezetben hatékonyabb lenne, fontolja meg ennek megváltoztatását a terméktulajdonos szerep kibővítésével.

4. Adjon ellenőrzési mechanizmust a szervezet felső szintjén

A szervezet felső rétegének emberei gyakran nem tudják pontosan, hogyan működnek a csapatok az értékes termékek előállítása érdekében. Nem érzik magukat, hogy bevonják őket vagy irányítsák őket. A SAFe-nak számos rétege és eseménye van erre. Rossz kezekben azonban ezzel visszaélhetjük a felülről lefelé történő irányítás kényszerítésére.

A Scrum biztosítja a tökéletes - tiszta és egyszerű - helyet a jelenlegi állapot felméréséhez és a következő lépések megvitatásához:

„A Sprint áttekintése során a Scrum csapata és az érdekelt felek együttműködnek a Sprintben végzett munkában. Ennek alapján, valamint a termékmaradványban a Sprint során bekövetkezett bármilyen változás alapján a résztvevők együttműködnek a következő dolgokon, amelyeket meg lehet tenni az érték optimalizálása érdekében. ” - Scrum Guide 2017

Igen, a Sprint Review az Ön eseménye, ha meg akarja vitatni az aktuális terméket és azokat a dolgokat, amelyek befolyásolhatják a következő lépésekkel kapcsolatos döntéseket. Közvetlen és hatékony, mivel minden érintett részt vehet a beszélgetésben.

Nem számít, mi a szerepe. Ha befolyásolni szeretné a termék irányát, akkor látogasson el a Sprint Review-re!

5. Szállítás szinkronizálása / lépések integrálása

Több csapatos termékkörnyezetben a SAFe Agile Release Trains szinkronizálja a szállítást több csapat kiadásai felé.

A Scrum segítségével a csapatok többféle módon szinkronizálhatják munkájukat. Ennek kulcsa:

„A Scrum csapatok gyakran együtt dolgoznak ugyanazon a terméken. Az egyik termékmaradvány a termékkel kapcsolatos küszöbön álló munkák leírására szolgál. ” - Scrum Guide 2017

Ez magában foglalja a következőket:

1 Termékmaradás → 1 Terméktulajdonos → 1 Terméknövekedés → 1 Sprint áttekintés.

Ezzel a szinkronizálás már automatikusan a helyén van, mivel 1 terméknövelést kell ellenőrizni az 1 Sprint áttekintés során. A Scrum empirikus folyamatirányítási megközelítését nem szabad érvényteleníteni az ilyen típusú kiadási szinkronizálási problémák miatt. Ez megszakítaná a visszacsatolás körét.

Ehelyett a csapatoknak aktívan kell keresniük az integráció megkönnyítésének lehetőségeit valódi, agilis módon:

"Együttműködnek és együttműködnek kifinomult fejlesztési architektúrákon és célzott kiadási környezeteken keresztül." - Scrum Guide 2017

6. Javítani kell a termelékenységet

A SAFe-t gyakran bevezik a csapatok termelékenységének növelése érdekében. Az alacsonyabb termelékenység oka a fentiek bármelyikének kombinációja lehet:

  • Csapatközi függőségek kezelése a növekedés elérése érdekében;
  • A látástól a termékig / a vállalati szint összehangolása a csapat szintjével;
  • Adjon ellenőrzési mechanizmust a szervezet felső szintjén;
  • Szállítás szinkronizálása / lépések integrálása.

Az ezeken a területeken történő javulás a termelékenység javulásához vezetne. A termelékenység javulását nagyrészt összehasonlítják a hagyományos projekt-végrehajtási megközelítésekkel (a vízesés területén).

Már tárgyaltam, hogy ezek a fejlesztések miként valósíthatók meg hatékonyan a Scrumban. Ennek eredményeként a Scrum máris elősegíti a termelés jelentős javulását. Ehhez nem kell SAFe-t használni.

7. Növelje az érték kiszállítását

A SAFe a hagyományos termékmenedzsment alternatívájaként kerül bemutatásra. A Lean és Agile elvek és keretek, például a Scrum használatával, a SAFe a helyes dolgok építésére összpontosít. A SAFe rendszeresen gondolkodási pillanatokkal rendelkezik annak biztosítása érdekében.

A reflexió pillanatai azonban a Scrumban már be vannak merülve. Heck, SAFe a Scrum-ban meghatározott reflexiós momentumokat használja (mint például a Sprint Review és a Sprint Retrospektív), és csak a további komplexitás miatt további reflexiós pillanatokat igényel.

A Scrum esetében kiemelkedik az, hogy ezek a reflexiós pillanatok - a legfontosabb érintettekkel együtt - gyakrabban fordulnak elő, mert minden sprintnél fordul elő, nem pedig minden egyes sprintnél (SAFe esetén). Ez nagyobb rugalmasságot, több lehetőséget kínál az új ismeretekhez való alkalmazkodáshoz, ami ennek eredményeként nagyobb eséllyel növeli az értékmegjelenítést.

8. Növelje a minőséget

A SAFe “beépített minőségű”. Ez az egyik módja annak, hogy a szállított termékek megfeleljenek a vállalat minőségi előírásainak. A beépített minőség része a csapat „kész” meghatározása.

Scrum ugyanakkor arra törekszik, hogy ugyanezt tegye a „Kész” meghatározásával. Már tartalmaznia kell a vállalati minőségi előírásokat. A „Kész” definícióját általában a fejlesztési szervezeti szinten határozzák meg. Nem csapat szinten.

A SAFe előadja, hogy a beépített minőség több, mint Scrum „Kész” meghatározása. Nem értek egyet ezzel. A „kész” meghatározása az, amit egy fejlesztési szervezet belőle készít. Magában foglalhatja ugyanazokat a dolgokat, mint a SAFe beépített minősége.

9. Szervezeti diagram - mit kell tenni a termékkel foglalkozó összes emberrel?

A SAFe kényelmes választ ad arra a kérdésre, ahová a szervezet minden tagja illeszkedik, amikor „agilisan dolgozik”. A sok szerep mellett mindenkinek mindig van hely (üzleti menedzsment, termékmenedzsment, rendszerépítészek, rendszermérnökök, Release Train Engineer és még sok más a nagyobb megoldások számára).

Mindezen szerepek jelenléte a SAFe-ben lehetővé teszi egy olyan álláspont kialakítását, amely „olyan könnyen illeszkedik a meglévő szervezethez”. Ez kiküszöböli a valós - fájdalmas, de szükséges - változtatások szükségességét a szervezetben. Ezzel eredményezheti, hogy egy „agilisnak” látszó, de valójában nem „agilis” szervezet lesz, hiányozva az agilis működés összes előnyeit.

Scrummal nincs ilyen egyszerű válasz. A Scrum csak három szerepet (terméktulajdonos, Scrum mester, fejlesztői csoport tagja) és az érdekelt feleket ismeri. Fontos megérteni, hogy ezek a Scrumon belüli szerepek. Ez nem / nem kell, hogy egyezzen egy vállalati funkcióval.

A Scrum egy keret. Vászonot ad, és a rajtad múlik, hogyan készíti el a festményét. Íme néhány példa annak megoldására, hogy ki megy, hová:

  • A termékmenedzser lehet a Scrum terméktulajdonos vagy kulcsfontosságú érdekelt;
  • Rendszermérnök lehet a fejlesztési csoport része vagy kulcsfontosságú érdekelt;
  • Rendszer-építész lehet a fejlesztési csoport része vagy kulcsfontosságú érdekelt;
  • A SAFe meghatározása szerint a terméktulajdonos (a Team Backlogon dolgozik) termékfejlesztő csoportban lehet termék-szakértő vagy a terméktulajdonos.

A Scrum megadja a szabadságát annak végrehajtásához, ahogy a legkedvezőbbnek tartja. Ehhez nincs szüksége további szerepekre vagy eseményekre. A Scrum keret használatához mindenkinek van helye.

10. Kezeljen egy programot több termékkel

A SAFe bevezetésének másik oka egy olyan program kezelése, amelyben sok termék található, sok függőség függvényében.

Azt állíthatja, hogy már tárgyaltam a függőségeket (az 1. és az 5. témára gondolok). Szeretném azonban kifejezetten a több termékre mutatni ezt a példát.

Az első dolog: nem összekeverik a projektmenedzsment és a termékmenedzsment?

A SAFe és a Scrum egyaránt megoldások értékes termékek szállítására. Mindkettő NEM projekt menedzsment keret.

Ha különböző, sok függőségű termékek vannak, akkor fontolóra kell vennie, hogy mit határoz meg termékként. A termék meghatározásának újraértékelése és ennek eredményeként a termékportfólió újraértékelése lehet megfelelő. Ez valószínűleg növeli az átláthatóságot (például aki felelős terméktulajdonosként), és megszünteti a SAFe használatának nyilvánvaló szükségességét.

11. Több terméktulajdonos hozzáigazítása a termék irányához

A SAFe-t gyakran megoldásnak is tekintik, amely összehangolja a termékért felelős több terméktulajdonosot. A munka ezután becsapódhat a program vagy a portfólió hátralékából a csapat hátralévő részébe, terméktulajdonosonként megosztva.

A probléma az, hogy a terméknek csak egy terméktulajdonosnak kell lennie (1 termékmaradvány → 1 terméktulajdonos). Ezért az, hogy egy termékhez több terméktulajdonos tartozik, anti-mintázatot jelent. Ha elveszi ezt a kérdést, akkor el is szünteti az ilyen típusú igazítás szükségességét, ami indokolja a SAFe használatát.

Alsó sorban

A Scaled Agile Framework (SAFe) sok általános kérdésre kínál megoldásokat, ha azt akarja, hogy nagyobb rugalmassággal dolgozzon. Ha azonban problémáit meg akarja oldani, akkor nincs szüksége a SAFe összes harangjára és sípjára. Ugyanazokat a kérdéseket megoldhatja a Scrum segítségével, amely egy igazán könnyű keret. A Scrum önmagában történő használatával elkerülhetők a felesleges bonyolultság és a túlterhelés.

Azt tanácsolom, hogy mindig határozza meg az Ön valódi igényeit, és kezdje el kicsivel.

Könnyebb hozzáadni a bonyolultságot, mint eltávolítani. Tehát mindig legyen óvatos, ha egyszerre sok bonyolultságot ad hozzá. Próbálja meg fokozatosan hozzáadni, és derítse ki, ha valóban szüksége van rá, és valóban megoldja-e a problémát. Ha egyszer ott nehéz eltávolítani.

A súrlódás az egyik módszer a kicsi kezdéshez. Ha elég jól elsajátította a Scrumot, és továbbra is úgy érzi, hogy valami hiányzik, akkor mindig kereshet méretezési módszereket. Itt a SAFe az egyik lehetőség, de ott vannak a LeSS, a Nexus, a Scrum @ Scale és mások is.

Kellemesen lepni fogja a Scrum ereje. Egyszerűen csak Scrummal méretezhető.

A méretezett Scrum továbbra is Scrum. Egyszerű és erős.
Szeretne Serious Scrumért írni, vagy komolyan megvitatja Scrumot?