Agilis szervezetek – tapasztalatok belső szemmel – 3. rész

Avagy milyen előnyökkel és hátrányokkal találkozik az, aki egy agilisan működő szervezetben dolgozik.

4 részes cikksorozatunkban körül járjuk a hagyományos és agilis szervezetek közötti különbségeket, azok nehézségeit és előnyeit. Tapasztalatok első kézből.

Elaprózott és hiányos információk

Számos csapat néz azzal szembe, hogy erősen hiányos információk alapján kényszerül dolgozni, és védeni magát:

• Minden fórumon felemlegetik a specifikáció hiányát, ami nagyon is rendben van, az a nagyobb baj, amikor ezt már nem teszik,
• Hibásan működő szoftver kerül lefejlesztésre, ami már nincs rendben.

Van különbség azonban aközött, hogy sose készül megfelelő részletességű specifikáció, és aközött, hogy eltérő az egyes dokumentum kidolgozottságának a mélysége.

• Az előbbi jó eséllyel szakmai inkompetenciára utal, nem a megfelelő ember ül ezen a helyen és a szervezet céljait egy alkalmasabb ember nagyobb mértékben szolgálná.
• Illetve még felmerülhet az is, hogy valaki a pozícióját védi azzal, hogy visszatart információkat.
• A második azonban sokkal inkább túlterheltségre, meglehet, hogy termékmenedzser oldalról alul lett tervezve a csapat vagy szervezet.

A kontextus válogatja, hogy ezek közül melyik verzió bizonyul igaznak, akárhogy is, mindkettő azonnali beavatkozást sürget. Ez bizonyosan megnehezíti a munka haladását.

Az agilis struktúra azzal segít, hogy kierőlteti a backlog transzparenciáját, azonban ennek mélységét csak érintőlegesen tárgyalja.

Pár tanács ezzel kapcsolatban, nekem a következők váltak be:

• Minden fejlesztési igényt alapos kutatás kell megelőzzön, ahol az üzleti igények alapos felmérésre és priorizálásra kerülnek, majd ezek egy mindenki által elérhető dokumentumtárban megjelennek.
  • Lehet ez akár egy Wiki-, vagy még inkább egy Confluence oldal.
  • Utóbbi esetben mindenképp érdemes a Jira jegyhez csatolni.
• Az üzleti rész mellet technológiai oldalról is alapos tervezés kell megelőzze, amit szintén le kell írni.
• Kickoff meetingen összegyűjtjük az összes szerepkört, akik érintettek lesznek a fejlesztésben, itt két cél is lesz.
  • A termékgazda átadjon minden szükséges információt.
  • Mindenki megszerezzen minél több információt.
• Napról-napra a frissen felmerülő kérdéseket rövid szinkronizációs meetingeken válaszoljuk meg.

Ahogy az előző téma kapcsán is, itt is rendkívül fontos, hogy kompetens és gyors döntések szülessenek.

Nem megfelelő a csapat felépítése

Az agilis módszertanok elég elnagyolt iránymutatást adnak a csapat összeállítása kapcsán. Persze legyenek kereszt-funkcionálisak, legyen meg minden szükséges szerepkör, lehetőleg legyen mindenki dedikált. Ez elvi szinten kiváló, de a valóságban számos hiba tud ebbe csúszni, ha nincs meg a kellő odafigyelés:

• Nem áll rendelkezésre minden szükséges szakértelem,
• Adott feladatra nem megfelelő a tapasztalat,
• Alultervezett a létszám,
• Egy vagy több szerepkör esetében korlátozottak a lehetőségek, úgynevezett erőforrás poolból kell dolgozni, azaz más csapatokkal megosztozva,
• Emberileg nem illenek össze a csapattagok.

Ezzel kapcsolatban több tanácsom is van:

• A csapatok összeállításánál különösen oda kell figyelni vezetőként, hogy emberileg a csapat jól illeszkedjen. Sokszor szakmailag egyébként magas szintet képviselő emberek sajnálatos módon rombolják maguk körül a csapatokat.
• A technikai oldalon sok ember nagyon jól képezhető és hamar fel tud szedni új tudást.
• Időben és hathatósan kell eszkalálni az erőforrás problémákat, minél később derül ki, annál biztosabb, hogy rossz következményekkel fog járni.

Folytatás Agilis cikksorozatunk 4. részében!

Kapcsolódó tanfolyamok

1. Digitális termékmenedzsment
2. Appmenedzsment és marketing