Oczekiwaniem wielu organizacji jest osiąganie 100% sukcesu we wszystkich działaniach. Każdy plan musi być wykonany. Każdy eksperyment udany. Gdy wykonana praca nie przynosi oczekiwanych rezultatów często zaczyna się szukanie osób odpowiedzialnych. Wypowiedzi “zespół nie dostarcza”, “zespół nie jest skomitowany” są sygnałem alarmowym. “Commitment”, który jest Wartością Scrum odnosi się do naszego zaangażowania. Oznacza, że zespół całą swoją energię wkłada w prace przybliżające Cel Sprintu. Bywa jednak mylnie tłumaczony, jako “zespół musi dostarczyć wszystko co obiecał na początku Sprintu”. To z kolei powoduje, że zespół planuje z buforem i unikania eksperymentów. Jednak Scrum to system “uczący się” a w większości przypadków uczymy się na błędach. Dlatego jeżeli nie dajemy sobie prawa do ich popełniania to ograniczamy możliwość uczenia się. Jak to powiedział Edison:
“Nie odniosłem porażki. Po prostu odkryłem 10.000 rozwiązań, które nie działają”
Dużo vs realnie
Pora na rachunek sumienia czyli “jak Agile Coachowie dostarczają sprinty”. Nawet u nas zaobserwowaliśmy kilka typowych zachowań.
Nasz pierwszy sprint nie był pełnym sukcesem. Miał się skończyć w czwartek. We wtorek dopadło nas przerażenie. Nie ma szans, żebyśmy zamknęli wszystkie zaplanowane zadania. Najpierw odpala się instynkt nadgodzin („jeśli posiedzę dodatkowe 4h w nocy to może się uda”), potem faza tłumaczenia (“ale nie powiedziałaś”, “za późno przyszły grafiki”, “na moim ekranie wygląda ok”), w końcu pytanie „to może wydłużymy Sprint?”. Efekt – w piątek wszyscy byliśmy nieprzytomni ze zmęczenia.
Uczymy się na błędach
Za to retrospektywa była bardzo ciekawa. Najważniejsza lekcja z tego Sprintu to “ile to jest właściwa ilość pracy na tydzień”. Chcemy tworzyć realistyczny plan, bo zawsze wydarzą się rzeczy, które nas zaskoczą. Inną ważną rzeczą, której się nauczyliśmy to jak usuwać zadania ze Sprintu. Przecież i tak nie możemy w połowie rozgrzebanych elementów wypuścić na produkcję.
Reaguj na niespodzianki
Ci którym się wydaje, że jeden nieudany Sprint załatwia sprawę mogą się zawieść. W innym sprincie znów życie nas zaskoczyło. Zaplanowaliśmy dla Was włączenie szkoleń. Wszystko posuwało się zgodnie z planem i wyglądało na to, że dostarczymy to co zaplanowaliśmy. Dzień przed końcem Sprintu uderzyło nas odkrycie. Zapomniałam w planach o „niewielkiej” funkcjonalności jaką jest rejestracja na szkolenie :). Było już za późno, żeby cokolwiek zmieniać w tym sprincie. Dlatego zrobiliśmy burzę mózgów i stworzyliśmy rozwiązanie hybrydowe. Spieliśmy część nowej i starej funkcjonalności, żeby umożliwić Wam rejestrację na szkolenie. Nie jest idealne, ale funkcjonuje. Za tydzień poprawimy i rozbudujemy. A przy okazji dowiedzieliśmy się, że funkcjonalności da się jeszcze bardziej zdekomponować.
Nasze dobre praktyki
Podsumowując:
- Każdemu zespołowi zdarzy się nie dostarczyć pełnego zakresu Sprintu. Jeżeli nie skupicie się na szukaniu winnych a wykorzystacie to jako lekcję to będziecie mogli się dużo na niej nauczyć. Ważne, żeby wyciągnąć wnioski a nie mieć nadzieję, że sytuacja już się więcej nie powtórzy.
- Nadgodziny i tłumaczenie się nie są rozwiązaniem – odpuśćcie sobie je od razu.
- Codziennie sprawdzajcie czy wasze plany są wciąż realne (od tego macie Daily). Jeśli nie, to je zmieńcie:
- Zobaczcie co możecie zrobić inaczej, aby osiągnąć Cel Sprintu
- Zobaczcie co możecie ze Sprintu usunąć. Pamiętajcie, że elementy w sprincie też mają swój priorytet. Usuwajcie te najmniej ważne i te, których jeszcze nie rozpoczęliście. Oczywiście w tym przypadku będzie potrzebna zgoda Product Ownera.
Sprint, który was zaskakuje jest prawdziwym problemem tylko wtedy, gdy całościowe plany są sztywne. O tym czym jest gotowość na zmianę przy innej okazji.
