Scrum

A Scrum egy összetett (komplex) problémák megoldására kifejlesztett általános keretrendszer. A szoftverfejlesztés területén gyakran használják az agilis szoftverfejlesztés egyik fontos összetevőjeként, de ugyanúgy megtaláljuk szolgáltatások fejlesztésénél, szervezetek irányításánál, még iskolákban is.^[1] Nem kizárólag termékek létrehozására kitalált folyamat vagy technika; sokkal inkább egy olyan keretrendszer, melyen belül különböző folyamatokat és technikákat lehet alkalmazni. A Scrum láthatóvá teszi a termék menedzsmentjének és a fejlesztési gyakorlatainak relatív hatékonyságát, így elősegíti annak tökéletesítését.

A Scrum keretrendszer a Scrum Csapatokból, valamint a hozzájuk rendelt szerepekből, eseményekből, munkaanyagokból (artifacts) és szabályokból áll. A keretrendszeren belül minden egyes komponens meghatározott célt szolgál, és mindegyik alapvetően szükséges a Scrum sikeréhez és használatához. A Scrum szabályai kapcsolják össze az eseményeket, szerepköröket és a munkaanyagokat, meghatározva a köztük lévő viszonyokat és kölcsönhatásokat. A Scrum szabályait a Scrum Guide ismerteti.^[2] A Scrum egyszerű, könnyen érthető, ám kihívás lehet mesteri szintre fejleszteni.

Az 1986-os cikkükben Takeucsi Hirotaka és Nonaka Ikudzsiró leírnak egy módszert, ami nagyban felgyorsítja és rugalmasabbá teszi új termékek fejlesztését:^[3] A tradicionális módszert (vízesés modell), amelyben az egymást sorban követő fejlesztési fázisokat más-más szakembercsapat kezeli, a váltófutáshoz hasonlítják, ahol egyszerre csak egy ember fut, és a futók egymásnak adják a stafétát. Az új módszert, amiben a fázisok erősen átlapolódnak, és a különböző területeket képviselő szakemberek egy kis csoportja végig, minden fázisban együtt dolgozik, a rögbihez hasonlítják, ahol egyszerre az egész csapat fut, és egymás között passzolgatják a labdát. Az esettanulmányok az autóiparból, a fényképezőgép-, számítógép-, és nyomtatógyártásból merítenek.

1991-ben DeGrace és Stahl^[4] hivatkozott rá először úgy, hogy Scrum, amely egy rögbis szakkifejezés, ami már Takeucsi és Nonaka cikkében is szerepel. Ken Schwaber is használt scrum-szerű módszert az 1990-es évek elején. Ezzel egyidejűleg fejlesztett ki Jeff Sutherland egy hasonló módszert az Easel Corporationnél.^[5] Sutherland és Schwaber közös cikkben mutatták be a Scrumot az OOPSLA ’96-on Austinban. Schwaber és Sutherland az azt követő években közösen dolgozott a megjelent írások, a saját tapasztalataik és az szoftveriparban látott gyakorlatok összegyúrásán, melynek eredménye a ma Scrum néven ismert módszertan. 2001-ben Schwaber könyvet írt Mike Beedle-lel közösen Agile Software Development with SCRUM címmel.

A Scrum egy keretrendszer, amely magában foglal bizonyos tevékenységeket és meghatározott szerepeket. A Scrum főbb szerepkörei a „Scrum Mester”, aki a folyamatot felügyeli és a projektmenedzserrel ellentétben, a csapat önálló munkavégzését coachként segíti, a „Product Owner” (magyarul terméktulajdonos), aki a projektben érdekelt döntéshozókat képviseli, és a „Csapat” (Team) ami 3-9 főből áll és lefedi az összes munkafolyamatot.

