"Nagy lépés, ha egy cég rájön arra, hogy problémái vannak" - A Scrum módszerről (2. rész)

Folytatjuk a beszélgetést Bodó Árpád Zsolttal, a Sprint Consulting alapítójával. Az interjú első részében a Scrum szoftverfejlesztési modell működéséről és sajátosságairól esett szó. (Akik nem annyira jártasak a témában, mindenképpen olvassák el az interjú első részét.) Most pedig az agilis módszer gyakorlati megvalósulásával, a gyakori hibákkal, a magyar cégek sajátosságaival, a startupok agilitásával és a gyorsreagálású csapatokkal folytatjuk...

Nincs meg természetes módon az agilis módszertan a cégekben. Tanulni kell. Nyomon tudjátok azt követni, hogy a cég munkatársai által elsajátított tudás ténylegesen működik-e a mindennapi munka során?  

Igen, mindenképpen. A Scrum-oktatást régebben úgy végeztük, hogy az ügyfelek kaptak egy tréninget, majd hazamentek, és csinálták, ahogy akarták. De rájöttünk, hogy ez így nem jó. Abból indultunk ki, hogy mi magunk hogyan tanultuk meg ezt a módszertant. Hát elég sok saját hibába kellett belefutnunk ahhoz, hogy végül megfelelően elsajátítsuk és nem biztos, hogy ez az optimális út. Ma, ha tehetjük, akkor már másképpen csináljuk, nem is tréninget próbálunk az ügyfeleknek biztosítani, hanem bevezetést. Ennek a bevezetésnek csak az egyik (harmadik-negyedik) eleme maga a tréning.

Az első lépés, hogy fölmérjük, hogyan néz ki a szervezet, milyen problémákkal küszködnek, egyáltalán való-e nekik a Scrum. Mert bár nagyon kis százalékban, de vannak olyan cégek, ahol nem biztos, hogy túlságosan hatékony. (Ilyenek például a pusztán üzemeltetéssel foglalkozó cégek. Náluk elemeit lehet alkalmazni a Scrumnak. Nem gondoljuk, hogy mindenkinek minden áron el kellene adni ezt a módszertant.) Az ügyfél cégének felmérését követően kiképezzük külön a menedzsmentet és a fejlesztőket is. Utána leülünk a menedzsmenttel, és ha kell valamit a szervezetben változtatni, akkor ezt megtervezzük és véghezvisszük. Ezek után az első sprintet személyesen mi indítjuk, majd a sprint végén a bevezetést a review-val és a retrospektívvel zárjuk, és akkor engedjük el a kezüket. Természetesen vannak ügyfelek, akik folyamatos coachingot kérnek és kapnak.

Néhány hónap elteltével ismét megnézzük a cégben a Scrum működését és megvizsgáljuk, hogy jelentek-e meg úgynevezett agilis "antipatternek" (gyakori buktatók és hibák) a módszertan alkalmazásába. Az a szomorú, hogy ha a team lazán veszi a szabályokat, és megpróbál kompromisszumokat kötni a Scrum-folyamat terhére, akkor ezekbe bele fog bukni. Nem fogják egyből bebukni magukat a projekteket, de például a várt nagy termelékenység-növekedés elmaradhat, a stressz nem tűnik el, stb. Így, ezen a ponton még mindig tudunk segíteni, kijavítani a hibákat.

Milyen kompromisszumokra hajlamosak általában?

Vannak a Scrumban ajánlott és kötelező szabályok. Kötelező szabályoknak nevezem azokat, amelyek a módszertan vázát képezik. De mivel ez a módszertan a józan ész módszertana, nyitva hagy kérdéseket, területeket, amelyeket a teamnek magának kell (vagy lehet) kidolgoznia. A baj akkor van, amikor olyan kompromisszumokat kötnek, amelyek a vázát bántják a módszertannak. Nem veszik komolyan, hogy legyen jó, priorizált backlog lista, a product owner nem veszi komolyan a szerepét, a team bevállal kidolgozatlan követelményeket, nem veszik komolyan a daily standupot, nem követik nyomun a burndown chart-ot, a sprintek, iterációk kötött időtartamát (timeboxing) nem tartják be, zavarják a teamet, átszervezik a teamet a sprint alatt, belenyúlnak a sprint szkópjába, a „done” kritérium laza, nincs retrospektív, stb...

