Na końcu każdej iteracji Scrumowej zespół przeprowadza dwa spotkania. Ich celem jest inspekcja i adaptacja (inspect & adapt), czyli analiza przebiegu iteracji w poszukiwaniu możliwości poprawy i dostosowania się do zmian zachodzących w otoczeniu projektu. Pierwsze z tych spotkań, czyli Przegląd Sprintu (Sprint Review), koncentruje się na tworzonym produkcie. Natomiast w trakcie Retrospektywy (Sprint Retrospective) zespół szuka możliwości poprawy sposobu działania. Dyskusja może dotyczyć zarówno tematów inżynieryjnych („W module X jest pełno błędów, trzeba go przepisać.”), związanych z planowaniem pracy („Znowu nie skończyliśmy wszystkich historyjek, które chcieliśmy dostarczyć. Musimy inaczej planować iteracje.”), komunikacyjnych („W trakcie iteracji Product Owner jest cały czas na różnych spotkaniach. Ustalmy z nim, kiedy będzie miał czas tylko dla nas.”), czy też logistycznych („Potrzebujemy więcej tablic magnetycznych”). Wynikiem spotkania są akcje, które zostają podjęte w trakcie następnej iteracji albo poprzez zespół (czyli stanowią część Rejestru Iteracji – Sprint Backlog) albo przez Scrum Mastera (wtedy są dopisywane do Rejestru Przeszkód – Impediments Backlog).
Pierwsza Dyrektywa
Jedną z najczęściej wymienianych reguł Retrospektywy jest tak zwana „Pierwsza Dyrektywa” z książki Norm’a Kerth’a pt. „Project Retrospectives”.
„Niezależnie od tego, co odkryjemy, rozumiemy i głęboko wierzymy w to, że biorąc pod uwagę swoje umiejętności i wiedzę, dostępne zasoby i obecną sytuację, każdy z nas wykonał swoją pracę najlepiej jak potrafił”.
Jej celem jest przede wszystkim zapewnienie wszystkim uczestnikom spotkania poczucia komfortu i bezpieczeństwa. Ma tym samym umożliwić wspólne poszukiwanie rozwiązań, a nie winnych problemu.
Dobre jest wrogiem lepszego
Jeżeli jednak zrobiliśmy wszystko jak mogliśmy najlepiej, to skąd ma się wziąć motywacja do poszukiwania i wprowadzania lepszych rozwiązań? Dlaczego mamy poprawiać coś, co jest już dobre? Na myśl przychodzi europejska wersja okładki albumu Fatboy Slim’a „You’ve Come a Long Way, Baby” z mocno otyłym chłopcem w podkoszulku z napisem „I’m #1 so why try harder”. My jesteśmy najlepsi, nasz proces jest najlepszy, po co się męczyć i go poprawiać?
Według mnie w dyrektywie brakuje elementu, który zmuszałby nas do szukania lepszego rozwiązania. Jest nim potrzeba podnoszenia poprzeczki, świadomość że coś nie działa jak należy, lub że popełniliśmy błąd. Nie mówię tutaj o poszukiwaniu kozła ofiarnego wewnątrz lub na zewnątrz zespołu. W pierwszym przypadku uzyskamy jedynie walkę na argumenty, w drugim narzekanie w stylu „gdyby nie oni” prowadzące jedynie to tworzenia podziałów na „my” i „oni”. To co mam na myśli to otwarte przyznanie, że coś nie działa tak jak powinno. Przecież metodyki Agile nie powstały dlatego, że wszyscy byli zadowoleni z pracy w modelu kaskadowym. Zostały stworzone, bo byli ludzie mający odwagę się przyznać, że tradycyjne podeście się nie sprawdza. Gdy będąc programistą z powodu pośpiechu nie przygotuję testów jednostkowych do mojego kodu, albo jako tester jedynie pobieżnie przetestuję Historyjkę, to ma to wpływ na jakość produktu. Muszę wtedy mieć odwagę przyznać się przed samym sobą i zespołem. Przy czym podkreślę raz jeszcze, że nie chodzi mi tu o formalną (samo-) krytykę, ale o refleksję, która doprowadzi do pełnego zrozumienia problemu i poszukiwania lepszego rozwiązania. Musimy więc oddzielić człowieka od jego czynu. Nie atakować tego pierwszego, ale przeanalizować nieefektywne działanie, aby wyciągnąć wnioski jak uniknąć podobnej sytuacji w przyszłości.
Poza Agile
Koncepcja samodoskonalenia się poprzez uświadomienie sobie faktu popełnienia błędu, przyznania się do niego i chęci szukania lepszego rozwiązania jest równie stara jak historia ludzkości. W IV wieku p.n.e. Arystoteles w „Poetyce” stawia tragedii greckiej za cel wzbudzenie u widza uczucia „litości i trwogi” prowadzącej do osiągnięcia Oczyszczenia (Katharsis). Na tej idei wiele wieków później będzie bazował Zygmunt Freud w swoich pracach nad psychoanalizą.
Również w kulturze chrześcijańskiej wyraźnie widać podobną koncepcję w sakramencie pokuty. Pięć czynności wymaganych od osoby przystępującej do spowiedzi obejmuje rachunek sumienia (refleksji pozwalającej na uświadomienie sobie, co zrobiłem dobrego, a co złego), żal za grzechy (przyznanie się do winy) oraz mocne postanowienie poprawy (na przykład poprzez określenie, z którą „ułomnością” chcę się uporać).
Wychodząc poza kontynent europejski natkniemy się na Hansei – Japońską autorefleksją mającą na celu wyrażenie skruchy i poprawą zachowania. Oczekuje się jej zarówno od dzieci, które coś „zbroiły”, jak i pracowników firm czy polityków, którzy popełnili błędy. W Systemie Produkcyjnym Toyoty (TPS, Toyota Production System), od z którego wywodzi się podeście Lean, Hansei jest niezbędnym elementem ciągłej poprawy procesów (Kaizen). Hansei-kai, czyli zebrania poświęcone refleksji, mają na celu odkrycie i zdiagnozowanie własnych słabości, aby móc w przyszłości je pokonać. Spotkania te odbywają się na zakończenie każdej fazy opracowywania nowego pojazdu. Tym samym są w TPS odpowiednikiem Retrospektywy ze Scrum’a. Dość dokładną analizę Hansei przedstawia Jeffrey K. Liker w książce „Droga Toyoty”. Wspomina w niej również o dużej niechęci pracowników amerykańskich, gdyż „przyjmują krytykę w sposób osobisty i negatywny”. Stąd już prosta droga do pierwszej dyrektywy i samozachwytu, że wszystko co robimy, robimy najlepiej.
Potrzeba matką wynalazku
Tragedia grecka, spowiedź, czy Hansei mają jedną wyraźną cechę wspólną. Wszystkie te podejścia zakładają, że przed poszukiwaniem lepszej drogi, wytworzymy w sobie potrzebę zmiany poprzez przyznanie się do popełnionego błędu i dokładne jego przeanalizowanie. Dlatego, w trakcie następnej Retrospektywy, nie ograniczajmy się znowu do poklepywania po plecach lub wspólnego narzekania, ale zastanówmy się również co było nieefektywne, jakie popełniliśmy błędy i jak ich w przyszłości uniknąć