Minden sprint során – amely 1 és 4 hét közötti időtartamot jelent (a csapat döntésétől függően) – a csapat egy működő terméket (szoftvert vagy más eredményt) hoz létre. A sprint során megvalósítandó funkciók a „Product Backlog”-ból (termék teendőlistája) kerülnek ki, ami az elvégzendő munka magas szintű követelményeiből álló, fontossági sorrendbe állított lista. Hogy a sprint során a lista melyik elemei kerülnek megvalósításra, azt a sprint elején tartott „sprinttervező” megbeszélés során választják ki. A megbeszélés során a „Product Owner” közli a csapattal, hogy a teendők listájából melyek azok, amiket leghamarabb akar, hogy elkészüljenek. Ezután a csapat eldönti, hogy ezek közül melyek azok, amelyeket a következő sprint során meg tud valósítani, és ezek megvalósítására ígéretet tesz. A sprint folyamán a „sprint teendőlistáját” nem lehet megváltoztatni, a sprint során elvégzett tevékenységek rögzítettek. Amint a sprint a végéhez ért, a csapat bemutatja az elkészült funkciókat (demo).

Az önszerveződő csapatok kialakulásának elősegítése végett a Scrum arra ösztönöz, hogy a projekt résztvevői egy helyen dolgozzanak, és szóban kommunikáljanak egymással.

A Scrum egyik legfontosabb alapelve az, hogy felismeri és elfogadja, hogy a megrendelő a fejlesztés során meggondolhatja magát a követelményekkel kapcsolatban, és a váratlan változások nem kezelhetők könnyen a hagyományos, előzetes tervezési fázison alapuló módszerekkel. Ezért a Scrum gyakorlati megközelítést választ, és elfogadja, hogy nincs lehetőség a probléma teljes megértésére és definiálására. Inkább azt próbálja maximálisan elősegíteni, hogy a csapat gyorsan meg tudja valósítani a funkciókat, és gyorsan tudjon reagálni a változó követelményekre.

A 2020-as Scrum Útmutató módosítása ^[6] jelentős változtatást hozott a Scrum keretrendszerbe: kivették a Fejlesztőcsapat kifejezést, ami azt az érzetet keltette, hogy az egy kisebb csapat a csapatban. Az új változatban egy Scrum csapat létezik, aminek a Terméktulajdonos és a Scrum Mester is szerves része. Ők együttesen felelősek a létrehozott eredményekért.

A megrendelőt képviseli. Biztosítja, hogy a csapat az üzleti szempontból fontos dolgokkal foglalkozzon. A termék-teendőlistát bővíti a megrendelő szempontjából megfogalmazott igényekkel, ami rendszerint a "User story"-k keretében kerül megfogalmazásra (Ki, mit, miért szeretne).

A Terméktulajdonos felelős a termék értékének maximalizálásáért. Ennek megvalósítása szervezeti formától, Scrum Csapatoktól és egyénektől függően nagyon eltérő lehet. A Terméktulajdonos az egyetlen személy, aki felelős a Termék Backlog (Termék Teendőlista - Product Backlog) kezeléséért, mely a következőket foglalja magában:

• a Termék Backlog tételeinek egyértelmű leírása,
• a Termék Backlogban szereplő tételeknek sorba rendezése aszerint, hogy azok a célok és küldetések legjobb, leghatékonyabb elérését szolgálják,
• a Fejlesztők által végzett munka értékének optimalizálása,
• annak biztosítása, hogy a Termék Backlog elérhető, könnyen áttekinthető és mindenki számára világos legyen,
• továbbá egyértelmű legyen, hogy a Scrum Csapatnak mi lesz a következő munkája,
• valamint annak biztosítása, hogy a Fejlesztők legalább a munkavégzéshez szükséges szinten értsék a Termék Backlog egyes tételeit.

A Terméktulajdonos saját maga is elvégezheti a fenti teendőket, vagy a Fejlesztők is elvégezhetik azokat, viszont ez utóbbi esetben is a Terméktulajdonosé a felelősség. A Terméktulajdonos nem egy bizottság, hanem egyetlen személy. A Terméktulajdonos képviselheti egy bizottság kívánságait a Termék Backlogban, de ha a bizottság meg szeretné változtatni valamelyik Termék Backlog elem prioritását, akkor ezt csak a Terméktulajdonoson keresztül teheti meg.

Ahhoz, hogy a Terméktulajdonos sikeresen el tudja végezni a feladatát, a teljes szervezetnek tiszteletben kell tartania a döntéseit. A Terméktulajdonos döntései a Termék Backlog tartalmában és az elemek sorrendjében nyilvánulnak meg. Senki nincs felhatalmazva arra, hogy a Fejlesztőkkel a meghatározottól eltérő követelmény-rendszer szerint dolgoztasson, és a Fejlesztők sem fogadhatnak el utasításokat másoktól.