Jó, tehát ott tartunk, hogy az utókövetés során kiderülnek hibák, és ezek szerint ezen a ponton még mindig lehet segíteni a teameknek...

Mi nemzetközi környezetből jövünk: Amerikától Nyugat-Európán át Oroszországig és Kínáig elég sok mindenkivel dolgoztunk. A magyar cégeknél, ami nagyon jellemző, hogy nincs módszertan. Vagy igény, vagy pénz nincs rá, viszont csinálni kell a céget, és így józan paraszti ésszel kezdenek bele. Ha tetszik, ez a "módszertan". Ez eleinte eredményes, a cég sikeres, van pl. jó termékük, de oda jut a dolog, hogy a fejlesztés már kezd nem megfelelően működni, felszínre törnek a problémák, amelyek kihatnak a vállalatra is. Ilyenkor azért keresnek meg minket, mert érzik vagy rájöttek, hogy valami nincs rendben. Nagy lépés, hogy ha egy cég rájön arra, hogy problémái vannak. Ekkor már lehet segíteni is. Agilis szempontból a nehézség ott van, ha azt mondják, "hallottam a Scrum-ról, trendi, de nekünk nincs semmi problémánk, miért lesz ez jó nekünk?" Persze ekkor is elmondjuk nekik, hogy miért lenne ez jó nekik, de az igazi az, amikor maga a cég jön rá, hogy valami nem működik jól náluk.

Fakadhat ez abból, hogy Magyarországon a céges menedzsment nem feltétlenül szakmai, nincs elég ismerete arról hogyan kellene projekteket vinni, a fejlesztői csapatokat hogyan kellene irányítani?

Én úgy gondolom, hogy abból fakad, hogy a szoftverfejlesztő cégek általában úgy alakulnak ki, hogy fejlesztők elkezdenek terméket, céget építeni, majd a cég kinövi magát, és ilyen helyzetekben a fejlesztő előlép menedzserré, és már nincs igazán igény arra, hogy valódi menedzser szervezze a céget. Hiszen ő a tulajdonos, és - gondolja - ő tudja a legjobban, hogy hogyan kell vezetni a cégét. Ez ugyanaz a kategória, hogy üzleti terv is nagyon ritka a kisebb magyar fejlesztőcégeknél... Szerintem a jó cégvezető, aki azt mondja, hogy "igen, én tök jó fejlesztő voltam, jó vállalkozó vagyok, mert létrehoztam ezt a sikeres céget", de egyben belátja azt is, nem biztos, hogy nem lehetne hatékonyabban megszervezni a munkát. Mert például nem ezt tanulta, nem ez a szakmája. Ezekből a cégekből lehetnek az igazán sikeresek, ezekből az emberekből lehetnek az igazán nagy vezetők. Akik belátják a saját hiányosságaikat, és akarnak is tanulni, változtatni ezen.

Egy másik specialitás, hogy a magyar cégek általában tőkeszegények, a magyar piac kicsi, a játékos sok. Kevés a pénz, kevés a megbízás. Nagy a verseny. Azonban sokszor nem úgy versenyzünk, hogy a legjobb minőséget nyújtjuk. Hanem lenyomni az árat, a határidő sem számít, "majd megoldjuk túlórában, éjszakázással, csak kapjuk meg a megbízást". Ebből is adódik az, hogy sokszor azt hallom, hogy "nekünk nincs időnk arra, hogy új vagy egyáltalán valamilyen módszertan szerint működjünk". Ez kelet-európai karakterisztika.

Mi újság a startupokkal? Van pár fejlesztő srác, van valamennyi pénzük, van valamiféle befektetés mögöttük... Nyilván ők akarják leginkább hatékonnyá tenni a működésüket, hiszen kevesen vannak, kevés a pénzük, de nagyon hisznek a projektjükben... A Scrum esetükben is alkalmazható?

