:

Szerző: Bíró Tamás

2020. december 7. 09:47

Megújult a 25 éves Scrum

Teljesen új, mégis minden a régi. A filozófia nem változott, de szélesebb körben alkalmazható, közérthetőbb és rövidebb is az új Scrum Guide. Több, sokak által félreértett dolgot rendbe tettek, és látszik, hogy felveszik a küzdelmet a „kiherélt” Scrumot alkalmazókkal. A most induló cikksorozatban kivesézzük, miként.

A tíz évvel ezelőtt kiadott Scrum Guide-ot a keretrendszer hivatalos definíciójának szánták, és az elmúlt évtizedben átesett pár módosításon. A mostani, negyed évszázad tapasztalatát összegezve azonban teljesen megújult. Első ránézésre a mérete tűnik fel, majdnem egy harmadával rövidebb, mindössze 13 oldal. A külalakja is megváltozott, eltűnt róla Ken és Jeff fotója, ami talán annak tudható be, hogy mindig is úgy érezték, hogy ez a dokumentum nem csak az ő érdemük. A bejelentő ceremónián is keveset beszéltek, látszik, kezdik átadni a stafétát egy új generációnak.

Ha viszont el is olvassuk, sokkal több változást látunk. Legszembetűnőbb a Development Team (fejlesztő csapat) fogalmának és a Daily Scrum három kérdésének eltűnése, valamint a Product Goal (termék cél) és Artifact-Commitment (műtermék vagy munkaanyag-vállalás) párok bevezetése. Ezen kívül néhány kisebb módosítás is van, mint a self-managing (önvezető) megjelenése a self-organizing (önszervező) helyett vagy a servant-leader (szolgáló-vezető) eltűnése. Ezeket egy-egy cikkben fogom alaposan szétszedni és összerakni, az elsőben azonban a filozófiai és gondolkodásmódbeli változásokra koncentrálok.

10:48
 

RSA ANIMATE: Drive: The surprising truth about what motivates us

Még több videó

MOTIVÁCIÓ ÉS KÜZDELEM A HELYTELEN ALKALMAZÁS ELLEN

A tíz évvel ezelőtti első verzióban az első oldalon kiemelve a Sprint szó szerepel, mint a „scrum szíve”. Az eltelt tíz évben ez a megközelítés eléggé megváltozott, a rendszer lényege inkább az emberekben és az emberi értékekben van. Ez az új dokumentumon még jobban látszik, hiszen egyre jobban a csapattagok motiválására fókuszál, egyre nagyobb szabadságot ad az embereknek. Egyre kevéssé a folyamatok módszertanszerű előírása áll a központban, hanem inkább arra törekszik, hogy keretet adjon (framework) az emberi kreativitásnak és hatékony együttműködésnek.

Kreativitást igénylő munka esetén a kutatások kimutatták (D. H. Pink, 2009), hogy az embernek három dolog együtt állására van szüksége, hogy a motivációja magas legyen: megfelelő cél, önállóság és fejlődési lehetőség. A Scrum keretrendszer mindhárom kritériumot teljesíti, ha valóban szabályosan alkalmazzák. Az önállóság és folyamatos fejlődés eddig is hangsúlyos volt, azonban csak rövid távú cél volt, a Sprint cél. A hosszútávú cél hiányát orvosolja a Product Goal bevezetése.

A bevezetőben rögtön az elején igen markánsan megjelenik, hogy a Scrum minden eleme valamilyen célt szolgál, és ha valaki ezeket önkényesen kihagyja, nem követi a szabályokat, akkor azzal csak elfed valamilyen problémát, és így az egész rendszer akár hasznavehetetlenné is válhat. Úgy érzem, ez komoly beszólás azoknak a csapatoknak, akik összevissza ferdítik a Scrum szabályait, hogy az ne legyen számukra kényelmetlen. Pedig az egész rendszer egyik lényegi eleme az, hogy a problémákat ne elfedjük, hanem szembesüljünk velük, így lehetőségünk van azokat kijavítani. Akkor is, ha ez elsőre kínos is. Ha nem fáj eleinte, nagy eséllyel nem jól alkalmazzuk a Scrumot. Amikor először olvastam, és ahogy a launch eventet hallgattam élőben, nagyon megörültem, hogy ez ilyen nyers őszinteséggel belekerült rögtön az elejére.

Ezután következik egy hatalmas pofon azoknak, akik a Scrum Mastert opcionális kisegítőként kezelték, vagy nem akartak rá költeni. A Scrum definíciója azzal kezdi, hogy először is vegyünk egy Scrum Mastert, aki egy olyan környezetet működtet, amiben egy csapat kis lépésekben értéket teremt. Tehát a Srum Master központi alak, központi szereppel, a csapat igazi vezetője. Ez nagy öröm azoknak, akik a Scrum Mastert eddig is a Scrum motorjának tartották. Ez a második pont, ahol azt érzem, a készítők a félreértett Scrum alkalmazás ellen tesznek lépéseket.

19:52
 

Nyolcadik utas a Scrum Master - Bíró Tamás (freelancer)

Még több videó

Az új dokumentum a vezetőkkel sem bánik kesztyűs kézzel, egyértelműen kijelenti, hogy a Scrum megmutatja a gyengeségeket a vezetésben, környezetben vagy épp a munkamódszerekben. Később azt is mondja, hogy a vizsgálat alkalmazkodás nélkül semmit sem ér, és hogy a Scrum célja a változás kiprovokálása. Sőt, az értékek kifejtésénél is megemlíti, hogy a tisztelet nem csak csapaton belül elvárt, hanem azok részéről is, akik a csapattal dolgoznak, hiszen a csapat tagjai értelmes és független emberek: röviden, ne kezeljük már a csapat tagjait gyermekként, se mint vezetőjük, se mint ügyfél.

