avagy „Jól költöttük el az ügyfél pénzét?”

Minden Scrumban működő Csapat -ideális esetben- tartja magát a Sprint Ceremonyk rendszeres és hatékony tartásához:

• Planning
• Daily Stand Up
• Sprint Review (vagy más néven megrendelői demo)
• Retrospective

Az összes meetingnek megvan a jól átgondolt, világos célja, dramaturgiája, szabályai. Ezek közül most a megrendelői demora térünk ki.
Körbejárjuk a meeting formai kötöttségeit, közben kiderítjük miért jó minden Sprint során együtt tölteni néhány órát az ügyfél és a szállító képviselőinek. Mik azok az aspektusai, amikhez ragaszkodnunk kell, és hol lehetünk kreatív Scrum Masterek?

Célja:

Elsősorban a „Customer Acceptance”. Vagyis hogy a megrendelő elfogadja amit a Csapat letett az asztalra az aktuális Sprintben.
Ha pedig ez mégsem sikerülne? Akkor is felbecsülhetetlen visszajelzéseket adhatnak arra, hogyan tegyük újra irányba a termékfejlesztést. Persze van egy előzetes szűrő is, a Definition of Done (“akkor és csak akkor van kész, ha teljesülnek azok a feltételek, hogy…”), mivel ideális esetben ezek minden Demo előtt teljesülnek.

Hossza:

Erről más-más vélemények vannak. Van aki szerint minden egyes ledolgozott hét után 1 órát kell(ene) rászánni, vagyis egy 2 hetes Sprintet 2 órás Customer Demoval zárunk. Máshol 1 óra alatt lezavarják…. eddigi tapasztalataim alapján itt is az „Attól Függ” szabály érvényesül. Tehát Scrum Masterként biztosítsunk legalább 1,5-2 órát mindenki naptárjában, hogy legyen idő az összes felmerülő kérdést megvitatni, és a résztvevők fejben már ne a következő meetingen tárgyaljanak. Viszont ha sikerül az effektív résszel rövidebb idő alatt is végezni, a beszélgetésen pedig már nagyanyáink legjobb Linzer-receptje is feljön, nyugodtan lezárhatjuk előbb is.

Résztvevők:

Az Ügyfél Demót sokszor célszerű, ha a Product Owner vezeti a Scrum Master facilitálása mellet. Mivel a Product Owner a Backlog (termék) legfőbb felelőse és ismerője, ő tudja a legjobban összekapcsolni a fejlesztést és az üzletet. Jó még, ha bent van egy senior csapattag, tipikusan egy vezető fejlesztő vagy architekt arra az esetre, ha mélyebb technikai kérdés is felmerül akár az eddigiek kapcsán, akár a továbbiakra nézve. Kiegészítés: több csapatos termék esetén, természetesen legjobb, ha minden csapat képviselteti magát.

*Dark Scrum Master Note*
Előfordul, hogy egy Csapat több egymás utáni Sprintet is elbukik. Ennek persze millió oka lehet, de ha úgy érezzük, hogy a hozzáállás nem megfelelő, átállhatunk a sötét oldalra. Felesleges felelősöket keresni; hívjuk be az egész Csapatot a Demora, ne csak a Product Owner érezze magát kellemetlenül, hanem közösen vállalják a felelősséget. Ez általában egyszerűbb/gyorsabb/hatékonyabb megoldás, mint válságkezelő és teljesítményértékelő meetingek sorozatát összehívni. Nem beszélve arról, hogy a nyomozás könnyen blaming game-be csap át, aminek mindig csak vesztesei vannak.

Agenda:

Facilitátorként elég nagy költői szabadságot élvezünk, ugyanis néhány fontos pontot kell csak betartanunk, azon belül viszont saját szájízünk szerint, az aktuális helyzetnek megfelelően alakíthatjuk a dramaturgiát:

• Köszöntjük a kedves egybegyűlteket, dióhéjban elmondjuk a meeting célját és agendáját.
• Először is bemutatjuk, mire tett vállalást a Scrum Csapat az aktuális Sprintre vonatkozóan
  • érdemes nyomtatott formában odaadni minden résztvevőnek az elkészült itemek rövid kivonatát, mint egy kis programfüzetet. Jegyzetelhetnek is rá, ráadásul a papíron nem ugranak fel értesítések, ellentétben a céges laptopokkal.
• Bemutatjuk, mennyit/milyen formában sikerült teljesítenie a Csapatnak az általuk tett vállalásból.
  • érdemes megjelölni, mely vállalások voltak architekturálisak és melyek közvetlen üzleti értéket teremtők (megrendelői szempontól lényegesen nagyobb súlyú az utóbbi)
  • kitérhetünk arra is, milyen kulcsfontosságú döntések/változtatások születtek az iteráció során
  • itt bemutathatunk méréseket is, amikre az üzlet számot tart, vagy a Product Owner valamilyen okból fontosnak tartja. Ez nem közvetlenül kapcsolódik az üzleti értékhez, ám a fejlesztési folyamatok optimalizálása kulcsfontosságú, ezért valahol mégis mindenki érdeke
• A vita helye itt következik. Visszajelzéseket gyűjtünk, meghatározzuk a további fejlesztési irányelvet. Facilitátorként kiemelten oda kell figyelnünk arra, hogy lehetőleg senki ne távozzon úgy, hogy látható kétségekkel/kérdésekkel küzd. A technikák és praktikák arzenálját mind-mind itt élesíthetjük.
• Lezárjuk a Megrendelői Demot, vagyis összegezzük a hallottakat és megköszönjük mindenkinek a részvételt.
  

+1 Híres bukások:

Tudtátok, hogy az irodai élet Szent Gráljának számító post-it cetlik tapadó anyagát eredetileg a repülőgép-iparba tervezték, ultraerős ragasztónak?
És azt, hogy a Viagra eredetileg szívgyógyszernek szánták, és amiről végül elhíresült, igazából egy mellékhatás volt?
A tanulság: néha mindenkinek lehet akkora mázlija, hogy bár a kitűzött célt nem éri el, útközben áttörést ér el egy másik területen. Mi azért igyekezzünk profi Scrum Masterként működni, és minél kevesebb teret engedni a véletleneknek. ?

A tanulság tanulsága:

A Demo értékét tehát  nem lehet eléggé hangsúlyozni, ha a stakeholderek informálásáról van szó, a termékfejlesztés tekintetében. Teret enged a megrendelői visszajelzéseknek, és (építő jellegű) vitaindító is lehet akár a Product Ownerrel, akár Csapat más képviselőjével. A cél természtesen itt is az üzleti érték maximalizálása.
Hogyan?
Egy ilyen beszélgetés inputot képezhet a Backlog további alakításához, vagy akár közvetlenül a következő Sprint Planninghez is.

Ámen

RendszerGazda