Ők a kedvenceim. Azért, mert bár nincs sok pénzük, az látszik, hogy nagyon érdekeltek abban, hogy jól csinálják, amit építenek... Nekik is szoktunk segíteni. Ők nyilván a piaci árat nem tudják megfizetni, de valami módon mindig meg tudunk állapodni velük. Ugyanis a szép benne az, hogy mivel ennyire motiváltak, ezeknél a cégeknél a leghatékonyabb a Scrum és öröm nézni a lelkesedésüket és az elért eredményeket.

Tudsz magyar példát mondani?

A legelső ilyen ügyfelünk a Digital Natives volt. Nagy élmény volt velük dolgozni. A   következő - akik egyébként az idei hazai Web 2.0 konferencián döntősök voltak - a Ninimo. Ők is egy nagyon lelkes csapat. És nem csak a módszertant, hanem mindent nagyon profin szeretnének csinálni. Az ő esetükben is nagyon jól működött a Scrum-bevezetés. Van olyan ügyfelünk, a Ustream, amely startupként indult, és mára már nagy céggé nőtte ki magát. Ennek a növekedésnek a felénél találtunk egymásra és azóta is együtt dolgozunk. Ezen kívül vannak saját kutatás-fejlesztési projektjeink, melyek esetében szintén nagyon jól alkalmazható az agilis szoftverfejlesztési modell. Amikor a doktorimat írtam, akkor egy egyetemista csapat dolgozott a kezem alá. Úgy használtuk az agilis módszertan sok elemét, hogy ők nem is tudták, hogy az honnan is ered, viszont maximálisan éltünk az előnyeivel...

És mik a nagy kudarcok? Mik azok a szituációk, amikor tudjátok, hogy ha a fene fenét eszik, ez ennél a cégnél akkor sem fog működni?

Általában amikor megkeresnek bennünket, a cégfelépítésbe nem illeszkedik ez a módszertan és nincs esély szervezeti vagy működési változtatásra. Elzárkóznak ettől. Például adott egy fejlesztőcsapat, ezer oldalról jönnek a követelmények, és minden nap release kell, minden nap ki akarnak tenni valamit élesbe, "minden legyen meg tegnapra". Ráadásul mindenki sok projekten dolgozik egyszerre, multitaskingban. Idő szétszabdalva, fókusz szétszabdalva... Nagyon nem hatékony, de gondolom ez mindenkinek ismerős. Ilyen környezetben nyílván nem fog működni a Scrum.

Úgyhogy felmérjük a céget, elbeszélgetünk, és ekkor derül ki, hogy mennyire akarják valójában magukévá tenni ezt az egészet. Ha van rá nyitottság, akkor megyünk tovább. A kétnapos tréninggel megspórolunk egy csomó értelmetlen párbeszédet, és általában a két nap után ők maguk mondják el, hogy hogyan is kellene átszervezni a dolgokat a saját cégükben. Az átszervezés rendszerint nem kerül pénzbe, csak pár pici szabályon kell módosítani. Például az egyik termékmenedzsert kinevezik product ownernek, és innentől kezdve az összes többi termékmenedzser csak rajta keresztül mehet a fejlesztőcsapathoz. Vagy pl. szervezzünk állandó teameket, még akkor is, ha több területről kapnak az adott product owneren keresztül munkát. Ilyen kis dolgokon múlik a siker.

Mondhatjuk egy kicsit úgy is, hogy ti igazából a céges pszichológián változtattok? Tehát hogy valójában terapeutái vagytok a cégeknek?

Így is lehet mondani. Viszont valójában a cég önterapeutája lesz magának, miután bevezetjük a módszertant. Minden iteráció, sprint után úgynevezett retrospektív meeting van, és ezen alkalomból beszélik ki a munkatársak magukból a jó és rossz dolgokat. És így is születnek meg a megoldások. Érdekes módon a legbántóbb dolgok egy cég életében nem nagy dolgok. Például: miért világít pont fölöttem a neonlámpa, miért nem megy a klíma, miért megy a klíma, miért lassú a szerver... Apróságokon múlik a boldogság és egy cég hatékonysága. Ráadásul nagy részük nem kerül pénzbe.

