Ako som spomínal, každá dobrá metodika tvorby softvéru by mala mať v sebe zapracované mechanizmy na optimalizáciu vlastných procesov. Práve to je cieľom tohto meetingu: ako robiť veci efektívnejšie.
Mali by sa teda nájsť body, ktoré môžeme zlepšiť. Keďže ich môžeme zlepšiť, do teraz nefungovali optimálne. Podotýkam, toto je konštruktívna kritika. Aj konštruktívnu kritiku si niektorí jedinci dokážu brať osobne a radšej ako ju prijať obviňujú všetkých naokolo. Práve cez tohto by sa mal SCRUM Master dostať využitím svojich soft skills napr. asertivita.
Preto radšej by SCRUM Master by mal rozprúdiť diskusiu, ako zlepšiť jednotlivé procesy vývoja tohto softvéru, v ktorých procesoch vidia členovia tímu medzery. Keďže procesy nie sú živé (nemajú oči, nos) sa nemôžu brániť, a tak si členovia tímu nebudú brať rady na zlepšenie osobne. Vylepšením procesu vylepšia seba, čiže odstránia svoje nedostatky.
Skúsený SCRUM Master vie, že jednotliví členovia tímu môžu mať sklony k tomu, že sa budú vzájomne konfrontovať resp. obviňovať. Je na ňom, aby uriadil diskusiu tak, aby sa venovala konštruktívnemu zlepšeniu procesov.
Toto sú body, ktorými by sa mal tento meeting venovať:
Product Owner by mal vyhodnotiť priebeh šprintu. Mal by sa vyjadriť k hodnoteniam (v prvom rade k ) procesov a prípadne členov tímu. Mal by konštruktívne navrhnúť opatrenia, ktorými by nastali pozitívne zmeny.
Aj jednotliví členovia tímu môžu hodnotiť a navrhovať vylepšenia procesov, ktoré by poviedli ku skvalitneniu vývoja a tým aj výsledného softvéru.
Marián Knězek