NEM CSAK SZOFTVER

Mi az összetett és bonyolult között a különbség? Ahol sok a bizonytalan tényező, feltérképezhetetlenek az összefüggések, ott komplexitásról beszélhetünk. Ahol sok a tényező, de azok összefüggései jól meghatározhatók, ott bonyolultságról. Fontos látni, hogy egy nem bonyolult rendszer is lehet komplex, azaz összetett, és egy rendkívül bonyolult sem feltétlenük komplex. Univerzális bizonytalansági tényező az ember, így ökölszabályként mondhatjuk, hogy az a rendszer, amiben emberek részt vesznek, szinte biztos, hogy komplex. Egy autó bonyolult, de jól kiismerhető; egy város forgalma azonban komplex, legfeljebb előrejelzésekkel dolgozhatunk, ha időre akarunk eljutni valahová. Érdekes, hogy a forgalmat józan ésszel kezelni tudjuk, de a komplex termékekbe sokan belebuknak. Ennek kezelésére jó a Scrum.

Izgalmas változás, hogy már nem kizárólag az IT-ban gondolkodnak. A Scrum keretrendszert számos más területen alkalmazzák sikeresen, és bár az alapjai a szoftverfejlesztésben gyökereznek, a Scrum bármely összetett fejlesztési feladatra alkalmas lehet. Ezzel el is érkezünk a "darázsfészek szóhoz", a developerhez, azaz fejlesztőhöz. Egy ideje komoly vita folyik a Scrum közösségben, hogy megfelelő szó-e a fejlesztő, amit sokan valóban a szoftverfejlesztővel azonosítanak, és úgy érzik, ez beszűkíti a Scrum alkalmazásának lehetőségeit. Magam is tapasztaltam, hogy egy tréning során mondjuk egy marketing menedzser vagy jogász nem tud feltétlenül azonosulni azzal, hogy ő egy fejlesztő. Ez angolul is így van, a developer szót sokan a software developerrel azonosítják.

Ugyanakkor Ken és Jeff álláspontja is védhető, hogy a szó ennél szélesebb körben használatos, hiszen a termékeket is fejlesztjük, sőt a kutatók is kutatás-fejlesztést (research and development) folytatnak. Ráadásul nem találtak jobb szót. Nemrég megkérdeztem pár szervezetfejlesztő ismerősömet, hogy a fejlesztő szó mit jelent számukra, ők nem a szoftverre asszociáltak, érthető módon. Így meg kell tanulnunk, hogy a Scrumban a fejlesztő a terméket fejleszti, így bárki, aki valahogyan hozzájárul a termék készítéséhez (fejlesztéséhez) az fejlesztő, akármi is a szakmája, akármi is a termék.

A Scrum alapjait leíró fejezetek is leegyszerűsödtek, és lényegre törőbbek lettek. A definíció egyértelműen komplex, azaz összetett problémák megoldásával való értékteremtésre tartja alkalmasnak a keretrendszert. A szoftver is egy a sok közül, ami összetett, de messze nem az egyetlen.

A LÉNYEG NEM VÁLTOZOTT

A Scrum alapjai továbbra is a transzparencia, valamint az empirikus megközelítés, az állandó vizsgálat és alkalmazkodás. Az empirikus gondolkodás mellé azonban a lean gondolkodás, a fölösleg elkerülése is bekerült, no nem mintha ez nem lett volna benne eddig is az Agile Manifesto 12 alapelve között, csak másként megfogalmazva. Beszólás itt is van, hiszen megemlítik, hogy a vizsgálat transzparencia nélkül félrevezetés és fölösleges. Azaz a teljes őszinteség az elvárás mindenki felé: ha nem mondjuk ki valamiről, hogy nem jó, pedig tudjuk, akkor átverjük magunkat és a körülöttünk dolgozókat is.

Összefoglalva:

  • Az új Scrum Guide 2020 kompaktabb és közérthetőbb
  • Egyértelművé teszi, hogy csak akkor működik, ha nem „hackeljük” a rendszert
  • Komplex problémák megoldására szánják, nem csak szoftverre
  • Tisztázza a fejlesztő fogalmát
  • Jobban épít az emberi motivációra
  • A csapat a Scrum Masterre és az általa fenntartott környezetre épül
  • Hangsúlyos lett a Lean gondolkodás
  • Küzd a rosszul értelmezett Scrum ellen
  • Rendbe teszi a csapat fogalmát, a Daily Scrumot, bevezeti a Artifact-Commitment párokat és tisztáz még pár fogalmat
  • A lényege nem változott

Ezért kezdtem azzal, hogy minden új, de semmi sem változott. Aki vette a fáradtságot és alaposan utánajá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.

Tamás 25 éve vállalkozó a tech szektorban, két sikeres cég felépítését (SenseNet, Barion) követően szabadúszóként kamatoztatja tapasztalatait. Az agilitást Lyssa Adkins-től az 5 agilis érték kitalálójától és Ken Scwabertől, a Scrum keretrendszer egyik alkotójától tanulta. Több, mint 1500 embert tanított eddig agilitásra.

November 25-26-án 6 alkalmas K8s security és 10 alkalmas, a Go és a cloud native szoftverfejlesztés alapjaiba bevezető képzéseket indítunk. Az élő képzések órái utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról