Jeff Sutherland: Hogy kezdődött a SCRUM
A legjobb módja annak, hogy elkezdjük megérteni a Scrumot, az, ha látjuk működés közben. Először kereskedelmi szoftvertermékek fejlesztéséhez használtam a Scrumot, azután arra, hogy más szervezetek is tudjanak rendszereket építeni. Az első szervezet, ahol a Scrum tesztelésére és finomítására lehetőség adódott, az Individual, Inc. volt 1996-ban.
Az Individual, Inc. gondban volt, és a vezetői azt remélték, hogy a Scrum segítségükre lehet. A cégnek volt egy online hírszolgáltatása, a NewsPage. Ezt eredetileg szabadalmazott technológiával fejlesztették, majd a licencet kiadták cégeknek. Az internet térhódításával az Individual, Inc. a Personal (vagyis személyre szabott) NewsPage-et (a továbbiakban PNP) weboldalként kezdte működtetni magánszemélyek részére.
Nyolc magasan képzett mérnökből állt a PNP termékfejlesztő csapata. Bár nem ez volt a legjobb csapat, amivel valaha is dolgoztam, kifejezetten rossz híre volt az Individual, Inc.-n belül. Azt mondták, a PNP csapat nem tudott előállítani semmit, „totális csőd” volt az egész. Ez az elképzelés onnan származott, hogy közel kilenc hónapja semmi újdonság nem jelent meg a PNP terén. 1996-ban jártunk, amikor az internettel felgyorsult idő még nem uralkodott el az iparágon, de a kilenc hónap már akkor is bőven túl sok volt. Amikor erről a helyzetről beszélgettem a marketinggel, a termékmenedzsmenttel és az értékesítéssel, azt mondták, nem értik a problémát. Félre nem érthető szavakkal szokták elmondani a PNP csapatnak, hogy mit akarnak, de a kért funkciók és egyebek sosem jöttek létre. Amikor a helyzetről az elégedetlen PNP csapattal beszéltem, úgy tűnt, sosem hagyták nekik, hogy kifejlesszenek (végigfejlesszenek) egy kódot. A mérnökök a „tűzriadó” kifejezést használták. A csapat mindig végiggondolta, hogyan lehetne megteremteni a kért funkciókat, elkezdett dolgozni rajta, majd hirtelen az egész félre lett dobva a következő friss és csodás új ötlet kedvéért. Akármikor elvállalt a PNP csapat egy projektet, nem jutott elég ideje arra, hogy a figyelmét a feladatra összpontosítsa, mert a termékmenedzsment máris megváltoztatta az elképzeléseit, mert vagy a marketing mondta nekik, hogy csináljanak valami mást, vagy az értékesítésnek jutott eszébe valami csodás ötlet, amit azonnal meg kellett valósítani.
A helyzet tarthatatlan volt. Mindenki frusztrált volt, és mindenki egymás ellen fordult. Versengés jelent meg a horizonton. Megkértem Rustyt, a termékmenedzsment vezetőjét, hogy állítson össze egy listát mindarról, aminek az emberek szerint bele kell kerülnie a PNP-be. Neki már megvolt a saját listája, és nem akaródzott körbemenni, és mindenkitől megkérdezni, hogy még ők mit akarnak. Azt mondta, „Ha a PNP csapat azt sem képes lefejleszteni, amit mi kérünk tőlük, mi a fenének fáradjunk azzal, hogy újra listázgassunk?” Azért mégiscsak megtette, amit kértem, és összeállított egy átfogó listát. Találkozott a PNP csapattal is, hogy lássa, tisztában vannak-e az elvárások lefejlesztéséhez szükséges technológiai változásokkal. Ezeket is hozzáírta a listához. Ezt követően rangsorolta a lista elemeit. A PNP csapat megadta, hogy várhatóan mennyi időt vesz igénybe egy-egy tétel fejlesztése. Rusty ennek megfelelően módosított a prioritásokon, amikor nyilvánvalóvá vált, hogy bizonyos nagy piaci hatással bíró fejlesztésekhez nem volt szükség sok munkára, vagy más fejlesztések, amelyeknek kis paci hatása lett volna, sokkal több munkát igényeltek volna, mint amennyit értek.
Megkértem Rustyt, hogy módosítsa a termékkel kapcsolatos kívánalmak menetét. Az emberek akkoriban egyenesen a PNP csapathoz mentek, ha új dolgokat, új funkciókat akartak a termékkel kapcsolatban bevezettetni. Azt gondoltam, jóval produktívabb lenne a dolog, ha csak egy helyről kapnák a munkát, és nem szakítanák folyton félbe az aktuális munkájukat. Hogy ezt megvalósítsa, Rusty azt javasolta, hogy mindenki csak hozzá vigye az igényeket. Az igényeiket hozzáadta a listához. Ezt követően újrarangsorolta a listát annak megfelelően, hogy mit mondtak a fejlesztés fontosságáról, mi volt a becslése a munkaidőre és munkamennyiségre (ezt ő határozta meg, miután beszélt valakivel a PNP csapatban), és milyen egyéb feladatok voltak a listán. Azt javasoltam Rustynak, hogy írjon fel minden javaslatot a listra, így sosem kellett nemet mondania. Ehelyett csak priorizálnia kellett. Nem voltak többé „rossz” ötletek, csak olyanok, amelyeket valószínűleg sosem valósítottak meg. Rusty azt javasolta mindenkinek az Individual, Inc.-nél, hogy a PNP csak az ő rangsorolt listája alapján ütemezze be a munkáját. A listáját elkezdte Product Backlog listának (termék-várólista) nevezni.
Rusty kedvelte a termék-várólistát. Soha nem kellett véglegesítenie egy termékmegjelenéssel kapcsolatos elvárásokat. Ehelyett csak fenntartott egy listát, amelyben mindig az állt, hogy mire van szükség a termékben, mindig az aktuálisan rendelkezésre álló legjobb információk szerint. A lista mindig friss és mindig látható volt. A termék-várólistát táblázatos formában tartotta egy közös és mindenki által elérhető szerveren, vagyis mindenki tudta, hogy legközelebb milyen fejlesztés történik a terméken. Előny volt az is, hogy a PNP csapatot nem zaklatták olyan sokszor. Az Individual, Inc. aprócska cég volt, ahol mindenki ismert mindenkit. Korábban nehéz volt meggátolni, hogy az emberek egyenesen a PNP csapathoz menjenek a kéréseikkel. Néha megpróbálták megkörnyékezni mérnök barátjukat, szívességet kérve: „most az egyszer, be tudnád ezt a kis fejlesztést suvasztani?” De Rusty elvárta, hogy a csapat mérnökei álljanak ellen. Ő lett az elvárások felügyelője, az elvárásoké, amelyek rangsor szerint szerepeltek a termék-várólistán.
Azt javasoltam, hogy a cég sajátítson el egy gyakorlatot, amit korábban használtam: a szakaszosan ismétlődő, „járulékos” fejlesztést. Minden szakaszt egy sprintnek neveztem, a szakasz eredményeit pedig termékhaszonnak, termékfejlődésnek. Azt javasoltam, hogy vezessük be a sprinteket, hogy a PNP csapatot ne zavarjuk a termék fejlesztésére való koncentrációban. Nem kell újra és újra megkérdezgetni tőlük, hogy „Na, hogy megy, készen állsz a következő fejlesztésre? Elkészítetted a legutóbbit?” A sprinteknek az volt a célja, hogy a csapat kezébe eszközt adjunk arra, hogy maga ossza be az idejét. Azt is javasoltam, hogy minden sprintnek adott hossza legyen. A PNP csapat 30 napot kért, amire azt gondoltam, elég idő ahhoz, hogy létrehozzanak és teszteljenek is egy termékfunkció-fejlesztést. A csapat azt is javasolta, hogy minden sprint végén a fejlesztéseket aktiváljuk a webszerveren. A csapat havi rendszerességű internetes frissítéseket javasolt! Eladdig nekem a dobozba csomagolt, fóliázott szoftverekkel volt csak tapasztalatom, ahol az új megjelenéseket el kellett juttatni minden felhasználóhoz, akiknek aztán maguknak kellett beütemezni azok futtatását. Mivel a PNP internetes termék volt, csak egy helyen kellett update-elni ahhoz, hogy minden felhasználó kiélvezhesse az előnyeit. Persze ha a csapat valami olyat élesített, ami nem működött, az is rögtön érintett minden felhasználót, vagyis a tesztelés a szokásosnál is fontosabb lett.
A PNP csapat összeült Rustyval, hogy eldöntsék, mit kell fejleszteniük az első sprintben. Sok egyezkedés zajlott ezen a meetingen, részletekbe menőleg megbeszélték az elvárásokat, és hogy miként lehet ezeket megvalósítani. Néhány munkaóra-becslés megváltozott, amikor a részleteket végiggondolták. Néhány alacsonyabb prioritású termék-várólistás elemet bevettek az első sprintbe, mert gyakorlatilag szinte munka nélkül megvalósíthatóvá vált, amikor egy magasabb prioritású elemhez létrehoztak egy kódot. A meeting egy álló napig tartott. A meeting végére a csapatnak már volt elképzelése a tervezés és a megvalósítás részleteiről. Mindenki tudta, mit fog tenni a PNP csapat a következő harminc napban.
Persze a PNP csapatot még mindig számtalanszor megkeresték (maga Rusty is), hogy fejlesszenek olyan funkciókat, amelyek nem szerepeltek a termék-várólistán az adott sprintre. A válasz mindig ugyanaz volt: ezeknek az embereknek várniuk kellett, és a kéréseiket felíratni a termék-várólistára. Ha az elvárásuk csúcsfontosságú, top priority lett, akkor a következő sprintben lehetett megvalósítani ezeket. Mivel a sprint csak harminc napig tartott, mindenki el tudta fogadni, hogy a sprint végéig várnia kell.
A PNP csapat anélkül dolgozott a sprint során, hogy félbeszakították volna a munkáját, leszámítva a terméktámogatási és karbantartási elvárásokat (bugok stb.). A PNP még mindig egy kicsit ingatag alapokon állt a régi „quick and dirty” eljárások miatt, amelyeket a „vészhelyzetként” felmerülő funkciókérések esetén bevetettek (quick and dirty: gyors megoldás, amely nem tökéletes, nem elegáns és nem is igazán jó, de ideiglenesen megoldja vagy elleplezi az adott problémát, és gyorsabb, könnyebb megvalósítani, mint a megfelelő megoldást). Akkoriban az volt a szokás, hogy a kezdőbb, kevesebb ideje ott lévő programozók hajtották végre a javításokat. Ám ezek a mérnökök nem ismerték eléggé a kódot ahhoz, hogy ki tudják javítani. Hogy megoldjuk ezt a problémát, a következőt vezettem be: aki írja a kódot, örökre az lesz a birtokosa. Noha ez valamelyest visszavetette a PNP csapatot abban, hogy 100%-osan tudjanak koncentrálni a sprintbe tartozó feladatokra, ezzel gyorsan fejlődésnek indult a kódok minősége.
A sprint ideje alatt a PNP csapat megkérdezett engem, hogy milyen mérnöki technikákat használjanak, milyen dokumentációra van szükség és milyen tervekre van szükség. De végül megegyeztünk abban, hogy a csapat dönti el, hogy hogyan hajtja végre a feladatát. Különösen, hogy mindenki örökös tulajdonosa maradt az általa írott kódnak. Ennek ellenére kikötöttem, hogy a PNP csapatnak minden sprintben létre kellett hoznia a termék frissített technikai leírását, amellyel érthetővé vált a termék és a kódja.
A sprint végére a PNP csapat létrehozta a fejlesztéseket, amelyeket elvállalt – és többet is. Mivel most először lehetőségek kapott rá, hogy a munkájára koncentrálhasson, a vártnál többet teljesített. A csapat készen állt rá, hogy bemutassa, miben fejlődött a termék az elmúlt hónapban. Rusty megkérte a csapatot, hogy mutassa be mindezt a menedzsmentnek és néhány ügyfelünknek. A közönség elégedett volt, és rögtön engedélyezte is a csapatnak, hogy a fejlesztéseket feltegyék a termék webszerverére. Kilenc hónap terméketlenség után a PNP csapat új frissítést hozott létre egy hónap alatt. A csapat ezt követően újra és újra megismételte ezt a teljesítményt. Mielőtt távoztam onnan, öt újabb sprint fejlesztéseit élesítették a webszerverre.
Miközben a PNP csapat az első sprinten dolgozott, a cég többi része továbbra is folyamatosan kérte, hogy tegyenek meg nekik „szívességeket”. A csapatnak nem volt könnyű elutasítania ezeket a kéréseket, különösen egy ilyen kis cégben, ahol az emberek mind barátok voltak. Eldöntöttem, hogy én leszek a rosszfiú. Bevezettem egy gyors, naponta megtartott meetinget, ahol a csapat minden tagja elmondta, hogy éppen mit csinál. Ha észrevettem bármit, ami nem volt benne a termék-várólistában arra a sprintre, a meeting után elbeszélgettem az adott csapattaggal. Megkérdeztem, hogy ki kérte meg az extra munkára. Azt az utasítást adtam, hogy ne hajtsa végre a munkát. Odamentem ahhoz, aki megkérte a munkára, és elmagyaráztam, hogy miért nem dolgozunk a kérésén, majd elmentem Rustyhoz, és informáltam a szabálysértésről. Biztosítottam, hogy a csapat csak azon dolgozzon, amiben megegyeztünk, és semmi máson. Én lettem az ütköző a csapat és a versenyből származó nyomás, a változó elvárások káosza között. Segítettem, hogy a csapat védett állapotban a sprintben elvállaltakra koncentrálhasson. A szerep, amit elvállaltam, Scrum Masternéven vált ismertté.
Nem volt könnyű megszerveznem a napi meetinget a korlátozott számú tárgyalóterem miatt. Amikor találtam egy termet, mindenkivel tudatnom kellett, melyik szobát és mikor használhatjuk. Az információ nem mindig jutott el mindenkihez, szóval nem is volt jelen mindenki. Az új kérések át tudtak csusszanni a réseken. Elmentem a menedzsmenthez, és kértem egy irodát, amit mindig használhatunk a PNP csapattal. Felszereltem ezt az irodát a csapat tervezési és napi meetingjeihez. Ezek a meetingek a Daily Scrum néven lettek ismertek, és mindennap ugyanott, ugyanakkor voltak megtartva.
A PNP csapatból mindenki megjelent ezeken a meetingeken, mert ezek hasznosak voltak. Elsődleges céljuk a PNP csapatnak való segítség nyújtása volt. Ha a meetingen előjött bármi, amire a csapatnak szüksége volt, vagy ha bármi akadályozta őket, megtettem, amit csak tudtam, hogy a hátráltató tényezőket kiiktassam. Amint ezt a PNP csapatból mindenki felfogta, elkezdtek felhozni egyéb akadályokat is, amelyekben remélték, hogy segíthetek nekik. Egyszer csak a menedzsment egyik képviselője legalább napi egyszer elérhetővé vált, hogy segítse a csapatot.
A PNP csapat és én összegyűltünk mindennap a napi meetingek kedvéért. 15 percesre ütemeztem a meetinget, de kezdetben ezt nehéz volt tartanom. Amikor valaki bejelentette, hogy mit csinált, a többiek elkezdték kérdezgetni a tervekről. Az egész csapat ilyenkor elkezdte megbeszélni a terveket, segítve, hogy optimalizálják. Filozófiai viták törtek ki a legjobb mérnöki alkalmazásokról. Amikor döntést kellett honi, az egész csapat megpróbált részt venni benne. Amikor az Individual, Inc.-nél mindenki más megtudta, mi zajlik ezeken a meetingeken, elkezdtek jönni. Feltettek kérdéseket, adtak javaslatokat, és általánosságban mindent lelassítottak. Noha jó szándékkal jöttek a látogatók, a csapat kezdte elveszíteni a fókuszát a megjegyzések és javaslatok ködében. A meeting kezdett kaotikus happeninggé válni, a haszna pedig napról napra csökkent.
Mindamiatt, ami a meeting során történt, nem tudtam a napi meetingek hosszát előre megjósolni. Ami még rosszabb, az egész csapatnak ott kellett maradnia az egész napi meeting során, hogy végighallgassák. Az egészet azért vezettük be, hogy növeljük a csapat termelékenységét, de a napi meetingek egyre inkább csak a csapat idejének egyre durvább pazarlásával teltek. Bevezettem néhány nagyon egyszerű szokást, hogy megoldjuk ezt a problémát, és a napi meetingek az eredeti funkciójukat visszanyerhessék. Először is, csak a csapattagoknak volt szabad beszélniük. Senki más nem beszélhetett. Aki nem volt a csapat tagja, de jelen akart lenni, annak csöndben kellett maradnia. Másodszor, a csapatnak mindössze három dologról volt szabad beszélnie: mit tett az utolsó meeting óta, mit fog tenni a következő meeting előtt, és mi akadályozta a munkáját. Óramutató járásának megfelelő sorrendben felkértem a csapattagokat, hogy jelentsenek ennek megfelelően, és mindenki jelentett.
Amikor a PNP csapat napi meetingjeit tartottam, nyilvánvalóvá vált, hogy menedzsmentfeladatot látok el. Megakadályoztam a beavatkozásokat, lehetővé tettem a csapat számára, hogy összpontosíthassanak, elhárítottam az akadályokat és segítettem, hogy a csapat gyors döntéseket tudjon hozni. Radikális változás volt ez ahhoz képest, amit előtte a menedzsment tett. A csapat találta ki, hogyan csinálja, ami a feladata volt. A menedzsment új és elsődleges feladata a csapat termelékenységének maximalizálása lett, vagyis ott lenni, hogy segíthessünk abban, hogy a legjobbat hozhassák ki magukból.
Mire az Individual, Inc.-t otthagytam, a scrumot mindhárom fő terméknél bevezették. Akkoriban az Individual, Inc. teljes változáson ment keresztül a menedzsmentben: lecserélték az alapítót, és új embereket hoztak a céghez. A scrum miatt azonban a csapat továbbra is tudott összpontosítani, és rendszeresen előállni újabb és újabb fejlesztésekkel.
Ha szeretnéd, hogy a csapataid értsék az Agilitás lényegét