A Fejlesztők azért felelősek, hogy a termék elkészüljön. A csapattagok különféle képességei lehetővé teszik hogy a feladatot közösen megoldják (üzleti elemzők, UX tervezők, programozók, grafikusok, tesztelők, stb.)

A Fejlesztők olyan szakemberek, akik azon dolgoznak, hogy minden egyes Sprint végén leszállítható legyen a termék egy “Kész” potenciálisan kibocsátható növekménye. A növekmény elkészítésében csak a Fejlesztők vesznek részt. A Fejlesztők maguk szervezik és menedzselik a saját munkájukat. Az így létrejövő szinergia optimalizálja a Scrum csapat hatékonyságát és termelékenységét.

A Fejlesztők az alábbi tulajdonságokkal rendelkeznek:

• Önszerveződőek. Senki – még a Scrum Mester – sem mondja meg a Fejlesztőknek, hogy miként hozzanak létre a Termék Backlogból potenciálisan szállítható funkcionalitást tartalmazó növekményeket,
• A Fejlesztők, beleértve a teljes Scrum csapatot keresztfunkcionális, és csapatként minden olyan ismerettel és készséggel rendelkeznek, ami szükséges a termék növekmények elkészítéséhez,
• A Scrum a „Fejlesztő”-n kívül nem alkalmaz külön titulust az egyes tagokra, függetlenül attól, hogy egyénenként milyen tevékenységet végeznek. Ez alól a szabály alól nincs kivétel.
• A Fejlesztők körében nincsenek alcsoportok egyes célfeladatok – pl. tesztelés vagy üzleti elemzés – elvégzésére; ez alól a szabály alól nincs kivétel, illetve
• A Fejlesztők körében az egyes tagok speciális ismeretekkel, készségekkel és szakterületi tudással rendelkezhetnek, de a felelősség a teljes Scrum csapatra, mint egy egységre hárul.

A Scrum Mester a Scrum népszerűsítéséért és támogatásáért felelős, a Scrum Útmutatóban foglaltaknak megfelelően. A Scrum Mesterek ezt az által érik el, hogy mindenkinek segítenek megérteni a Scrum elméletét, gyakorlati elemeit, szabályait és értékeit. A Scrum Mester a Scrum Csapat szolgáló-vezetője (servant-leader). A Scrum Mester segíti a Scrum Csapaton kívülieknek megérteni azt, hogy mely Scrum Csapattal való interakciójuk lesz hasznos és melyik nem. A Scrum Mester mindenkinek segít oly módon megváltoztatni ezeket az interakciókat azért, hogy azok a Scrum Csapat által létrehozott értéket maximalizálják.^[7]

A Scrum mester szerepe többrétű. Ez egy támogató vezető szerepkör, fő célja a csapat teljesítményének növelése és a munkát akadályozó tényezők elhárítása, amelyek gátolják a csapatot abban, hogy a sprint célját megvalósítsa. A scrum mester nem a csapat vezetője, (a csapat önszerveződő), hanem a csapat és a külső tényezők közötti szereplő. Ügyel arra, hogy a scrum folyamatot megfelelően alkalmazzák. Ő tartatja be a scrum szabályait. Kulcsfontosságú feladatának számít a csapat védelme és annak biztosítása, hogy a csapat az elvégzendő feladatokra koncentráljon. A scrum mester tartja mozgásban a csapatot (facilitátor), jelentős szerepet vállal az események lebonyolításában.

A Scrum mesterek nyolc feladatkörét Barry Overeem így fogalmazta meg:^[8]