Vegyük egy kicsit az ideális helyzetet. Adott egy cég, elsajátítja ezt a módszert, jól is működik... Aztán jönnek az új alkalmazottak. Velük mi történik?

Korábban próbáltuk azt az utat, hogy az új munkatársak a régi kollégáktól tanulják meg a Scrumot. Egy idő után azt láttuk, hogy ez nem működik. Azért, mert a régebbi kollégák végigülték a - csúnya szó, de így van - agymosást. Azért nevezhetjük így, mert a tréning során valódi paradigmaváltáson mennek át a résztvevők. És az új munkatársak nem értik, hogy miért van szükség erre, mi az értelme annak? Miért kell ezt túlspilázni? A többiek mondják, ezért ő is csinálja, de valójában nincs meggyőzve arról, hogy ez mire is jó. Így oda jutottunk, hogy az a jobb, ha ezek a cégek időről-időre elküldik az új alkalmazottakat például hozzánk, hogy ők is éljék át a tréninget. Voltak erre olyan reakciók is, hogy á, nem, ők már nem akarnak többet költeni erre, majd "training on the job" megoldja. Aztán egy idő után mégiscsak jelentkeztek ők is...

Tehát ez nem működik organikusan? Ezt a cégfilozófiát, módszertant nem szívják magukba automatikusan az új munkatársak?

Paradigmaváltás kell! Vannak olyan emberek, akik meg tudják ezt oldani saját maguk, úgy, hogy sokat olvasnak a témában, képezik magukat. De a fejlesztők nagy része nem ilyen. Kicsit visszatérve az előző kérdésedhez: az, hogy beszéljünk a problémákról, a jó dolgokról a fejlesztőktől általában eléggé idegen hozzáállás. A szoftverfejlesztők reál beállítottságú emberek. Ez az "akarsz beszélni róla?" dolog nem nekik való. És mégis nagyon hatékony tud lenni, mert a retrospektív meetingeket nem azzal a bullshittel kell eladni nekik, hogy "majd hatékonyabban dolgozunk legközelebb", meg "majd jobb lesz a cégnek". Nem. Azért csináljuk a retrospektív meetinget, hogy - önző módon - a saját életünk legyen jobb. És akkor lesz jobb a cégnek, ha mi elégedett, kiegyensúlyozott munkaerő vagyunk.

Nem csak a munkatársak összetétele változhat, de a cég maga is. Egy cégnek van egy fejlődéstörténete... Jó példa a korábban már említett üzemeltetés. Lehetnek olyan új feladatok, kihívások, amire egy idő után azt mondja a cégvezetés, hogy ezeket mégsem agilis módszertannal szeretné vinni... Ahogy megyünk előre az időben az ilyen feladatok aránya folyamatosan változik egy cég életében...

Igen, egy cégnek ezt is ki kell mondania: vannak olyan területek, ahol ezt a módszert szeretnénk alkalmazni, és vannak olyan területek, ahol mondjuk, csak egyes elemeit szeretnénk megtartani. Tegyük fel, hogy egy cég elkezd fejleszteni egy terméket. A termék élesbe megy, de ez alatt fejlesztjük a következő release-eit. De közben már bejön a support, a maintanence is. Bizony ez nagy zavaró tényező tud lenni a Scrum teameknek. Ilyenkor szoktam javasolni, hogy egy definiáljanak egy pár emberből álló külön teamet. Lehet gyors reagálású egységnek is nevezni. Az ő feladatuk az, hogy megvédjék a Scrum teameket a munkájukat megzavaró hirtelen feladatoktól. Ez a gyorsreagálású team végzi el helyettük a bugfixeket, apróbb sürgős fejlesztéseket, így a Scrum-team továbbra is működni tud. De ugye senki sem szeret tűzoltó lenni. Nagyon ritka az ilyen ember. Ezért ennek a gyorsreagálású csapatnak az összetételét rotálni szoktunk, mert ez a kis szervezeti változás még mindig kevésbé fájó, mintha az összes Scrum-team munkája válna hatékonytalanná.

