Jak wspomniałem, każda dobra metodyka tworzenia oprogramowania powinna mieć wbudowane mechanizmy optymalizacji własnych procesów. To jest dokładnie cel tego spotkania: jak robić wszystko efektywniej.
Powinny więc istnieć pewne punkty, które możemy poprawić. Ponieważ możemy je ulepszyć, dotychczas nie działały optymalnie. Uwaga, jest to konstruktywna krytyka. Niektóre osoby potrafią nawet konstruktywną krytykę potraktować osobiście i zamiast ją zaakceptować, obwiniają wszystkich wokół siebie. Właśnie przez to powinien przejść SCRUM Master wykorzystując swoje umiejętności miękkie. asertywność.
Dlatego SCRUM Master powinien raczej rozpocząć dyskusję na temat tego, jak udoskonalić poszczególne procesy tworzenia tego oprogramowania, w których to procesach członkowie zespołu widzą luki. Ponieważ procesy nie są żywe (nie mają oczu, nosa) nie mogą się obronić, dlatego członkowie zespołu nie będą osobiście korzystać z porad dotyczących usprawnień. Udoskonalając proces, doskonalą siebie, czyli eliminują swoje niedociągnięcia.
Doświadczony SCRUM Master wie, że poszczególni członkowie zespołu mogą mieć tendencję do konfrontowania się ze sobą lub winić. Do niego należy takie zorganizowanie dyskusji, aby była poświęcona konstruktywnemu doskonaleniu procesów.
Oto kwestie, którymi powinno zająć się to spotkanie:
Właściciel Produktu powinien ocenić postęp sprintu. Powinien komentować oceny (przede wszystkim) procesów i ewentualnie członków zespołu. Powinien konstruktywnie proponować działania, które przyniosą pozytywne zmiany.
Nawet poszczególni członkowie zespołu mogą oceniać i proponować ulepszenia procesów, które doprowadzą do lepszego rozwoju, a tym samym powstałego oprogramowania.
Marián Knězek