• Támogató vezető, aki a csapat tagjaira és az általuk megteremtett ügyfél-érték megteremtésére összpontosít annak érdekében, hogy eredményeket érjenek el a szervezet értékeivel, alapelvekkel és üzleti célokkal összhangban.
• Facilitátor, aki a keretek tiszta meghatározásával segíti az együttműködést. Ide tartozik a megbeszélések adminisztrációja, moderálása és dokumentálása is.
• Coach, aki segít fejlődni az egyéneknek a gondolkodásmódra és a viselkedésre összpontosítva. A csapatot a folyamatos fejlődésben, míg a szervezetet a Scrum csapattal való valódi együttműködésben támogatja.
• Menedzser, aki az akadályok kezeléséért, a pazarló folyamatok csökkentéséért, a folyamatokért és a csapat egészségének, az önszerveződés határainak kezeléséért és a kultúra támogatásáért felelős. Támogatást nyújt a projekten kívüli megrendelők számára a megfelelő riportok és eszkalációs anyagok összeállításában. Folyamatosan követi a sprint állapotát és a projekt állapotát. Időben észreveszi, ha a tervek veszélybe kerülnek és a csapattal közösen kitalálja, hogy megoldható a team-en belül a probléma vagy eszkalálni kell. Utóbbi esetben megoldási javaslattal együtt eszkalál.
• Mentor, aki az agilis tudást és tapasztalatot átadja a csapatnak. Segít testreszabni a Scrum keretrendszert anélkül hogy a lényeges elemeket elhagyná vagy szembemenne azokkal. Támogatja a team-eket a módszertani elvek betartásában.
• Tanár, aki biztosítja a Scrum és más vonatkozó módszerek megértését és bevezetését.
• Akadálymentesítő, aki megoldja a csapat előrehaladását hátráltató tényezőket, figyelembe véve a problémát és a fejlesztőcsapat önszervező képességeit.
• Változáskezelő, amely lehetővé teszi egy olyan kultúra kialakulását, amelyben a Scrum csapatok virágozhatnak.

Az egyéb érintettek nem részei a scrum folyamatnak, de figyelembe kell venni őket. Az agilis szoftverfejlesztés egyik fontos aspektusa, hogy bevonják a felhasználót a fejlesztési folyamatba, a tőlük érkező visszajelzéseket figyelembe veszik a sprintek tervezésénél.

Felhasználók

Akik a szoftvert használni fogják. (A sok egyedi vásárló számára készülő szoftverek esetén a felhasználó hangját megtestesítő személy.)

Üzleti szereplők

Azok az emberek, akik lehetővé teszik a projekt létrehozását és akiknek a termék hasznot fog hozni. Közvetlenül csak a sprintáttekintő megbeszélésen (demo) vesznek részt a folyamatban. Ez az adminisztrátorokat és az igazgatókat is magába foglalja.

Menedzserek

A fejlesztésben részt vevő szervezeti egységek munkakörnyezetét teremtik meg. Nem csak a funkcionális vezetőket jelenti.

Minden sprint előtt sprinttervező megbeszélést tartanak:

• Elvégzendő feladatok kijelölése a termék teendőlistájáról (product backlog) a terméktulajdonos közreműködésével.
• sprint teendőlistájának előkészítése, amely a teljes csapat figyelembevételével részletezi az egyes részfeladatok időszükségleteit.
• Annak meghatározása és kommunikálása, hogy mennyi feladat elvégzése várható el az aktuális sprint során.
• 4 hetes sprint esetén maximum 8 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.

Nevéből adódóan minden nap (a demó napja kivétel lehet) megtartott esemény, az angol szakirodalomban Daily Scrumnak vagy Daily Standupnak nevezik. A napi megbeszélés célja, hogy a csapat tagjai összehangolják tevékenységüket.

Az időpontra nincs szabály, lehet napindító megbeszélésként tartani, ez a notóriusan késő tagokra tekintettel nem feltétlenül szerencsés. Népszerű időpont a státuszmegbeszélésre az ebéd utáni időszak. Az emberek gyakran elpillednek az ebédtől, tehát egy élénk állómeeting felfrissítheti őket, vélik egyes Scrum-szakértők. Azt is vélik, hogy mindenki dolgozott már ebéd előtt, ezért az emberek nem a privát dolgaikon gondolkoznak éppen, hanem a munkájukon. Számos egyéb szempont befolyásolhatja az időpont kiválasztását.

A következők vonatkoznak rá:

• Bárki részt vehet, de főszabályként csak a Scrum csapat tagjai beszélhetnek.
• A megbeszélés ideje 15 percre korlátozott
• A résztvevők általában állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el).
• Minden nap ugyanazon a helyen és ugyanabban az időpontban tartják.