Hogyan tud együttműködni egy Scrum-team egy nem Scrum-modell szerint működő másik teammel ugyanabban a cégben? Sok olyan helyzet van, amikor együtt kell tudniuk dolgozni, kommunikálniuk kell.

Teljesen együtt kell tudniuk működni. Scrumban működésnek az egyik előnye, hogy a team bura alatt van, védve a külső, zavaró tényezőktől. Ez nem azt jelenti, hogy nem jöhetnek kérdezni. Tehát nyugodtan segíthetnek egymásnak a teamek, persze nem órák hosszat, vagy feladatokat átvállalni tőlük, hanem konzultálni. Ezt szabad és kell is. Ez is része kell, hogy legyen a kommunikációnak. Lássuk be, hogy a kommunikáció nem csak önmagában a Scrum-teamben jó, hanem más módszertanokban is jótékony hatású.

Mi van akkor, ha nincs egy gyorsreagálású csapat, ami felfogja a Scrum-team elől a feladatokat, hanem ennek a teamnek közvetlenül kell tudnia együtt dolgoznia bizonyos feladatokon mondjuk az üzemeltetőkkel... Ez belefér? Ruglamas ennyire ez a módszertan?

Igen. Két módon működhet. Az egyik az, amikor már a sprint tervezésekor ismertek a hibák, és a product owner úgy kéri a teamtől, hogy légy szíves, ezt meg ezt is javítsátok ki. Viszont emiatt ugye kevesebb új fícsör fejlesztés fog beleférni. A team megbecsli valahogy, és akkor rendben is van a dolog. De hogyha nem ismerjük előre ezt a hibalistát – mert még nem találták ezeket meg ‑ akkor célszerű egy úgynevezett buffer storyt betervezni. Vagyis azt mondjuk, hogy a sprint 20 százaléka erre a jövőbeni feladatra fog elmenni. Amikor érkeznek be a hibák, azok ide adódnak, és amikor elfogy a 20 százalék, akkor odamegyünk a product ownerhez, és megkérdezzük: folytassa-e a team a hibajavítást, és akkor kevesebb fícsör lesz kész, mint amennyit beterveztünk, vagy fordítva. Ezt a döntést a fejlesztőnek mindig át kell hárítania a product ownerre.

A webes fejlesztések piaca fellendülőben volt az elmúlt években. A szoftverfejlesztés  népszerűsödését leköveti a Scrum? Változott ez a módszertan az elmúlt években?  Mi hat rá? Mi a jövője?

Ahhoz, hogy lássuk, hogy hova tart ez a módszer, látni kell egy picit a historikus oldalát is. A 70-es évek közepén és 80 években jöttek az első forradalminak, renitensnek nevezett módszertanok. És csupán 2001-ben született meg az agilis kiáltvány, és innentől beszélhetünk igazából agilis módszertanokról, jóllehet maga a Scrum már a 90-es évek eleje óta létezett. A Scrum is a 2000-es évek elejére forrott ki igazán, innen kezdve viszonylag stabil a módszertan. Az agilis szemlélet nem nagyon változott az elmúlt években, és szerintem már nem is fog. Újabb módszertanok persze jöhetnek. Ma ott tartunk, hogy ezek közül a Scrum a legkiforrottabb, de lehet, hogy egy idő után kiforr egy másik, jobb módszertan is. Jóllehet vannak próbálkozások, egyelőre ez nem látszik. A Lean módszertant említeném meg, amely a jövőben akár be is kebelezheti a Scrumot és egy nagyobb keretet nyújthat köré.

Vissza az interjú első részéhez...

Címkék: dev interjú szoftverfejlesztés projektmenedzsment scrum produktvitás agilis
2010.05.18. 12:48. írta: hírbehozó

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Szép leírás, de szokás szerint nem sikerült kifejteni, milyen az agilis projekt valós üzleti környezetben. Ahol beszerzési folyamatnak, PMI/Prince alapú projekt vezetésnek és céges módszertannak kell megfelelni.

A referenciák közül nagyon érdekelne a Siemens... mert a magyar startup-ok referenciának nem annyira ütősek.
Annyira furcsa, hogy itt nálunk a "Scrum" szó egyedüli jelentése az, hogy reggelente az egyes 5-6 fős teamek leülnek megbeszélni, hogy ki mivel foglalkozik aznap. Illetve van egy hétfői teljes céges meeting (kb. 30 fő) ahol mindenki elmondja a CEO-nak, hogy mivel is fog foglalkozni a héten.
Ha egy cég kizárólag szoftverfejlesztéssel foglalkozik órabérben, akkor jó, hogy búra alatt ülnek a kreatv munkások - de ha nem ez az egyetlen területe a cégnek, akkor az elzártság az első átszervezésnél kárára válik a csapatnak.

Még mindig nincs válasz arra, h hogyan lehet Scrum alapon fix áras szerződést, kockázatátvállalást, back-to-back alvállalkozói szerződést beilleszteni.
@Amby: Az előző cégemnél kötöttünk sikeres SCRUM szerződéseket fix árra. Előzményként tudni érdemes hogy mi voltunk a Magyar Távmunka Szövetség alapítói és volt egy 42000 fős távmunkás (alvállalkozós) adatbázisunk, ebből kb 50 fővel - csapattal aktívan együtt is dolgoztunk.

Az ügyfél általában azt értette meg, hogy ha lefixáljuk az összeget, az időt és a scope -ot, akkor egyetlen változó marad, és ez a minőség. Ezek közül a scope az, amiről meg lehet győzni hogy nem jár rosszul, ha változó, főleg úgy hogy menet közben mindig a legfontosabb elemeket tudja beleemelni. Ha ezt elfogadja, már lehet dolgozni SCRUM -ban. Az ellen senki nem tiltakozott, hogy 2-3 hetente kap egy demót az addig elkészültekről...

Távmunkásokkal, alvállalkozókkal viszont már nehezebb a helyzet. Irdatlan mennyiségű minőségellenőrzés szükséges és lehetőleg minnél több automatizálás a tesztelésben...
@Amby: Azt hiszem, hogy olyan kérdésekre próbálsz választ találni itt, amit a Scrum nem válaszol meg, mert ő felteszi, hogy olyan környezetben dolgozol, hogy őt alkalmazhatod :)

Ha jól gondolom, akkor Téged az agilis szerződések érdekelnek. Ezzel is foglalkoznak a neten. Ez itt nem egy rossz leírás: agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

Szerintem ne várd senkitől itt ezen a fórumon, hogy megoldja ezeket a problémákat, ugyanis ezekkel az egész iparág küszködik :) Én úgy látom, hogy jobban jársz, ha Te magad jársz utána a dolgoknak :)
@aston21: Ki csinálta nálatok a Scrum-bevezetést?
@ESz: a scope ilyen megkozelitese tetszik, ezt meggyozonek erzem.

Az en kornyezetemben a tavmunka felallas mindennapos valosag es az aktiv projektekbol mindossze 20% agile alapu - mikozben szerintem 40% korul kene lennie. A kulonbseg abbol adodik, h a gyakorlatban nincsen valaszunk az indiai alvallalkozo kezelesere, illetve a projekt tagabb, mint egy szimpla termekfejleszteshez kapcsolodo folyamat.
@rozyka: hopp, nem az én azonosítóm ;-)

@Marhefka István: azt tudom, h nem mindenre alkalmas a Scrum, csak az interjúban olyan szépen hangzott a "projektvezetés rossz, Scrum jó" kijelentés, hogy igyekszem tanulni ;-)

A linket köszönöm, olvasok.
Zseniális összefoglaló a Scrum-ról. Sajnos nem tér ki azokra az esetekre, amikre viszint nem ad választ (vagy nem egyértelmű választ) Készítettem egy összefoglaló szösszenetett erről:

www.qualityontime.eu/extracts/megertik-es-atelik-munkajukat-scrum-modszerrol-1-resz
Igazából ez a megjegyzés inkább az előző cikkhez szólna, csak elkavartan. A felvetett kérdésekből azért ez már párat megválaszolt. :)
@Amby:
A projektvezetés nem "rossz", PM is vagyok. :) Előbb voltam hagyományos projektmenedzsment tréner, mint Scrum és agilis tréner, coach.

