Oczywiście, sprawa jest delikatna bo to zespół powinien sam jakby dojść do tego, sam czuć się źle z tym, że nie dotrzymał swoich zobowiązań w jakiś sposób. Dlatego najlepszym rozwiązaniem jest dobra retrospekcja – i dlatego jest taka ważna. Retrospekcje to jest w ogóle rzecz, której robii się zdecydowanie za mało – my sami robimy je zdecydowanie za rzadko.

Widziałem taki zespół. Ruszenie go z posad status quo było trudne i nie do końca się to udało. Zdecydowanie ziarno Scruma zaowocuje najlepiej tam, gdzie ludzie są otwarci na zmianę, chcą się uczyć i lubią to co robią.

Wspomniałeś w artykule o czymś co mnie zainteresowało.Ostatnio byłem na wrocławskim spotkaniu Agilopolis gdzie dyskutowano o tym w jakich kategoriach nalezy traktować sprint, w którym zespołowi nie udało się wszystkiego zrobić. Było kilka zdecydowanych głosów, że nie można mówić o porażce zespołu czy rozpatrywać wynik w kategoriach winy. Mówiono raczej o sprincie w którym nie wykonano wszystkich zadań. Ja osobiście się z tym zgadzam – faktycznie może to działać demotywująco na zespół. Niemniej jednak granica między mówieniem o sprincie że się nie udał i był porażką a tym że zespół nie zrobił wszystkiego co zaplanował jest cienka i łatwo ją przekroczyć.
Jak według Was powinno mówić się o sprincie który się nie udał? Ciekawy jestem jakie macie zdanie na ten temat.

Pamiętam na przykład, że jeden z kolegów przedstawił sytuację, w której PO nie jest osobą na tym samym poziomie technicznym co zespół. Dyskusja była zbyt wielowątkowa i pomysły zbyt szybkie, żeby były pomocne.
Proponuję etap dyskusji prowadzić nie poziomo (czyli np. po warstwie obowiązków PO), a pionowo, czyli przydzielić jednej osobie czas na przedstawienie problemu, przejście przez rozwinięcie tematu bez wymyślania szybkich gotowców, a wnioski wyciągnąć na koniec.