A megbeszélés során minden résztvevő ehhez hasonló kérdéseket válaszol meg:

• Mi az, amit a tegnapi megbeszélés óta csináltam? (vagy mit tanultam?)
• Mi az, amit a mai nap tervezek csinálni?
• Vannak-e akadályok, amik gátolnak a saját és a sprint célok elérésében?

Az akadályok elhárításában a Scrum Mester segít a csapatnak.

A sprint végén két megbeszélést tartanak: „Sprintáttekintés” és „Visszatekintés”

• Annak áttekintése, hogy mely munkák készültek el és melyek nem.
• Az elkészült munka bemutatása a terméktulajdonos és a fejlesztésben érdekeltek részére (demo).
• A legkisebb, értéket adó, működő terméket már be lehet mutatni (a létrehozott termék a stakeholder kívánalmainak már funkcionálisan megfelel) A még nem működő elemeket nem lehet bemutatni.
• 4 hetes sprint esetén maximum 4 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.

• A csapattagok véleményt alkotnak az elmúlt sprintről. A vélemény lehet egy puszta benyomás is, nem kell kidolgozott, szilárd álláspontnak lennie.
• Javaslatokat tesznek a folyamatok továbbfejlesztésére. A javaslatoknak nem kell kiérleltnek lenniük, a kidolgozás nem a visszatekintés része.
• Két kérdés merül fel a megbeszélésen: Mi az, ami jól ment a sprint alatt? Mi az, amit a következő sprint során jobban lehetne csinálni?
• 4 hetes sprint esetén maximum 3 óra hosszúságú, rövidebb sprint esetén ez az esemény is rövidebb.

Az agilis fejlesztés a működő szoftvert előnyben részesíti az átfogó dokumentációval szemben. A Scrum 3 munkaanyag (artifact) meglétét írja elő, ezek a Termék teendőlista, a Sprint teendőlista és a Növekmény (Increment).^[9]

A „termék követelménylistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelményleírásokat. A lista elemei lehetnek funkciók leírásai, kívánságok, ötletek, stb., amelyek prioritás szerint vannak rendezve. Tulajdonképpen azt tartalmazza, hogy mi a fejlesztés célja. A lista szabadon szerkeszthető bárki által, és becsléseket tartalmaz a bejegyzések üzleti értékére és ráfordításigényére vonatkozóan. A becslések abban segítik a terméktulajdonost, hogy meghatározza a bejegyzések sorrendjét és bizonyos mértékig a prioritásukat. Ha például a „helyesírás-ellenőrzés” és „repülőgép-szimulátor” funkcióknak azonos az üzleti értékük, akkor a kevesebb fejlesztési ráfordítást igénylő funkció fog magasabb prioritást kapni, hiszen annak jobb a megtérülése. A termék követelménylistája a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordításigényt a fejlesztők határozzák meg. A követelmények formátuma gyakran az ún. user story (felhasználói történet).

A sprint teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a sprint során megvalósítandó funkciókat. Ez egyes funkciókat részfeladatokra bontják. A felbontást célszerű úgy elvégezni, hogy egy részfeladat 4-16 óráig tartson. Ilyen szintű részletezettség mellett a csapat összes tagja pontosan érti, hogy mit kell elvégezni, és mindenki kiválaszthatja a neki legmegfelelőbb részfeladatot. A sprint teendőlistájában levő részfeladatokat nem rendelik személyhez, inkább a csapattagok választják ki azokat a meghatározott prioritások, szükségletek és a csapattag képességeinek megfelelően.

A sprint teendőlistája a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy Feladattáblát (angolul Task Board) állítanak össze, amely követi és beállítja a teendők állapotát („elvégzendő”, „folyamatban”, „elvégzett”, stb.) a sprint során.

A Növekmény (más szóval Inkrementum) a Sprintben leszállított Termék Backlog elemeknek és az összes megelőző Sprint során szállított növekmények értékének összessége. A Sprint végére az új növekménynek “Kész”-nek, azaz használhatónak kell lennie, és meg kell felelnie a Scrum Csapat által meghatározott “Kész” definíciójának. A növekmény egy ellenőrizhető, “Kész” munkatermék, ami a Sprint végén az empirikus működést támogatja. A növekmény egy lépés egy vízió vagy cél felé. Felhasználható állapotban kell lennie független attól, hogy a Terméktulajdonos úgy dönt, hogy ténylegesen kibocsátja-e azt.