Arra próbáltam utalni, hogy az agilis projektvezetésnek van egy csomó előnye, amelyet egy hagyományos projektmenedzsment nem tud nyújtani.
Persze ez fordítva is igaz, csakhogy véleményem szerint az agilis projektvezetés több kockázatot lő ki csípőből, rugalmasabb és életszagúbb. Az üzlethez, a változó világhoz is közelebb áll.
Ha jól végezzük, a fejlesztők kevésbé élnek stresszben (a menedzsment is), a csapat úgy lesz produktívabb, hogy magát pörgeti föl, nem egy PM hajtja őket korbáccsal, könnyebb elérni, hogy az ügyfél elégedett legyen, és a szoftver minősége is jobb lesz. Még tovább is sorolhatnám.

Tudom, hogy mindez marketing bullshit-nek tűnik, mert elsőre én is annak tartottam. Szenvedtünk is az agilistől rendesen, ellencikket akartam írni, majdnem bebuktunk egy nagy projektet, de miután külső kényszerítő körülmények hatására kiképeztek minket, elhittem, hogy ez még akár működhetne is. És működni kezdett. Ugyanaz a csapatom élvezte a munkát, már nem akartak felmondani, ügyfél elégedett volt, folyamatosan szállítottunk.

Ezután ezt már több sikeres projektem követte. Napokig tudnék sztorizgatni.
A tréningjeim is azért népszerűek, mert szinte mindenre tudok pozitív/negatív saját tapasztalati példát hozni.

Igen, valóban a fenti interjú nem tért ki mindenre, de ez nem is volt célja. Egy tréningem két napos és így is intenzív, hát háromnegyed órába nem sikerült többet belepasszírozni.
@bodozs: szerintem, amit emlegetsz ostorozás szinten, az mindössze vezetési technika, ami nincs fixálva PM-ként se ;)

Én legalábbis egy kommunikáció és együttműködés alapú megközelitést tanitok a PMjeimnek. Saját példa alapján, amikor ügyfélkérésre agilis megközelitest kellett alkalmazni, akkor az addig tanult PM technikakat siman fel tudtuk hasznalni, nem volt kulonbseg.

(megjegyzes: szoftverfejlesztesben egyebkent sokkal több értelmét látom az agilis technikáknak - mig az üzlet többi részében még mindig a PM megközelites életszagúbb.)

Arról szivesen vitatkoznék, hogy az agilis megközeltés projekt megközeltés-e egyáltalán - de az ilyet jobb egy sör mellett. ;)
"Még mindig nincs válasz arra, h hogyan lehet Scrum alapon fix áras szerződést, kockázatátvállalást, back-to-back alvállalkozói szerződést beilleszteni."

Sehogyan, de szerintem egyik módszerrel sem lehet ilyet...ezt csakis akkor lehet, ha a menet közbeni, szokásos újrafejlesztések, átalakítások valós, munkaórában számított költségeit ráterhelik a fejlesztőkre és "vagy megszoksz vagy megszöksz", "kussolj és dolgozz" alapon elvégetetik velük a munkát. Olyan viccces itt olvasgatni ezeket a fennkölt, pszeudo-intellektuális szövegeket erről a témáról :D Miközben a valóság teljesen más. Én több mint 10 éve dolgozok fejlesztőként, nagyon sok projektet csináltam végig és még soha nem fordult elő, hogy ilyen szép, intelligesn, átgondolt, korrekt ütemezés és fejlesztés lett volna.... Mindig ugyanaz van: időben alultervezés, funkcionális hiányosságok a tervben, hiányos specifikációk és az ezekből következő problémák cinikus ráterhelése a fejlesztőkre és a projektvezetőkre. A végén 99%-ban úgyis át lesz adva a projekt, mert az emberek a nyelvüket lógatva befejezik... További jó dumcsizást a semmiről!
@Amby: Aaz, hogy a cég többi részében működnek-e az agilis elvek tökéletesen bizonyítottak: nézt meg a Franklincovey álltal készített tanulmányokat. Az tisztán kimutatta, hogy az igazán kiválló vállaltok mindenszinten olyan elveket vallanak, amik "tiszta Scrum"