Agile coaching

Kiderült, hogy a kollegáimnak, a cég nagy öregjeinek, akik 5-10 éve ott dolgoznak, nem igen volt alkalmuk kipróbálni az agile fejlesztési módszertant. Mert házon belül nem volt ilyen munka. Nekem, aki mindenféle cigány munkát végeztem, hol itt, hol ott, a telefonszolgáltatónál volt kb 10 hónap tapasztalatom, na meg a 3 diplomamunkámmal kapcsolatos interjúk a volt budapesti munkahelyemen, amibõl az agile coaching tanulmányt írtam. A lényeg, úgy néz ki nekem van eddig a legtöbb agile tapasztalatom, és hirtelen elõléptem agile coach-csá.

Történt, hogy az egyik projektem átállt agile fejlesztésre, engem meg behívtak szakérteni teszteléssel kapcsolatban. Csirke vagyok, nem szólok a napi megbeszélésen, de utána elmondtam a "project manager"-nek, aki afféle scrum master és product owner egyben, hogy nem kellene a napi negyedórás megbeszélést 40 percesre húzni, az elején elhagyhatja a 20 perc infosharing-et (amikor õ beszél, hogy mit kellene csinálni), és ne azt kérdezze "do you have anything to report", hanem azt, hogy mit csinált tegnap, mit csinál ma, és van-e akadály, és hogy ne õ maga egy excel táblában vezesse melyik feladat hogy áll, bemondás alapján, hanem tegyék fel táblára a sárga cetliket, és minden fejlesztõ maga "dokumentálja", hol tart. Ja, mondja, nehéz leszokni a poject manager szereprõl. Meg azt is szóvá tettem, hogy sprint közben új feladatokat vett fel a backlogba, amit nem lenne szabad, mert borul a sprint. (Értsd: ha nem terveztél takarítást a hétre, akkor már ne is takaríts, különben nem lesz idõd mosni, mosogatni, fõzni.)

Ezek után elkezdték kérni a tanácsaimat. Jönnek hosszú tömött sorban, hogy hogyan is kellene áttérni az agile-ra. Persze elõsorban a tesztelést illetõen, mert fejleszteni mindenki tud. Én meg szkeptikus vagyok, igazán minõségi terméket csak alaposan megtervezve lehet csinálni, vagy úgy se, hát még ha elhagyjuk az alapos tervezést...

Ráadásul különféle szakértõink vannak. Van, aki ismeri az üzleti folyamatot, van, aki tud programozni SAP-t, van, aki a vendor kütyüjéhez meg annak a speciális programozásához ért, van, aki tud(na) tesztelni, és vannak a felhasználók, akik szintén tanulnák és tesztelnék az új rendszert, na ezeknek a többsége biztos nem lenne képes programozni, tehát a mindenki csinál mindent elv borul. Mindenki mást tud csinálni, és ilyen esetben a Kanban jobb módszer lenne, mint a scrum, nem értem miért nyomja mégis mindenki a scrum-ot. Talán azért, mert a scrum-ra van akkreditált oktatás, el lehet menni 3 napos tanfolyamra, a Kanban meg túl flexibilis, annyira, hogy ötvözhetõ a scrum-mal.

Ha engem kérdeznének, én a Kanban-t tenném kötelezõvé. Vizualizáljanak, csináljanak krossz-funkciós csapatokat, ütlessenek mindenkit egyrakásra, csináljanak napi 15 perces standup-ot, csináljanak idõnként retrót, és kit érdekel, hogy egyes feladatok 1 hét alatt, mások 6-8 hét alatt lesznek készen, ha mindenkinek megmarad a feladatköre, és lehet az átfutási idõt optimalizálni.

Szóval úgy lettem agile (scrum) tanácsadó, hogy minden belsõ szervem tiltakozik a Scrum fejetlen bevezetése ellen. Mert csak akkor mûködik, ha úgy csinálják, ahogy kell. Ha nem úgy csinálják, rosszabb, mint a májkroszoft projektes projekttervezés. És amit még mindig nem értettek meg: az agile bevezetése nem mindenhol érdemes, és hogy fájdalommal jár. Értsd: lesznek, akik el fognak menni. Leginkább a jobb szakemberek, akik találnak máshol is munkát.

A többit olvassátok el a diplomamunkámban, vagy az Ezerarcu coaching c. könyvben.

---
Jut eszembe, hogy a coach diplomamunkámat aktuális lenne lefordítani angolra, hogy értsék, hiába hivatkozok rá, ha csak magyarul van....
---
Mielõtt keresni és számonkérni kezditek, a második diplomamunkám soha nem készült (még) el.