Az alábbi eszközök támogatják a haladás mérését és az előrejelzések elkészítését. Használatuk nem kötelező, értelmezésük kellő szaktudás birtokában hasznos információ a folyamatokat érintő döntések meghozatalához.

Burn down chart (egyfajta napi eredménykimutatás)

Mindenki számára elérhető grafikon, amely mutatja a sprint teendőinek a listájából hátralevő munka mennyiségét. Minden nap frissítik, egyszerű módon jeleníti meg a sprint állapotát.

Burn up chart

A sprint feladatlistáján szereplő feladatok számát és az elvégzett feladatok számát ábrázolja közös grafikonon, napi frissítéssel. Lényegében a burn down chart dekompozíciója.

Sebesség (Velocity)

A sprint tervezésekor a csapat a termék-teendőlista (product backlog) elemeihez a kivitelezés várható nehézségének függvényében számszerűsíthető értéket rendel. A becslésre több kidolgozott módszer is rendelkezésre áll. A sprint során elkészített elemek összpontszáma a csapat sebessége. Új csapatok esetén a sebesség jellemzően sprintről-sprintre nő, tapasztalt csapatok esetén közel állandó. A sebesség segítségével jól becsülhető, hogy az adott pillanatban ismert termék-teendőlista mikor fogy el.

• A megrendelő a fejlesztő csapat részévé válik.
• Gyakoriak a köztes szállítások működő funkcionalitással, a fejlesztés növekményes. A köztes állapotokat is validálják és ellenőrzik, hogy ne csak a végén derüljenek ki a problémák, legyen idő kijavítani őket.
• Gyakori kockázatelemzés a fejlesztőcsapat részéről.
• Napi megbeszélés, ahol mindenkit megkérdeznek, hogy:
  • Mit csinált tegnap óta.
  • Mit tervez holnapra.
  • Vannak-e problémái, amik meggátolják a célja elérésében.
• Átlátható tervezés és modularizáció, azaz lássa mindenki, hogy ki miért felel és milyen határidővel.
• Gyakori találkozók, amelyeken figyelemmel kísérik a haladást.
• Semmilyen problémát nem söpörnek a szőnyeg alá. Mindenkit meghallgatnak, aki felismer és ismertet egy váratlan problémát.
• A munkahely és a munkaidő legyen hatékony. A több munkaóra nem feltétlenül vezet több eredményre.

A Scrumot kis csapatokra tervezték. A csapattagok kommunikációját próbálja javítani. Sok szoftverterméket viszont egyetlen fejlesztő készít egyedül, de a Scrum-elvekből ő is tanulhat, erre találták ki a módszertan Solo Scrum nevű változatát.

A munkahelyi zaklatás újszerű formája a Scrum bullying. A munkahelyi zaklatás nem újkeletű jelenség, a Scrum bullying ennek egy új válfaja, amit agilis szervezetek fejlesztése kapcsán figyelhető meg. A zaklatók jellemzően az agilis keretrendszert előíró dogmaként értelmezik. Ennek az a kockázata, hogy a jó szándék ellenére a kioktató/előíró stílus megfojtja a pszichológiai biztonságot,^[10] elbizonytalanítja a letorkolt munkavállalót, így nem fog a továbbiakban bátran próbálkozni az újonnan elsajátított agilis szemlélet alkalmazásával.

Az Agilis Manifesztó szerzőinek 12 alapelvére reflektálva a Budapesti Metropolitan Egyetem^[11] vezetésével 24 hazai agilis szakember megfogalmazta^[12][13] ajánlásait a hatékony agilis coaching mellett, a scrum bullying visszaszorításának érdekében.

