Dlaczego Sprinty bywają nieudane?

Artykuły eksperckie | 10.10.2018 | Czas czytania: 5 minut

Sercem Scruma jest Sprint. Oznacza to, że wszystkie wydarzenia i artefakty scrumowe mają sprawić, aby praca podczas Sprintu była jak najbardziej wydajna, komfortowa, wartościowa i przejrzysta. Przed rozpoczęciem każdego nowego Sprintu, zespół deweloperski ustala wraz z Właścicielem Produktu zakres prac, zwany Backlogiem Sprintu. Jest to swego rodzaju zobowiązanie, dzięki któremu Product Owner może być pewien, że zespół deweloperski dołoży wszelkich starań, żeby ukończyć zadania, które zadeklarował.

Co w sytuacji, gdy Sprint został ukończony, lecz zadania niezrealizowane?

Każda przyczyna niepowodzenia Sprintu powinna być przeanalizowana oraz podjęte muszą być kroki, żeby podobnej sytuacji uniknąć w przyszłości. Dla odpowiedzialnych i dojrzałych zespołów niedowiezienie Sprintu bywa niekiedy osobistą porażką, ponieważ czują, że nie udało się spełnić obietnicy danej na początku swojej pracy. Nie bez znaczenia jest także aspekt motywacyjny – ukończenie i przedstawienie dobrze wykonanego zadania dodaje wiatru w żagle i mobilizuje do jeszcze lepszej pracy.

Dlaczego zatem Sprinty bywają nieudane?

  1. Źle zaplanowany Backlog Sprintu. Ludzie mają bardzo często tendencję do zbytniego optymizmu lub pesymizmu. Nasze cechy osobowości mają bezpośredni wpływ na pracę, jaką wykonujemy. Powszechnie zdarza się, że przeceniamy swoje możliwości, lub mamy skłonność, w dobrej wierze, do gorliwego dążenia do zadowalania oczekiwania innych. Nie uciekniemy od tego także podczas planowania Sprintu, ale należy pamiętać, że jest to szczególnie ważne, żeby realistycznie spojrzeć na zakres prac, jaki zespół zobowiązuje się wykonać.
  2. Powierzchowna analiza oraz zła estymacja zadań. Kiedy planujemy zadanie do wykonania wierzymy, że wiemy o nim wystarczająco dużo, żeby prawidłowo określić jego złożoność. Co jednak w sytuacji, kiedy nasze założenia są błędne? Rozpoczyna się cykl zdarzeń, który prowadzi do niepowodzenia Sprintu. Zadanie okazuje się bardziej złożone, niż przypuszczaliśmy; poświęcamy więcej czasu na dokładną analizę i dodatkową pracę, w konsekwencji „Sprint jest za krótki”, żeby ukończyć, przetestować i zaprezentować określoną funkcjonalność.
  3. Zmiana składu osobowego zespołu. Jak pisałem w moim poprzednim artykule, celem pracy Scrum Mastera jest stworzenie samodzielnego zespołu. Dojrzałe i najbardziej samodzielne zespoły to oczywiście te, które znają się wzajemnie i wiedzą o swoich mocnych i słabych stronach. Każda zmiana w zespole powoduje niepewność oraz utratę płynności pracy, która bezpośrednio wpływa na velocity zespołu, czyli prędkości, z jaką przetwarzany jest Backlog Sprintu.
  4. Źle oszacowane velocity. Okazuje się, że to pojęcie nie zawsze znaczy to samo. Rozważmy hipotetyczną sytuację: velocity zespołu oscyluje w granicy 70 Story Pointów, co oznacza, że w ostatnich 4 Sprintach ukończono zadania, których suma +/- wynosiła właśnie 70 SP. Czy to oznacza, że kolejny Sprint także możemy zaplanować na to 70 SP? Intuicja podpowiada, że tak. Doświadczenie – to zależy.

Podczas pracy z zespołami zauważyłem, że nawet jeśli suma SP jest jednakowa, to praca nad większą liczbą mniejszych zadań idzie szybciej niż nad mniejszą liczbą dużych. Oznacza to, że jest większe prawdopodobieństwo skutecznego ukończenia Sprintu, jeśli zadania w Backlogu rozdzielone są na więcej mniejszych zadań, o mniejszej wartości SP. Jest to jeden z powodów dla których podział (split) dużych zadań na kilka mniejszych jest czynnością niezwykle pomocną podczas planowania oraz realizacji Sprintu. Przy mniejszych zadaniach zmniejsza się niepewność podczas prac deweloperskich i zwiększa szybkość testowania.

Chcesz zbudować zespół posiadający doświadczonego Scrum Mastera?

 

Czy nieudany Sprint może być wartością dodaną?

Wbrew pozorom tak! Scrum opiera się na empiryzmie, zatem każda porażka powinna być lekcją dla Zespołu Scrumowego, z której wyciąga się wnioski na przyszłość. Temu zadaniu służy oczywiście Retrospektywa czyli spotkanie, na którym analizuje się czynniki sprzyjające oraz przeszkadzające w pracy. Warto zwrócić także uwagę, że niekiedy zespoły świadomie chcą podjąć się zadań na granicy możliwości, żeby po prostu sprawdzić, czy są w stanie je wykonać.

Pamiętajmy, że zdarza się, że nieudany Sprint wniósł ostatecznie większą wartość biznesową dla interesariuszy niż udany, który został po prostu zaplanowany z większą rezerwą. W takiej sytuacji należy zweryfikować, jakie są czynniki, które wpływają na zespół, że decyduje się na bezpieczny, a nie realny Backlog Sprintu?

Wyzwania przed Scrum Masterem

Początkujących Scrum Masterów zachęcam, żeby wydrukowali i przykleili nad biurkiem kartkę z napisem „Sercem Scruma jest Sprint”. Pozornie oczywiste zdanie pozwoli nam skupić się na tym, co jest najbardziej istotne w naszej pracy – na wspomaganiu procesu w taki sposób, żeby Sprinty były produktywne. Wszystko inne jest tylko pomocą, a nie celem samym w sobie.

Przeczytaj również: Agile w digitalizacji przemysłu oraz Agile i Scrum w dziale sprzedaży.

Autorem wpisu jest

Łukasz Tudzierz, JCommerce

Scrum Master

Scrum Master w JCommerce, realizuje projekt dla niemieckiego klienta wspierającego instytucje i organizacje w cyfrowej transfromacji. Wierzy w empiryzm i iterację. Uczy Zespoły Scrumowe samodzielności i odpowiedzialności. Po godzinach śląski felietonista, taternik i wspinacz.

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami