Scrum Guide 2020 - Kell egy csapat, de csak egy

Az új Scrum Guide első fejezetében a Scrum definíciójában azzal kezd, hogy a Scrum egy olyan egyszerű keretrendszer, amely segít csapatoknak abban, hogy értéket teremtsenek összetett problémák adaptív megoldásával. Tehát a Scrum csapatokról, emberekről szól. A második mondat pedig azzal folytatja, hogy a Scrum működtetéséhez szükséges egy Scrum Master, aki megteremti a környezetet ahhoz, hogy a fejlesztők és a Product Owner hatékonyan dolgozhassanak. Konkrétan három folyamatosan ismétlődő lépést ír le:

1. A Product Owner sorrendbe rakja a munkát.
2. A Scrum Csapat a munkát értékes termékké alakítja.
3. A Scrum csapat és az érdekeltek megvizsgálják az eredményeket és szükség szerint változtatnak a következő iterációban.
4. És kezdjük elölről, vissza az 1-es pontra.

Mit olvashatunk ki ebből? Az első, hogy sokkal általánosabb a megfogalmazás, mint eddig, azaz szinte bármilyen összetett munka végezhető ezzel a gondolkodással. Fogjunk egy emberekhez jól értő személyt, bízzuk meg azzal, hogy működtessen egy csapatot, akik egy másik személy által fontosnak ítélt munkát elvégeznek, és rendszeresen megmutatják a megrendelőnek, hogy jó-e az irány, és merre folytassák. Majd ezt addig ismétlik, amíg a megrendelő úgy érzi, nem érdemes tovább fejleszteni a dolgot, mert már nem éri meg.

Két dolog szúrhat szemet. Már nincs Development Team (fejlesztő csapat), minden munkát a Scrum Team (Scrum csapat) végez. A másik, hogy a Scrum Master nem opcionális, nem egy „tök jó, ha van” szerep, hanem központi eleme a Scrumnak. No nem mintha eddig nem így lett volna, de nem volt ennyire hangsúlyos. És ahogy a bevezetőből megtudjuk, a Scrum minden eleme valamilyen célt szolgál, és ha valaki ezeket önkényesen kihagyja, például nem alkalmaz Scrum Mastert, akkor azzal csak elfed valamilyen problémát, és így az egész rendszer akár hasznavehetetlenné is válhat.

HOVÁ LETT A DEVELOPMENT TEAM?

Az igazság az, hogy eddig se volt igazán külön csapat, de ezt sok helyen félreértették. A fejlesztőket azért nevezték fejlesztő csapatnak, mert vannak dolgok, amelyeket önállóan végeznek, és vannak döntések, amelyeket ők hozhatnak meg; még pontosabban, van saját felelősségi körük. Tehát nem szervezési egység, inkább csak nevezéktani fogalom volt. Ez azonban számos félreértéshez vezetett. Az egyik, hogy a fejlesztő csapatot sokan keverték a Scrum Csapattal, de azt a káros nézetet is erősítette, hogy a Scrum Master és Product Owner afféle kívülállók. Ez a Scrum Master esetében volt a legveszélyesebb, ahol a több csapat között megosztott Scrum Master szerephez vezetett.

Az új útmutató immár egyértelműen fogalmaz: a Scrum Csapat egy Scrum Masterből, egy Product Ownerből és Fejlesztőkből áll. Egyértelmű, hogy a Scrum csapaton belül nincs kisebb csapat, nincs hierarchia, nincs semmiféle belső szerkezet, csak három egyenlő szerep, különféle felelősségekkel. Mindenki egyenlő, és mindenki felelős a csapat vezetéséért, hiszen a csapat önvezető (self managing). Ugyanezzel a mondattal az önvezetőt is rendbe rakták. Figyeljük meg, hogy a felsorolás a Scrum Masterrel kezdődik, ami ismét hangsúlyozza a szerep nélkülözhetetlen mivoltát.

A Scrum Csapat tehát egy csapat, aki együtt végzi a munkát, mindenkinek meg van a maga szerepe és felelőssége. A tagjai együtt döntik el, ki, mikor, mit és hogyan tesz azért, hogy az iterációban minél több és a Definition of Done-nak megfelelő termék darab készüljön el.

MINDEN SZAKTUDÁS KELL

A Scrum csapat akkor képes működni, ha minden szaktudás megvan benne, ami szükséges a termék előállításához. Ez utóbbi alól csak nagyon speciális és ritka, illetve ritkán szükséges szaktudás lehet kivétel.

Csapaton belül vagy kívül? A fintech területen működő vállalkozásomban például jogász nem volt tagja a csapatnak, de a Product Owner rendelkezett a megfelelő jogi tudással, és szükség esetén gyorsan rendelkezésre állt a jogász is, sokszor órákig tartó közös agyalásra. Egy banki projektben viszont volt jogász a csapatban, mert a termék sokkal inkább banki szakmai, mint informatikai jellegű volt. Ez is mutatja, hogy a Scrum Guide inkább útmutató, mint szabályok gyűjteménye. Az ideális megoldást gyakran csak kísérletezéssel lehet megtalálni. Nem szégyen tehát, ha valamit nem tudunk, inkább erény, ha kimondjuk és kísérletezéssel találjuk meg a megoldást.

Hogy is kell ezt érteni? Úgy, hogy minden olyan képességnek meg kell lenni a csapatban, ami a termék fejlesztéséhez folyamatosan szükséges. Nem lehet szükség külső szereplőkre, másik csapatra, nem lehetnek függőségek. A csapatot úgy kell összeválogatni, hogy külső függőség nélkül tudjon terméket előállítani, így tud felelősséget vállalni a kiváló és gyors munkáért. A külső függőségek lassítják a munkát és rombolják a morált. Természetesen vannak kivételek, olyan speciális, ritkán szükséges szaktudás, ami fölösleges lenne, ha a csapaton belül lenne, vagy ami egyenesen kivitelezhetetlen, de ennek valóban igen ritkának kell lennie. Ha például nemzetközi terméket készít a csapat, nem kell a világ összes nyelvét beszélő ember a csapatba, de olyan kell, aki ért a nemzetközi termékek fejlesztéséhez, lokalizációhoz, és képes szervezni mondjuk a fordítási munkákat külső fordítókkal. Ilyen speciális tudás lehet még a jogász, fotóművész, grafikus, de egy nem informatikai projektben akár az informatikus is. Ha azonban rendszeresen szükség van egy adott tudásra, akkor a csapaton belül a helye. Egy banki termék esetében például a jogszabályi feltételeknek való megfelelés miatt elképzelhető, hogy egy jogász állandó tagja kell legyen a csapatnak.

ÖNSZERVEZŐBŐL ÖNVEZETŐ

Érdekes apróság, hogy a self-organizing (önszervező) szót lecserélték a self-managing (önvezető) kifejezésre. Igazából ez nem változtat semmit, a lényeg, hogy a Scrum csapat dönti el, külső beavatkozás nélkül, hogy min, mikor, ki és hogyan dolgozik. A Scrum csapaton belül azonban vannak szerepek, például a „min dolgozik” kérdést a Product Owner határozza meg a Product Backlog segítségével

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

Sokan félreértették, hogy a self-organizing az a csapat összeállítását is magában foglalja. Pedig a Scrum alkotói többször elmondták, hogy az önszerveződés az csakis az adott szervezet által megadott kereteken belül értelmezendő. Most már egyértelmű, hogy a munka csapaton belüli szervezésére utal a self-management kifejezés.

MEKKORA CSAPAT IDEÁLIS?

A Scrum csapat mérete „tipikusan” nem több, mint 10 fő, írja a Scrum Guide. Hogy miért tipikusan? Azért, mert bár láttam 12 fős csapatot jól dolgozni, ez igen ritka. A tagok közötti interakciók száma ugyanis radikálisan nő a résztvevők számával.

Ahogy az útmutató is ajánlja, tíz fő fölött érdemes elgondolkodni a csapat két csapattá alakításán. Olvastam már olyat is, aki viszont a 4 fős csapatra esküszik, mert ott a létszám miatti kommunikáció igen kevés és így jobb az információ áramlása. Bizonyos típusú és komplexitású termékeknél ezt is el tudom képzelni, bár az ilyenekénél magán a Scrum alkalmazásán is érdemes elgondolkodni: erősen kísérleti típusú fejlesztéseknél egy másik keretrendszer jobb eredményt hozhat. Egy pici csapatnál a Scrum Master vagy a külön Product Owner költsége is elképzelhető, hogy meghaladná azt az előnyt, amit nyújtani tud, bár az új útmutató nem tiltja, hogy a Product Owner és a Scrum Master is végezzen fejlesztői munkát. Mint mindig, az ilyen dilemma esetén az Inspect & Adapt (vizsgálunk és beavatkozunk) elvet ajánlom, azaz kísérletezzünk, és nézzük meg, mit lehet tanulni a tapasztalatokból. Ami a legtöbb csapatban beválik, az hat fejlesztő és egy-egy Product Owner és Scrum Master, mint nyolcadik utas.

KINEK MI A DOLGA?

Felelős vagy felelős? Ha szótárban nézzük, az angol „responsible” és „accountable” szavak fordítása egyaránt „felelős”. Ez komoly félreértésekhez vezethet, ezért érdemes tisztázni a különbséget, a két szó ugyanis messze nem szinonimája egymásnak. A különbség az, hogy aki responsible, annak feladata az adott dolog elvégzése, míg aki accountable, az felelős, azaz felelősségre vonható érte. Az accountable személy nem feltétlenül végzi el az adott feladatot, de úgy kell intéznie, hogy valaki elvégezze, azaz ő tartja a hátát, ha nem sikerül ezt elérni. Szerencsére a Scrum Guide magyar fordításában ezt jól kezelték, de aki az angolt olvassa, annak érdemes tudni, mi a különbség a két kifejezés között.

Az egész csapat felelős azért, hogy minden tevékenység, amely a termék előállításához szükséges, el legyen végezve. Hogy egyértelmű legyen, a Scrum guide fel is sorol több dolgot, olyanokat is, amiket sokan nem szoktak a csapathoz sorolni. Ilyen például a megrendelővel való kapcsolattartás, amit például sokan a Product Owner szerephez rendelnek. Kiemelném, hogy a csapat felhatalmazott (empowered) a munka önálló elvégzésére, azaz a szervezet vezetősége nem szólhat bele a munkába, ha azt várja a csapattól, hogy kiváló terméket fejlesszen.  A Scrum csapat felelős azért, hogy értéket termeljen, bármi is legyen az. Ezen belül a három szerepnek vannak saját felelősségei, amivel a sorozat egyik következő cikkében fogunk foglalkozni, csakúgy, mint a csapat alapvető céljával a Product Goal-lal.

A LÉNYEG NEM VÁLTOZOTT

A Scrum csapat továbbra is az önállóságra és felelősségvállalásra épül. Mindenki egyenlő, de vannak szerepek, amelyek felelősségi körei és feladatai eltérőek.

Összefoglalva:

• A Scrum Master alapvető szükségessége most már félreérthetetlen.
• Nincs csapat a csapaton belül, csak egy csapat van.
• Finomították az önszervezés fogalmát önvezetőre.
• Továbbra is kezelhető méretű csapatokkal dolgozik.
• A feladatok egyértelműbbek, a keresztfunkcionalitás erősebben van jelen.
• A cél is egyértelműbb.

Ahogy azt a sorozat indító cikkében kifejtettem, minden új, de semmi sem változott. Aki vette a fáradtságot és alaposan utána járt, mit is gondoltak a „költők”, az eddig is úgy alkalmazta a Scrumot, ahogy a mostani leírásban szerepel. Remélem az új dokumentum segít a helyes út megtalálásában és több csapat tud majd jobban dolgozni, nagyobb értéket teremteni a Scrum Guide 2020 alkalmazásával.