1. Elégítsük ki ügyfeleink, az általunk támogatott szervezet munkavállalóinak agilitással kapcsolatos igényeit azáltal, hogy poroszos szigorral való letorkolás helyett a napi gyakorlatban mutatunk példát a mikéntekre.
2. Legyünk mi, agilis coachok és szakértők is nyitottak a változásra, igyekezzünk az ügyfél igényeihez igazítani az agilis implementációt a keretek megtartása mellett.
3. Sok, kis lépésben haladjunk, nagy big bang helyett, hogy az ügyfél értékteremtése folyamatos maradjon. Nem teremthetünk válságot a hirtelen bevezetett agilis eszközök által.
4. Agilis coachként dolgozzunk közösen a támogatott csapattal a probléma megoldásán.
5. Bízzunk azokban, akiket támogatunk, bátorítsuk őket, hogy próbálkozzanak, hibázzanak és tanuljanak a hibáikból. Hallgassunk és figyeljünk.
6. Lehetőleg élőszóban adjunk visszajelzést, építő jelleggel, soha ne alázzuk meg a fogadó felet. Gyakran a jó kérdések segítenek leginkább abban, hogy a vezetők/csapatok maguk találják meg és magukénak érezzék a megoldásaikat.
7. Sikerünk mércéje a működő agilis csapatok és szervezetek és azok értékteremtő képességének növekedése.
8. Akkor dolgoztunk fenntarthatóan, ha támogatásunk következményeképp a csapatok és a szervezet önállóan képes tovább fejlődni.
9. Tartsuk fenn az önfejlesztés iránti folyamatos igényünket, ismerjük tudásunk határait.
10. Az egyszerűség nagyszerű – nem lövünk ágyúval verébre.
11. Támogassuk az önszerveződést, ezért a csapatokat nem az egyes agilis gyakorlatokra tanítjuk be, hanem a szemléletet átadva fejlesztjük őket, így képesek lesznek egy idő után maguk megválasztani az eszközeiket. Minden helyzet és minden csapat más és más. Dolgozzunk a rutinunk alapján, de soha ne dolgozzunk rutinból.
12. Kérjünk rendszeres időközönként visszajelzést a munkánkkal kapcsolatban; ügyféltől és szakmai közösségtől.

• story – a termék funkcióinak magas szintű, megrendelőközpontú leírása
• product backlog – a projekt során megvalósításra váró teendők listája, fontossági sorrendben
• sprint backlog – konkrét feladatok a következő sprintre
• backlog item – teendő
• sprint (futam) – a sprinttervezés során kiválasztott teendők megvalósítására szánt rövid iteráció (1–4 hét)
• daily standup – rövid napi találkozó, ahol megbeszélik az eredményeket, az akadályokat és a következő teendőket
• sprint planning session – megbeszélés, amelyen a következő sprint teendőit definiálják
• sprint retrospective – visszatekintés, célja a fejlesztési folyamat gyengeségeinek elhárítása, a hatékonyság javítása. Minden csapattag elmondja a véleményét az utolsó sprinttel kapcsolatban, és a csapat megegyezik, hogy mit változtatnak a fejlesztési folyamaton a következő sprint során.
• sprint burn down chart – kimutatás a napi eredményekről a sprint során
• DoD – Definition of Done – a megvalósításra irányuló ígéret a PO felé; lehet plain szöveg vagy ellenőrző lista

• (PDF) Ken Schwaber, Jeff Sutherland (2011). The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game
• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams elérés 2007. március 15.
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process elérés 2006. augusztus 15.
• (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum elérés 2006. augusztus 15.
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google elérés 2014. január 10.
• (video) Ken Shwaber in Scrum et al. Archiválva 2008. január 26-i dátummal a Wayback Machine-ben elérés 2008. január 19.

• Hivatalos Scrum Guide fordítások
• Scrum in five minutes - elérés 2008. február 7.
• Scrum Alliance - elérés 2008. február 7.
• Scrum et al - Google-ös interjú Ken Schwaber-rel. - elérés 2008. február 7.
• Scrum and XP from the Trenches - elérés 2008. február 7.
• Scrum articles directory - elérés 2008. február 7.
• Agile Alliance's Scrum library - elérés 2008. február 7.
• Agilo For Scrum (Open Source Scrum Tool) - elérés 2008. február 7.
• scrum.org
• International Scrum Institute
• iceScrum (Open Source Scrum Tool)
• Mi az a scrum?
• Az agilis coach 12 alapelve
• Mit tanultam a Scrumból Archiválva 2020. január 13-i dátummal a Wayback Machine-ben (angol)

• Agilis szoftverfejlesztés