Az első agilis élményem 2007-2010-re datálódik vissza, amikor a Synergonnál dolgoztam senior fejlesztőként/vezető fejlesztőként. A Honvédelmi Minisztérium megbízásából dolgoztunk egy iratkezelő szoftver kifejlesztésén, ami képes volt a teljes Magyar Honvédség igényeit kiszolgálni.
Ebben a kétrészes cikksorozatban ezt az élményt szeretném megosztani mindenkivel, aki érdeklődik más agilis élményei iránt.
Az első rész a projekt történetét írta le, ez, a második rész pedig a csapatunk belső világáról ír.
Sokat gondolkoztam az évek során, hogy mi volt a sikere a mi csapatunknak. Bizonyos dolgok láthatóak (szervezeti támogatás, módszerek, keretek, backlog, ügyféllel való kapcsolat), de a csapat sajátságos belső összetétele és dinamikája csakis a belső tagok számára volt ismert.
A Scrum Guide három szerepkört említ: a Product Ownert, a Scrum mastert és magát a csapatot. Én úgy gondolom, hogy túl nagy fókusz van a csapaton és ehhez képest pedig kevés az egyéneken, pedig enélkül szerintem nem lehet siker. A világban futó agilis kezdeményezések kapcsán is azt látom, hogy keveset foglalkoznak az egyéni szinttel, sokkal többet a csapattal vagy a szervezeti szinttel.
Pedig ha nincs válaszunk arra, hogy mitől fognak tudni egy csapatban az egyéni képességek érvényesülni és az egyéni igények kielégítésre kerülni, és az egészből hogyan lesz valami, ami képes a valós teljesítményre is, akkor szervezeti szinten sem lehet várni a sikert az agilitástól.
A mi esetünkben azt mondhatom, hogy Csuti nagyon jól összeválogatta a csapatot. Volt pár kulcskompetencia, ami szükséges volt a sikerhez, illetve a csapaton belül is volt olyan kémia a tagok között, amit már meglévő baráti- és korábbi munkakapcsolatok is megalapoztak. Fontosnak tartom, hogy ezekről is külön meséljek, talán nem veszi senki rossz néven a csapatból. Előre elnézést kérek azoktól, akik ugyanúgy hozzájárultak az iktató sikeréhez, de nem szerepelnek a listában (beleértve a menedzsment tagjait és az első csapat tagjait is, vagy bárkit aki részt vett a projektben).
Csuti. Róla már meséltem, ő lett a Scrum masterünk. Nagyon jó volt, hogy ő a divíziómenedzsment tagja is volt. Ha nekünk volt valami panaszunk (nevezzük impedimentnek), akkor ő azt meghallgatta, és igyekezett elérni a menedzsmentnél vagy akár az ügyfélnél is a kívánt változást, ha az nem csapaton belüli probléma volt. Talán furcsa, hogy a Scrum master az ügyféllel is kapcsolatot tarthat, valójában egyáltalán nem volt furcsa, hiszen az ügyféllel több szálon is kellett a kapcsolatot tartani: volt szakmai szint, amin jórészt a csapat “utazott”, és volt a menedzsment szint, ahol a pénzügyi megállapodások is születtek. Csutinak jó érzéke volt ahhoz is, hogy összefogjon egy maroknyi kreatív embert, hogy azok az idő kereteken belül értelmes eredményekre jussanak.
Endre. Ő volt a titkos fegyverünk, és egyben a rangidős közöttünk. A honvédségtől, az ügyfél oldalról igazolta át a Synergonhoz a menedzsment. Endre korábban vezetőként dolgozott a honvédségnél, ismerte az egész szervezetet, és egy időben az iratkezelésért is felelős volt az egyik katonai szervezetben. Az első iktató egyik fontos tanulsága az volt, hogy komplex az üzleti domain (maga a nyelv, a jogszabályok és a sok egyéb szabály), mi pedig (Synergon) nem vagyunk ennek szakértői. Endre szerepe kulcsfontosságú volt a sikerben, mert így házon belül nagyon sokat tudtunk beszélgetni, hogy egy-egy fogalom tulajdonképpen mit is jelent, hogyan zajlanak a valóságban bizonyos dolgok, amiket mi az íróasztal mögül nem tudunk elképzelni. Endre jelenléte üzleti szakértőként kulcsfontosságú volt: nem csupán gyorsította a csapat tanulását és a tervezést, egyszerűen elengedhetetlen volt, hogy a teljes csapat megértse az üzleti domaint. Vele együtt terveztük meg a folyamatokat, a képernyőket, a teljes működést, és ő részt is vett az elkészült funkciók validálásában és verifikálásában is. Egy igazi kincs volt ő.
Kristóf. Külsős senior fejlesztőként (architectként) vette be Csuti a csapatba. Akkor ez nekünk rosszul esett, mert azt éreztük, hogy nem bíznak bennünk, hogy technológiailag képesek vagyunk megvalósítani a projektet (legalábbis én így éltem meg, a többiek nem biztos). Kristóf hozta be a csapatba a Spring frameworköt (2007-ről beszélünk), a Domain Driven Designt, a TDD és a Hibernate gyakorlatát, a POJO fejlesztést, és az egész lightweight szemléletet az architektúrában. Előtte mindenféle alkalmazásszerverekkel kínlódtunk. Kristóf volt azért a felelős, hogy skálázható rendszert építsünk a végén, és ezen technológiák/módszerek ennek (is) voltak az eszközei. Kristóf ugyanúgy produktív munkát végzett, és napi szinten kódolt a csapatban. Konfrontatív stílusával és szilárd rendszerszemléletével mindig a technológiailag jobb irányba terelt minket, amit én nem mindig viseltem könnyen, de utólag be kellett látnom, hogy sok mindenben volt neki igaza.
István (én). Vezető fejlesztőként kerültem a csapatba, de tulajdonképpen úgy alakult, hogy én voltam az, aki Endrével nagyon sokat dolgozott párban, hogy felfedezzük az üzleti domaint, rájöjjünk, mi fontos és mi nem a szoftver szempontjából, és ezeket a leszűrt információkat a csapatnak is átadjuk. Mai terminológiával nézve üzleti elemzőként funkcionáltam, de egyben kódoltam is fejlesztőként. Számomra nagyon fontos volt, hogy tiszta fogalmakkal operáljunk, így kompromisszummentesen mentem utána Endrével egy-egy fogalom letisztázásának. Ezeket a fogalmakat aztán következetesen a kódban is használtuk, így kialakulhatott a Domain Driven Design szerinti “mindent átható nyelv” (Ubiquituous Language). Egy nyelvet használtunk az ügyféllel, a csapatban, a felhasználói felületen, a kódban, de még az adatbázisban is (vagy legalábbis törekedtünk rá). Sokáig nem tudtam, de a Product Onwer szerepkört is én vittem, mert valahogy nekem volt “ingerenciám” a leginkább arra, hogy lássuk, hogy hogy is fog megvalósulni a rendszerünk, milyen feature-ök egymás utáni fejlesztésén keresztül, ergó a product backlogért is én feleltem. Ebbe azért a többiek is nagyon be voltak vonva, Endre is, az ügyfél is és a teljes csapat. Az ügyféllel sokat egyeztettünk szakmai szinteken sprintek közben is, és a demókon is ott voltak, és visszajelzést adtak. Nem éreztem úgy, hogy formálisan nekem kellene az egészet irányítani mint PO, természetesen működött a dolog. Endrének is voltak személyes kapcsolatai a volt kollégáival, Csuti is ápolta a kapcsolatot menedzsment szinten, így a PO szerepben (amit nem tudatosan vittem) itt is erősen kiegészítettek. Ja, és én is ugyanúgy dolgoztam a kódon, leginkább a backenden.
Laci. Ő is vezető fejlesztő volt, úgy mint én. Ez fura, hiszen egy vezető fejlesztő szokott lenni egy csapatban. Mivel jóbarátok voltunk, tudtuk “tandemben” csinálni. A teljes technológiát Laci látta át, beleértve a frontendet és a backendet is, én inkább a backenden és az üzleti oldalon (mint BA/PO) funkcionáltam. Laci nagyon jól igyekezett harmonizálni a különböző fejlesztőktől érkező elvárásokat, a közös standardokat számonkérni (pl. UI-on komponenseket hozunk létre, és azokat újra felhasználjuk, vagy könyörtelenül clean code-ot írunk Javascriptben), és mentorálni a kezdő kollégákat. Kiállt a SmartClient Javascript UI technológia mellett, ami abban az időben még igen újszerűnek számított, és vastagkliens élményt hozott a böngészőkbe böngészőfüggetlenül (2007-ről beszélünk). Lacival mi barátok voltunk, kollégiumi szobatársak, és ez azért úgy gondolom, nagyban stabilizálta a csapat működését. Laci is – természetesen – ugyanúgy kódolt napi szinten.
Zotyó. Fejlesztők közül ő volt közöttünk a rangidős, aki korábban megjárta a banki rendszerek bugyrait. Neki köszönhettük, hogy megtanultunk MS SQL-ben queryket írni, DB-t optimalizálni. Az elején naivan még azt hittük, hogy majd a Hibernate mellett nem kell ilyen “apró részletekkel” fogalkoznunk. Zotyó csípős humora nagyon jó indikáció volt arra, hogy ha valamilyen elképzelésünk nem találkozik a realitással. Így ő ezzel minket (vagy legalábbis engem) mindig arra kényszerített, hogy az ideák világából mihamarabb a realitás világába kerüljünk át.
Kulcsi. Ő volt a UI/UX szakértőnk, aki ugyanúgy részt vett a domain megismerésében, amikor Endrével beszélgettem, vagy amikor a csapattal próbáltuk megérteni, mi “áll előttünk” épp. Abban az időben a UI/UX-nek nem volt még akkora irodalma. Kulcsi ösztönösen mindig érezte, milyen irányba lenne jó vinni a felületet, és mindig partner volt abban, hogy a fejlesztőkkel közösen (akik hozták a sok kivételt) újra gyúrja a felületeket, ha szükséges volt. Ez a folyamat különösen érdekes volt, hiszen balanszírozni kellett a különféle használati esetek között, és ehhez viszont jól kellett ismerni a leendő felhasználókat, ami Endrétől jött. Kulcsi pszichológusként sokszor volt “békítő” is a csapatban, a feszültségeket igyekezett elrendezni maga könnyed, de mégis felelősségre törő stílusában.
Janó. Pályakezdőként dolgozott a Synergonnál, leginkább a smartclientes frontendet vitte, de a teljes stacket átlátta ő is. Janó is ugyanúgy teljes értékű csapattag volt, aki tehetségével és lelkesedésével részt vett a csapatmunkában. Partnere volt Lacinak abban, hogy a smartclientes felületek megfelelően legyenek kompensekre bontva, hogy újra felhasználhatóak legyenek részek, és hogy ne harapódzon el a kliens oldalon a káosz.
Dani. Később került be a csapatba, gyakornokként. Ő is teljes értékű csapattag lett, kezdetben tesztelt, de aztán hamar felvette a fordulatszámot, és fejlesztői munkát végzett. Az ő onboardingjáról anno írtam egy cikket a régi blogomon, aminek stílusát már kissé szégyellem.
Gyuri. Ő volt a tesztelőnk a csapatban. Kezdetben nem volt velünk, később került be. A csapat úgy érezte, hogy hasznos lenne, ha profi tesztelő is lenne a csapatban. Gyuri hozta ezt a vonalat, és segített nekünk a rendszerben megtalálni a hibákat elsősorban exploratory teszteléssel.
Azt hiszem, a többiek nevében is mondhatom, hogy mindannyian értékeltük a másik hozzáadott értékét a projekthez.
Nem volt kérdés, hogy ki miben járult hozzá a csapat sikeréhez.
A csapat adott közösen a terméknek nevet (Syrius volt a neve a piacon). Az ötlet ugyan a Csutié volt, de ez nem számított, mert mindenki magáénak érezte azt. A termék neve tovább erősítette a csapat identitását.
A projekt közben is, és utána is sokat beszélgettünk egymás között, hogy milyen szerencsés csapatfelállás is volt ez a miénk, és tulajdonképpen hogyan is sikerült ezt összehozni. A titkát őszintén szólva a mai napig nem sikerült megfejtenünk. De talán most azt mondanám, hogy mindenki dolgozott a kódon, és alapvetően megvalósult a collective code ownership és a tulajdonosi szemlélet is. A közös cél is fontos összetartó erő volt, ami rögtön az elején manifesztálódott abban, hogy mi azért vagyunk itt, hogy ezt a projektet sikerre vigyünk, és ezzel a Synergon becsületét is megmentsük.
Az is egy fontos elem volt, hogy Lacival mi barátok voltunk, és Zotyóval kiegészülve hármasban is dolgoztunk korábban már hosszabb ideig a Synergonban. Nagyon jó volt a teljes csapatban a kémia, a csapat törekedett a harmóniára, de voltak konfrontatív tagok is (Kristófra gondolok elsősorban 🙂), ill. olyanok akik speciális tudást hoztak be (Zotyó, Kristóf, ill. üzleti oldalon Endre).
A nagyfokú átfedés a code ownershipen túl a különböző szerepkörök átfedésében is megfigyelhető. Talán furcsa lehet, hogy nincsenek vegytiszta szerepkörök (PO, tech lead, architect, BA, QA), de én úgy látom, hogy ez nagy előny volt, mert senki nem ragaszkodott a saját státuszához, és mindenki a saját képességeinek és motivációinak megfelelően tudott dolgozni.
Nagyon rugalmasnak látom ezt a generalista modellt, hiszen sikerült hátra hagynunk azt, hogy milyennek kellene lennünk a külső modellek alapján (te szoftverfejlesztő vagy, ő tesztelő, én meg BA), így nem skatulyáztuk be magunkat. Ezzel egyidejűleg pedig a csapat minden tagja produktív munkát végzett (architect is, BA is, tech lead is), de még az üzleti szakértő Endre is, hiszen ő a tesztelésben vett részt.
A csapatösszetartás annyira erős volt, hogy szabad időnkben is rendszeresen találkoztunk, és szokásunkká vált a szabadban főzés. Több főzőversenyen is szerepeltünk az évek alatt, de csak úgy, spontán módon is főztünk, amikor úgy hozta kedvünk. Többen egymás esküvőjén is részt vettünk.
Megkértem a csapattagokat, hogy írjanak egy rövid visszaemlékezést, hogy ők hogy élték meg akkor a közös munkát és milyen hatása lett ennek a későbbi karrierjükre. Következzen ez a záró rész.
Endre reflexiója (domain expert)
A legnagyobb tanulságról:
Az alkalmazásról:
Lehet egy üzletileg szerteágazó, robosztus szoftvert fejleszteni úgy, hogy az nem csak a tanúsítás próbáját állja ki, hanem a felhasználók zömének elégedettségére támogatja azok mindennapi tevékenységét. A rugalmas változásmenedzsment lehetőségeit kihasználva a felhasználók javaslatai a folyamatokba rugalmasan beépíthetők, így a termék elfogadottsága magas szintet érhet el.
A CSAPAT-ról:
Itt szeretném megköszönni mindannyiótoknak, hogy ennek a CSAPAT-nak a tagja lehettem. Addig is hittem, hogy közösen jobb eredményt lehet elérni, de itt CSAPAT-ként, együtt bizonyítottuk be, hogy az elérendő cél (egy magas minőségű, az ügyfél igényeit magas szinten kielégítő szoftver fejlesztése) az agilis szoftverfejlesztés módszerének alkalmazásával sikeresen elérhető.
A sikerről:
Azok, akik részt vettek az iratkezelő rendszer fejlesztésében, majd annak bevezetésében, a szakterületüket magas szinten művelték, hittek a CSAPAT-ban, és a projekt sikerében.
A projekt működése során javaslataikkal hozzájárultak a belső folyamatok optimalizálásához.
A szoros határidők és a magas minőség csak a technológiai- és munkafegyelem szigorú betartásával volt elérhető, amelyet sikerült megvalósítanunk.
A közös munka során olyan bizalmi viszony alakult ki a megrendelői oldallal, amely biztosította a gyors információcserét, egyben a nyugodt munkavégzést.
Kristóf reflexiója (architect)
Miért lett sikeres:
Szerintem: a heterogén csapat összeállítás (ha nem is volt feltétlen tudatos) nagyon hatékonynak bizonyult. Többnyire fiatal, szakmailag erősen motivált, egymást kiegészítő tudású emberek gyűltek össze, de a csapat rangidősének tiszteletet parancsoló, szigorú fellépése és a Scrum master lelkes határozottsága is segített a csapat dinamikájának és egyensúlyának a kialakításában és fenntartásában.
Legnagyobb tanulság:
Az agilis módszertan működő, hatékony keretrendszert ad a termékfejlesztés jellegű projekthez, de nem a la carte (ami nem tetszik, azt nem kérem), ahogy a legtöbben kezelik mostanában.
Hogyan járult hozzá a karrieremhez:
Az egyik legkomplexebb sikeres projekt volt amit csináltam. Értsd: a többi vagy jóval egyszerűbb volt, vagy kevésbé sikeres 🙂
Dani reflexiója (gyakornok fejlesztő)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Milyen egy jó csapatban dolgozni, és sikeres projektben fejleszteni. Biztosan jobb alapot adott mint egy-két projekt ami azután jött.
Miért lett ez a projekt sikeres szerinted?
Szakmailag és emberileg is nagyon jó csapat, akiknek fontos volt az összetartás és a siker.
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
Mivel junior voltam ezért gyakorlatilag minden alapot itt tanultam meg, azt gondolom, hogy a lehető legjobb emberektől.
Csuti reflexiója (scrum master)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Ezen a kérdésen sokat gondolkodtam. A legnagyobb tanulság az volt, hogy bonyolult és „akadémikus” módszertanok helyett néhány egyszerű alapelvre koncentrálva meg lehet fordítani egy korábban vesztettnek látszó projektet. Utólag visszaemlékezve ezek az egyszerű alapelvek a következők voltak:
- Csak elkötelezett és tehetséges emberek legyenek a csapatban.
- Legyen a csapatban valaki, aki jól érti az üzleti domaint.
- A (projekt)vezető dolga hogy megteremtse azt a közeget és kiharcolja azokat a feltételeket, amiben az elkötelezett emberek együttműködni és dolgozni tudnak.
- A rendszeres eredmények és a transzparencia a legcsalódottabb ügyfelet is újra partnerré teheti.
Miért lett ez a projekt sikeres szerinted?
A fenti négy tényező és még két fontos ok miatt.
- Egy egyszerű agilis keretrendszert kezdtünk el alkalmazni, de azt a lehető legnagyobb fegyelemmel.
- A csapat szabad kezet kapott a megvalósításban és teljes egészében erre a projektre koncentrálhatott.
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
Ez a projekt alapozta meg azt a szakmai világképet (agilitás), amire az egész azt követő tanácsadói karrieremet építettem. Mivel minden szempontból hátrányos helyzetből indult a projekt (csalódott, tekintélyelvű, államigazgatási ügyfél számára külsősként fejlesztett alkalmazás) ezért számomra élő bizonyíték arra, hogy ha a megfelelő feltételek rendelkezésre állnak, akkor bármilyen környezetben lehet sikeres agilis fejlesztés megvalósítani.
Zotyó reflexiója (senior fejlesztő)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Milyen sokat számít és segít, ha a megrendelő ténylegesen bevonódik a projektbe a kezdetektől a végéig a megfelelő kulcsfelhasználókkal.
Illetve a közös nyelv fontossága.
Miért lett ez a projekt sikeres szerinted?
Három fő ok miatt:
- Scrum: a rendszeres demoknak köszönhetően azonnal visszajelzést kaptunk a megrendelőtől, hogy jó irányba haladunk-e.
- Az egész fejlesztő csapat magáénak érezte a projektet és a teljes kódot. Az egyes fejlesztők nem csak arra az egy feladatra fókuszáltak amit éppen csináltak, hanem az egész projekt sikeressége lebegett a szemük előtt.
- A megrendelő aktív részvétele a megfelelő kulcs felhasználókkal a teljes folyamatban. És valószínüleg ennek az aktív részvetelnek is köszönhetően ők is teljes erőbedobással dolgoztak, hogy sikeres legyen a projekt.
A második (2.), ha nem is fontosabb mint az első (1.), de nehezebben érhető el, ezért ritkábban találkoztam ilyennel a 30+ éves pályafutásom alatt.
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
Nagyon sok technológiát ebben a projektben ismertem/tanultam meg.
De még hasznosabb és fontosabb volt, hogy itt tapasztaltam meg először az agilis módszert és azon belül a scrum keretrendszert élesben.
Aztóa sok scrumos projektben vettem részt, de egyikben sem sikerült ennyire jól adoptálni a scrum keretrendszert.
Legtöbbször a megrendelő aktív részvételét nem sikerült ilyen jól elérni.
Szinten ennek a projektnek köszönhetően vált mániámmá a közös nyelv kialakításának/megtanulásának fontossága. 😉
Janó reflexiója (junior fejlesztő)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Egy megfelelő tudással rendelkező, motivált csapat előtt nem léteznek akadályok.
Miért lett ez a projekt sikeres szerinted?
A projekt egyik nagy eredményének azt tartom, hogy egy időtálló megoldás koncepcióját sikerült kidolgozni szoros együttműködésben a megrendelővel.
A szerződéses, szervezeti és jogszabályi követelményeknek való megfelelésen túl sikerült egy olyan modellt közösen kialakítani, amelyben megjelentek az ügyfél valódi igényei is.
Ezáltal egy, a hétköznapokban is egyszerűen alkalmazható, felhasználóbarát megoldás jött létre.
(Ehhez az kellett, hogy Magyarországon az elsők között valósítottunk meg agilis szoftverfejlesztési projektet – helyesen.)
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
Hatalmas lehetőségként éltem meg, hogy részese lehettem a csapatnak, rövid idő alatt nagyon sokat tudtam fejlődni.
A kollégáim hagytak kibontakozni és még támogattak is abban, hogy megtaláljam a helyemet a szakmán belül.
A mentoraimtól kapott agilis gondolkodásmód felülírta bennem a szoftverfejlesztésről és szervezetek működéséről kialakított korai elképzeléseimet.
Kulcsi reflexiója (UI/UX expert)
Kulcsi külön cikket írt saját megéléséről.
Laci reflexiója (vezető fejlesztő)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Az informatikai projektek amikben addig szerepelnem kellett, többségében mind átláthatatlan, bonyolult technológiák, nem kevésbé átláthatatlan és bonyolult üzleti specifikációk kuszaságában folyt.
A legnagyobb tanulság, hogy lehet ezt máshogy is csinálni. A scrum módszer helyes használatával, üzleti szakértő bevonásával, ligthweight technológiákat alkalmazva sikereket lehet elérni.
Miért lett ez a projekt sikeres szerinted?
A kivételes csapat miatt. Abban a szerencsés helyzetben voltam, hogy barátokkal dolgozhattam
együtt, akik mellesleg rendkívül tehetségesek is. Üzleti domain specialista, az üzletet is érteni akaró tehetséges fejlesztők, és persze az ezt lehetővé tévő management és módszertan is kellett a sikerhez.
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
Rengeteget tanultam, tapasztaltam. A csapat fontossága, az agilis elvek, lightweight technológiák alkalmazása azóta is meghatározzák a karrierem. Itt igazán meg lehetett szeretni a szakmát. Szerencsések voltunk, hogy ilyen csapatban dolgozhattunk.
István reflexiója (Vezető fejlesztő, Product Owner)
Mi volt az, ami számodra a legnagyobb tanulság volt a projektben?
Ha hiszünk abban, hogy jól érdemes csak csinálni, akkor az eredmény is automatikusan jó lesz.
Miért lett ez a projekt sikeres szerinted?
Az ambíciózus, hozzáértő baráti csapat miatt, aki az ügyféllel is ki tudtak alakítani a bizalmat. Ehhez szükséges volt a menedzsment támogatása is.
Hogyan járult hozzá ez a projekt a szakmai karrieredhez?
- Elkezdtem blogolni (infokukac.com)
- Soha többet nem dolgoztam nem agilis projektben. (Vagy ha igen, rövid idő után kiléptem, mert nem bírtam.)
- Társalapítója lettem a be-novative nevű startupnak.
- 2010-ben kiadtuk Csutival a Kanban és Scrum – mindkettőből a legjobbat e-könyv magyar fordítását. Emiatt sokan megismerték a nevemet agilis körökben.
- Az iratkezelő megalapozta a tanácsadói karrieremet, az agilitás egy biztos pont lett az életemben (agiluu.hu)
