Dlaczego tak trudno ustalić Cel Sprintu?

Porządny Agile

Poprawnie skonstruowany Cel Sprintu to wyzwanie dla niejednego zespołu. Widzimy to dosyć często w naszej codziennej pracy. Z czego może wynikać ten problem? Zdradzamy kilkanaście naszych hipotez. Mamy też dla Ciebie kilka rozwiązań, które pomogą poprawnie skonstruować Cel Sprintu.

Porządny Agile · Dlaczego tak trudno ustalić Cel Sprintu?

Cel Sprintu jest zobowiązaniem będącym częścią Backlogu Sprintu. Jest on ustalany przez Zespół Scrumowy podczas planowania Sprintu. Określa, co zespół chce osiągnąć w ramach Sprintu. Dobrze sformułowany Cel daje developerom pewną swobodę w doborze rozwiązania w trakcie Sprintu. Cel Sprintu pozostaje niezmienny przez cały Sprint, co zapewnia zespołowi skupienie, spójność współpracy i stały punkt odniesienia przez cały czas trwania Sprintu.

Spis treści

• Powody problemów w konstruowaniu celu Sprintu
• Jak rozwiązać problemy w zbudowaniu celu Sprintu?
• Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„

Powody problemów w konstruowaniu celu Sprintu

1. Brak zrozumienia czym jest Cel Sprintu

To bardzo podstawowy, ale istotny problem. Obserwujemy, że brak dobrego zrozumienia, dlaczego Cel Sprintu jest obecny w Scrumie, prowadzi do problemów z jego praktycznym wykorzystaniem podczas Sprintu. Cel Sprintu jest narzędziem, które pozwala nam osiągnąć skupienie. Z natłoku różnych tematów, którymi moglibyśmy się zająć w trakcie Sprintu, wybieramy jeden określony kawałek – coś, co chcemy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy biznesowo. Cel Sprintu powinien być dla nas najistotniejszy i pomagać w podejmowaniu codziennych decyzji podczas pracy w Sprincie.

2. Założenie, że Cel dotyczy całego zakresu i wszystkich Developerów

Mamy tutaj do czynienia z nadinterpretacją teorii, która mówi, że cel zapewnia skupienie i pozwala na współpracę. Choć to prawda, przesadne zrozumienie tego może prowadzić do myślenia, że Cel Sprintu musi pokryć 100% elementów wziętych do Sprintu, włącznie z tymi, które są nieco inne niż główne zadanie.

Podobnie problem może dotyczyć developerów. Jeśli zespół składa się z sześciu developerów, pięciu może realizować główne zadanie, ale szósty może zajmować się np. zadaniami utrzymaniowymi. W takich przypadkach zespoły próbują na siłę włączyć wszystkie zadania i wszystkich developerów do Celu Sprintu, co prowadzi do tworzenia celów zbyt ogólnych lub wieloelementowych. Naszym zdaniem jest to antywzorzec.

Odwracając ten problem, Cel Sprintu nie musi pokrywać całego zakresu i nie musi dotyczyć każdego developera w danym momencie. Ważne jest, aby zrozumieć specyfikę danego zespołu i skupić się na głównym celu, który jest najistotniejszy dla Sprintu.

3. Poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne

Wyobraź sobie sytuację, w której zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu wchodzą w jego zakres. Nagle ktoś mówi, że naprawa jakiegoś błędu jest również ważna, ale skoro nie ma jej w Celu Sprintu, to zespół nie będzie się na niej skupiać. Cel Sprintu ma wskazywać drogę, być drogowskazem, latarnią morską dla zespołu, ale to nie oznacza, że rzeczy spoza Celu Sprintu są kompletnie nieważne i można je zignorować.

W praktyce może się zdarzyć, że rzeczy poza Celem Sprintu, gdy w trakcie Sprintu odkryje się problemy, mogą stać się kandydatami do renegocjacji. Jednak na etapie planowania Sprintu nie powinniśmy od razu zakładać, że czegoś nie zrobimy tylko dlatego, że nie jest w Celu Sprintu.

4. Realizacja Celów jest rozliczana przez management

Realizacja Celu Sprintu jest rozliczana przez management, co może być źródłem problemów. Dlaczego? Ponieważ zespoły zaczynają podejmować niewskazane negocjacje.

Jeśli zespoły są ściśle monitorowane i kontrolowane, ustalają taki Cel Sprintu, aby jak najszybciej go zaliczyć. Niestety, widzieliśmy na własne oczy, że jako Cel Sprintu formułowane jest coś, co można zrealizować w 1-2 dni. Oczywiście, zespół wykonuje wiele innych zadań, ale ma potencjał, aby wyznaczyć bardziej ambitny Cel Sprintu. Jednak zespoły są zachęcane przez management do tego, aby zawsze mieć wszystko „na zielono”. W rezultacie cel jest albo banalny, albo tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że Cel Sprintu nie spełnia swojej podstawowej funkcji, a staje się narzędziem do unikania problemów i zapewnienia, że wszystko wygląda dobrze w raportach.

Takie podejście jest zrozumiałe w korporacyjnym świecie, ale może być bardzo frustrujące dla Product Ownerów, którzy chcieliby stawiać bardziej ambitne cele. Ponadto, koncepcja pracy eksperymentalnej i przyrostowej całkowicie się rozmywa, ponieważ zespół skupia się na bezpieczeństwie i zaliczaniu celów, zamiast na faktycznym rozwoju i dostarczaniu wartości.

5. Brak pracy przyrostowej

Dlaczego tak trudno ustawić sensowny Cel Sprintu? Jednym z głównych powodów jest brak pracy przyrostowej. Mówimy o sytuacji, w której zespół realizuje z góry założony zakres konkretnego produktu lub projektu, ale brakuje chęci poukładania tego w sensowne przyrosty. Na pierwszy rzut oka, patrząc na Backlog Produktu, może się wydawać, że jest on sensownie przemyślany i można z niego wyłonić Cele Sprintu. Jednak w rzeczywistości jest to po prostu lista rzeczy do zrobienia, a podczas planowania Sprintu trudno wyłapać z tej listy coś, co można zamknąć w sensowny Cel Sprintu.

Problem tkwi w braku przyrostowości. Wiele zespołów ma trudności z formułowaniem Celów Sprintu, ponieważ Sprinty nie przynoszą przyrostów. Jest to wynik tego, że zadania są tak poukładane, że trzeba zrobić wszystko. Wybierane są nie te kombinacje realizacji zakresu, które dają przyrostowość, ale te, które z jakiegoś powodu ładnie pasują do planu. Problem polega na tym, że brakuje przyrostowości, a koncepcja robienia pełnych kroków i osiągania sensownych celów zanika.

6. Wiele równoległych wątków realizowanych w Sprincie

To klasyczny problem, który najczęściej prowadzi do antywzorca, który nazywamy „wielocelem”. Oznacza to, że zespół ma w planie zrealizować funkcjonalność X, poprawić wskaźnik KPI ABC o Y oraz rozwiązać 10 błędów. Taki „wielocel” najczęściej można rozpoznać po wielu połącznikach w formule celu, gdzie wszyscy widzą i wiedzą, że to są dwie, trzy, cztery, a czasem nawet więcej wyraźnie odseparowanych zadań. Są one wzięte do Sprintu, zgodnie z decyzją Product Ownera, być może samodzielnie, a być może pod naciskiem interesariuszy, komitetów lub innych czynników.

Na etapie planowania zespół łatwo odkrywa, że musi złapać wiele wątków. Product Owner nie jest skłonny do zmiany tej sytuacji. Ewentualnym mini rozwiązaniem jest uzgodnienie, że zespół wykonuje wiele różnych rzeczy, ale tylko jedna z nich trafia do Celu Sprintu. Jednak wówczas wracamy do problemów, które wcześniej wspomnieliśmy.

7. Produkt nie jest rozwijany poprzez cele

Jeśli nie wykonuje się odpowiedniej pracy przed planowaniem Sprintu, nie mamy na myśli tylko procesu Refinementu, ale także bardziej wysokopoziomowej analizy, która pozwala spojrzeć na produkt z szerszej perspektywy, to później trudno jest określić Cel Sprintu. Jeżeli nie mamy jasno określonego sensownego Celu Produktu, bardzo trudno jest ustalić konkretne kroki, czyli Cele Sprintu, które będą nas prowadzić do tego Celu Produktu. Jeżeli Cel Produktu jest dla Ciebie interesującym tematem, odsyłamy Cię do odcinka 111 na stronie porzadnyagile.pl/111.

8. Backlog Produktu nie jest uporządkowany

W skrajnych przypadkach dopiero na planowaniu Sprintu ustala się, co właściwie znajduje się w Backlogu. Często zespół dopiero ustala kryteria, dokonuje estymacji i dzieli zadania. Powoduje to, że są ważniejsze sprawy niż rozmowa o Celu Sprintu. Jeśli Backlog Produktu jest nieuporządkowany, prawdopodobnie nie było czasu na rozmowy o Celach Produktu jako całości, kolejnych większych krokach, przyrostach czy pomysłach na rozwój produktu. Najczęściej wynika to z braku wystarczającego czasu na Refinement.

Jednym z pytań, jakie zadalibyśmy zespołowi mającemu problemy z Celami Sprintu, jest: „Jak wygląda wasz Backlog Produktu?” Na ile jest gotowy i jak daleko w przód jest zaplanowany? W dyskusjach, pracach i aktywnościach refinementowych widzimy silną korelację – nieuporządkowany Backlog powoduje trudności z planowaniem i ustalaniem Celu Sprintu.

9. Zespół rozwija wiele produktów albo projektów

Kolejny problem, który uniemożliwia łatwe i skuteczne tworzenie Celu Sprintu, to sytuacja, w której zespół rozwija wiele produktów jednocześnie lub pracuje nad wieloma projektami.

W takiej sytuacji zespół jest traktowany jako zasób, do którego można wrzucać dużą liczbę różnych wątków, streamów czy kontekstów. Zwykle prowadzi to do tego, że pojedyncze osoby lub małe podgrupy (2-3 osoby) obsługują te wątki. Jeśli mamy kilka takich wątków na Sprint, nie jesteśmy w stanie stworzyć Celu Sprintu, który jest wspólny dla całego zespołu. Cel Sprintu powinien angażować większość zespołu, budując poczucie zespołowości i wspólnego dążenia do celu. Kiedy wątków jest wiele, wyklucza to możliwość stworzenia takiego celu, który daje wartość zespołowi i poczucie wspólnego osiągnięcia konkretnego celu. W skrajnym przypadku może to oznaczać, że każdy członek zespołu ma swój własny Cel Sprintu, ponieważ wątków jest tyle, ilu członków zespołu. To kompletnie się nie sprawdza.

10. Zespół nie tworzy kompletnego produktu

Zespół może być skoncentrowany na jednej specjalizacji technologicznej, podczas gdy produkt ma wiele warstw, obsługiwanych przez inne zespoły. Może to być też zespół składający się z wybranych kompetencji, ale niezdolny do stworzenia sensownego produktu jako całość. W takich przypadkach Cele Sprintu są zupełnie nieadekwatne. Możemy na przykład postawić serwis, ale to nie jest ani funkcjonalność, ani cel biznesowy. Jest to, tylko etap w rozwoju. Zespół może czuć, że sensowny cel jest ustalany na poziomie kilku zespołów lub, na przykład w komitecie zarządzania, ale na pewno nie na poziomie tego konkretnego zespołu. Kluczowe jest więc to, jak skonstruowane są zespoły w organizacji. Nie można winić pojedynczego zespołu za brak możliwości określenia Celu Sprintu, jeśli nie tworzą produktu jako całość.

11. Zespół realizuje głównie zadania utrzymaniowe

Chodzi tutaj o drobne zlecenia, rzeczy, które są od siebie bardzo różne, co jest podobne do dwóch poprzednich punktów, o których pisaliśmy. Jednak jest to o tyle specyficzna sytuacja, że spotykamy zespoły, które nazywają siebie bądź są nazywane w organizacji zespołami utrzymaniowymi. Czasem jest to utrzymanie konkretnego produktu, czasem całego obszaru. Kluczowe jest to, że bardzo trudno jest przewidzieć, czym dokładnie taki zespół będzie się zajmował. Większość ich pracy polega na reagowaniu na bieżące potrzeby, zamiast realizowania jakiejś wizji czy konkretnej koncepcji.

Oczekiwanie od takiego zespołu, że wymyśli i wybierze sensowny Cel Sprintu, może być trudne. Wyobraźmy sobie sytuację, w której w ramach utrzymania zmieniana jest konkretna wersja biblioteki, co wymaga pracy na wielu frontach i w różnych miejscach. Wtedy może to być kandydat na Cel Sprintu. Jednak, gdy różne zadania wpadają od różnych interesariuszy z różnych stron organizacji, próba stworzenia wspólnego Celu Sprintu dla takiego zespołu może być nierealistyczna.

Przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jak rozwiązać problemy w zbudowaniu celu Sprintu?

Określiliśmy, jakie mogą być powody, mające wpływ na skonstruowanie Celu Sprintu. To pokazuje, jak myślimy o problemach, kiedy pracujemy z klientami. Teraz wskażemy, co można zrobić, aby poradzić sobie z tymi problemami. Poniżej proponujemy, kilka rozwiązań, które warto rozważyć.

1.Uporządkuj i rozbuduj swoją wiedzę na temat Celu Sprintu

Pierwsze możliwe rozwiązanie to uporządkowanie i rozbudowanie swojej wiedzy na temat Celu Sprintu. Zakładamy, że sposób wprowadzenia, tłumaczenia i pokazywania Celu Sprintu na przykładach wpływa na jego późniejsze stosowanie. Kierujemy to głównie do Scrum Masterów, Agile Coachów i Product Ownerów. Mogą istnieć powody, na które nie masz wpływu, takie jak konstrukcja zespołów czy ogólnofirmowe procesy, ale w każdym zespole można dużo osiągnąć, jeśli wiedza o Celu Sprintu jest uporządkowana i dobrze zrozumiana. Im lepiej rozumiesz to narzędzie, tym skuteczniej wprowadzisz je do swojego zespołu. Szukaj informacji, sprawdzaj różne źródła, nie bój się zadawania trudnych pytań trenerom i mentorom. Jeśli coś nie działa, spróbuj inaczej. Jako Scrum Master, Product Owner czy Agile Coach masz wpływ na to, jak przekazujesz i wprowadzasz Cel Sprintu jako narzędzie.

2. Wyrównaj wiedzę na temat Celu Sprintu w zespole

W przeciwieństwie do pierwszej porady zachęcamy, aby zrozumienie Celu Sprintu nie było tylko w głowie jednej osoby. Ważne jest, aby cały zespół uczestniczył w szkoleniach lub warsztatach, które mają na celu wyrównanie poziomu wiedzy. Istotne jest, aby skupić się na pracy na realnych przykładach Celów Sprintu. Można wziąć przykładowy zakres Backlogu Produktu lub wcześniejsze Cele Sprintu i zastanowić się, jaki mały krok może sprawić, że te Cele będą lepsze. Nawet jeśli wiemy, że nie osiągniemy od razu idealnego Celu Sprintu, warto dążyć do stopniowego ulepszania i zbliżania się do sensownego Celu Sprintu.

3. Eksperymentuj z formułami Celu Sprintu

Zespół często ma problem z rozpoczęciem pracy nad celami lub z ich rewizją. Zachęcamy do wytrwałości i cierpliwości w realizacji celów przez kilka kolejnych Sprintów. Ważne jest, aby regularnie wprowadzać Cel Sprintu, poświęcać na to czas i zatrzymywać się jako cały zespół, zamiast unikać trudności i wybierać bezpieczne, ale niedocelowe rozwiązania. Eksperymentuj z różnymi formułami i sposobami dochodzenia do Celu Sprintu. W niektórych zespołach Product Owner proponuje szkic Celu Sprintu, w innych developerzy sami próbują go wyłapać, słysząc, co jest do zrobienia. Istnieje również kilka wariantów pośrednich. Nie ma jednego dobrego sposobu – spróbuj różnych podejść i zobacz, który najlepiej pasuje do twojego zespołu, aby wprowadzić to do swojej rutyny.

4. Usprawnij proces Refinementu Backlogu Produktu

Zakładamy, że w twoim zespole już istnieje jakiś proces Refinementu, ale warto zainwestować dodatkowy czas w te spotkania. Może to polegać na spojrzeniu na Backlog Produktu z szerszej perspektywy, a nie tylko na niskopoziomowe elementy Backlogu. Oprócz dzielenia, uszczegóławiania czy szacowania zadań, warto zastanowić się nad poprawą efektywności procesu, co może dać więcej czasu na refleksję nad długoterminowym układem Backlogu Produktu. Jeśli interesuje Cię odpowiedzialność Zespołu Scrumowego podczas Refinementu, czyli rola Product Ownera, Scrum Mastera i developerów, zapraszamy do odcinka na stronie porzadnyagile.pl/89

5. Rozpocznij dyskusję o konfiguracji zespołów

Trzy ostatnie problemy były ściśle związane z konstrukcją zespołów: za dużo produktów, za dużo wątków lub brak konkretnego produktu i prace utrzymaniowe. To może sugerować, że dzisiejsza konstrukcja zespołów, ich granice, skład osobowy lub kompetencyjny nie są doskonałe, co utrudnia realizację Celów Sprintu. Nie chodzi tylko o same Cele Sprintu, ale o to, że trudności z ich realizacją mogą być sygnałem, że warto zaangażować management i porozmawiać o konfiguracji zespołów.

Ważne jest, aby zespoły były zgodne z koncepcją zespołów samodzielnych, autonomicznych, produktowych, realizujących pracę przyrostowo. Te składowe są często w zasięgu działania managementu, i to na wyższym poziomie niż pierwszy stopień menedżerski. Wymaga to zwołania sojuszu Product Ownerów, Scrum Masterów, sąsiadujących zespołów i kilku menedżerów mających podobny problem. Ktoś musi tę rozmowę rozpocząć i zainspirować innych myślą, że można to zrobić inaczej. Takie rozmowy potrafią trwać miesiącami, ale każdy dzień jest dobry, aby je zacząć i porozmawiać o możliwości zrekonfigurowania zespołów przy najbliższej okazji.

Czasem po prostu nie da się zmienić układu zespołów z różnych powodów, często politycznych, i dostajemy komunikat, że musi pozostać tak, jak jest. W takiej konfiguracji może być bardzo ciężko ustawić dobre Cele Sprintu. Jeśli nie można ustawić sensownych Celów Sprintu, może to być sygnał, że Scrum nie jest odpowiednim frameworkiem dla twojej sytuacji, zespołu lub aktualnej konfiguracji. Warto potraktować to jako sygnał ostrzegawczy. Może lepiej odpuścić Cele Sprintu, zamiast konstruować je tylko po to, by odhaczyć ich istnienie. Warto zastanowić się, czy Scrum jest właściwym narzędziem dla Twojego zespołu. Jeśli chcesz pogłębić tę myśl, odsyłamy do odcinka „Kiedy Scrum nie jest odpowiedzią” na porzadnyagile.pl/68

Podsumowując, jakie mogą być powody problemu w konstruowaniu Celu Sprintu?

• Brak zrozumienia, czym jest Cel Sprintu
• Założenie, że Cel dotyczy całego zakresu i wszystkich developerów.
• Poczucie, że jeśli coś nie jest w Celu Sprintu, nie jest ważne.
• Realizacja celów rozliczana przez management.
• Brak pracy przyrostowej.
• Wiele równoległych wątków realizowanych w Sprincie.
• Produkt nie jest rozwijany poprzez cele.
• Backlog Produktu nie jest uporządkowany.
• Zespół rozwija wiele produktów albo projektów.
• Zespół nie tworzy kompletnego produktu.
• Zespół realizuje głównie zadania utrzymaniowe.

Przygotowujemy kolejny webinar, tym razem o tym, jak skutecznie pracować z Celem Sprintu. Wiemy z doświadczenia, że temat jest istotny i trudny dla wielu osób. Sami mamy poczucie, że w dostępnych materiałach jest on mało pokryty. Jeśli jest to ważny temat dla Ciebie, zostaw swój e-mail na stronie webinaru i bądź jedną z pierwszych osób, które dowiedzą się, że webinar jest już dostępny. Stronę webinaru i formularz do zostawienia maila znajdziesz pod adresem porzadnyagile.pl/cs.

Oczywiście ten e-mail wykorzystamy tylko do poinformowania Cię, że webinar jest już gotowy. Notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/125.

Dodatkowe materiały

• Cel Sprintu
• Cel Produktu
• Kiedy Scrum nie jest odpowiedzią?

Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„

Kuba: Tematem tego odcinka jest, dlaczego tak trudno ustalić Cel Sprintu. Podczas warsztatów z zespołami, podczas pracy faktycznej, codziennej, coachingowej z wybranymi Zespołami Scrumowymi, obserwujemy, że poprawne wykorzystanie Celu Sprintu przysparza kłopotów, jest jakimś wyzwaniem. Skonstruowanie poprawnego Celu Sprintu, albo przychodzi z dużą trudnością, albo jest pomijane, czy też występuje kilka różnych od siebie sposobów na to, żeby wypełnić Cel Sprintu, ale tak naprawdę nie osiągnąć tego, o co chodzi z tym konkretnym zobowiązaniem. I postanowiliśmy nagrać na ten temat odcinek, ale odcinek będzie silnie skupiony głównie na powodach, dlaczego jest to problem, czy wyzwanie. Powody mogą być bardzo różne od siebie. Tutaj zebraliśmy kilka różnych kategorii i kilka różnych powodów. Opowiemy o tym, dlaczego ciężko jest ustalić Cel Sprintu i z czego to może wynikać.

Jacek: Spis treści dzisiejszego odcinka jest następujący. Przypomnimy, czym jest Cel Sprintu. Wylistujemy powody problemów w konstruowaniu Celu Sprintu i przytoczymy możliwe rozwiązania na problem ustalania Celu Sprintu.

Kuba: To przechodząc do pierwszego rozdziału, krótkie przypomnienie, czym jest Cel Sprintu. Cel Sprintu jest zobowiązaniem wchodzącym w skład Backlogu Sprintu. Cel Sprintu jest ustalany przez Zespół Scrumowy na planowaniu Sprintu. No i Cel Sprintu wskazuje, co jest jakimś takim celem, zobowiązaniem, dążeniem do tego, co jest do osiągnięcia w ramach Sprintu. Często ten Cel Sprintu jest jakąś formą powiedzenia, jaki ma mieć kształt przyrost, który uzyskamy w tym Sprincie. Czasami jest to coś bardziej biznesowego, czasami to jest bardziej funkcjonalne, albo takie skupione na jakimś konkretnym kawałku zakresu. No ale dobrze sformułowany Cel Sprintu daje pewną swobodę rozwiązania, doboru rozwiązania w trakcie Sprintu przez deweloperów, bo Cel Sprintu w całym Sprincie jest niezmienny i to on jest taką składową czy stałą, która zapewnia skupienie zespołowi, zapewnia spójność współpracy i powoduje też, że zespół ma się do czego odnieść przez cały czas pracy w trakcie Sprintu.

Jacek: Więcej informacji o tym, czym jest Cel Sprintu pokryliśmy już w odcinku numer 7. Jeżeli jesteś zainteresowany, bądź zainteresowana, żeby ten odcinek sobie przypomnieć albo poznać, to zapraszamy cię na porzadnyagile.pl/7

Kuba: Natomiast w tym odcinku chcemy się skupić na tym, z czego dokładnie może wynikać problem w konstruowaniu Celu Sprintu i to tu się skupimy, tutaj ten wątek poszerzymy. Powodów wyliczymy jedenaście, więc tutaj zachęcamy do wytrwałości razem z nami. Ale po kolei, jakie mogą być powody, problemów w konstruowaniu Celu Sprintu?

Jacek: Pierwszym powodem jest brak zrozumienia, czym jest Cel Sprintu. Jest to taki bardzo podstawowy powód. Jednakże obserwujemy z Kubą, że brak dobrego zrozumienia, po co tak naprawdę Cel Sprintu znajduje się w Scrumie, powoduje dalsze problemy z jego praktycznym wykorzystaniem w trakcie Sprintu. To, co z mojej perspektywy jest istotne, jeśli chodzi o Cel Sprintu, to to, że jest to narzędzie, które pozwala nam osiągnąć skupienie. Czyli z natłoku różnych tematów, którymi potencjalnie moglibyśmy się zająć w trakcie Sprintu, chcemy się umówić na pewien określony kawałek, na coś, co tak naprawdę chcielibyśmy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy to biznesowo, tak jak Kuba przed chwilą opowiadał? I to powinno być dla nas tym, co jest najistotniejsze i powinno to wskazywać nam decyzje czy podpowiadać decyzje, które będziemy na co dzień w trakcie pracy w Sprincie podejmować.

Kuba: Kolejnym powodem problemu ze sformułowaniem Celu Sprintu może być błędne założenie o tym, że cel dotyczy całego zakresu pracy w Sprincie i wszystkich deweloperów. Tutaj jest takiego rodzaju nadinterpretacja tego kawałka teorii, że cel zapewnia skupienie, pozwala na współpracę, to jest wszystko prawda. Natomiast przerysowana interpretacja powoduje takie zatrzymanie się albo takie zblokowanie się, że Cel Sprintu, który jest sformułowany przez dany zespół, musi pokryć 100% elementów wziętych do Sprintu, wszystkie możliwe, włącznie z tymi, które ewidentnie są jednak trochę inne niż ta główna rzecz, którą robimy. No i podobnie problem może dotyczyć deweloperów. Czyli z sześciu deweloperów, z jakich składa się ten Zespół Scrumowy, pięciu będzie faktycznie realizowało to główne coś i tak będzie mocno współpracować, ale ten szósty z jakiś powodów jednak zajmuje się czymś trochę innym, na przykład zadaniami utrzymaniowymi. No i tutaj wtedy zespoły zaczynają dokonywać jakichś fikołków albo jakiegoś takiego mentalnego wysiłku, żeby jednak tego szóstego dewelopera, i to siedemnaste zadanie zupełnie inne, też jeszcze próbować wcisnąć do Celu Sprintu i wtedy te Cele Sprintu stają się jakieś takie albo zbyt ogólne, albo właśnie wieloelementowe, czyli kilka takich wskazówek, które zawarliśmy w tym wspomnianym przez Jacka siódmym odcinku, jako jednak naszym zdaniem antywzorce. Czyli odwracając ten problem, Cel Sprintu, nie musi koniecznie pokrywać całego zakresu i nie musi w danym momencie, w danym Sprincie dotyczyć absolutnie każdego jednego dewelopera, jaki w Sprincie jest, bo może to być pewna specyfika danego zespołu.

Jacek: Trzeci powód problemu w konstruowaniu Celu Sprintu to poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne. To jest trochę podobno do tego, co Kuba mówił przed chwilą, czyli wyobraźmy sobie sytuację, że zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu faktycznie wchodzą w zakres tego, co byśmy nazwali Celem Sprintu. Natomiast nagle odzywa się ktoś, kto mówi, no ale przecież przykładowa naprawa jakiegoś błędu, też jest ważna. No ale skoro nie ma jej w Celu Sprintu, to znaczy, że kompletnie nie będziemy się na tym skupiać. Oczywiście to nie jest prawda. Cel Sprintu ma wskazywać nam pewną drogę, ma być drogowskazem, ma być taką latarnią morską dla zespołu, ale to nie oznacza, że rzeczy, które nie wchodzą w skład Celu Sprintu, że są kompletnie nieważne i że możemy je zignorować.

Kuba: Choć w praktyce może się zdarzyć, że akurat rzeczy poza Celem Sprintu, gdy w środku Sprintu jakieś odkryje się problemy i nie ma znać przedłużenia, to być może to będą kandydatury na rzeczy do renegocjowania, ale w szczególności nie na planowaniu Sprintu rozmawiamy o tym, że w zasadzie od razu mówimy, że tego nie zrobimy, bo nie jest w Celu Sprintu.

Kuba: Ok, to kolejny powód, dla którego może być to wszystko bardzo trudne. Trochę już z innej beczki to to, że realizacja Celu Sprintu jest rozliczana przez management. I dlaczego to jest możliwy powód problemów? Bo zespoły podejmują negocjacje, taką niewskazaną negocjację. Skoro coś jest bardzo rozliczane, coś jest śledzone, coś jest gdzieś tam kontrolowane, to ustalmy taki Cel Sprintu, żeby jak najszybciej zaliczyć. I to mogą być takie historie, też niestety widzieli na własne oczy, że jako Cel Sprintu jest formułowane coś, co w zasadzie w 1-2 dni w Sprincie jest zrobione. Oczywiście zespół robi mnóstwo innych rzeczy. Jest też potencjał w tym zespole na Sprint, taki troszkę bardziej pojemny Cel Sprintu, który jest może też trochę bardziej ambitny. Ale zespół ma zachęty takie no, managerskie do tego, żeby mieć się zawsze na zielono. Więc ten cel będzie albo zupełnie banalny, albo będzie tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że nie spełnia tej swojej podstawowej funkcji frameworkowej, tylko staje się jakimś takim sposobem, żeby nie podpaść czy negocjacją tego, żeby to było wszystko miłe, łatwe i przyjemne. Co oczywiście z jednej strony w korporacyjnym świecie nic mnie nie zdziwi, ale może być bardzo irytujące np. dla Product Ownerów, którzy mieliby ochotę jakieś bardziej ambitne cele postawiać. Czy w ogóle koncepcja takiej pracy eksperymentalnej, przyrostowej, też tutaj się całkowicie rozwala, bo jest jakby podejście byle bezpieczniej, byle zaliczyć, byle nie podpaść, byle dobrze wypaść w jakichś dashboardach czy tabelkach?

Jacek: Piąty kolejny powód, dlaczego tak trudno ustawić sensowny Cel Sprintu, to brak pracy przyrostowej. Mówimy tutaj o sytuacji, kiedy zespół realizuje z góry założony zakres konkretnego produktu czy jakiegoś projektu przy jednoczesnym braku chęci poukładania tego w sensowne przyrosty. Czyli pozornie patrząc na Backlog Produktu możemy mieć poczucie, że to, co widzimy, jest jakoś sensownie przemyślane, być może stoi za ten jakiś cel produktowy czy może wyłaniają się z tego jakieś sensowne Cele Sprintu, ale tak naprawdę jest to po prostu pewna lista rzeczy, które trzeba zrobić i patrząc na ten Backlog, w szczególności w sesji planowania, możemy mieć bardzo dużą trudność, żeby z tej listy, z takiego strumienia tematów do zrobienia wyłapać coś, co moglibyśmy zamknąć w sensowny Cel Sprintu.

Kuba: I tak zaakcentuję mocniej, że nie chodzi nam o to, że być może w niektórych przedsięwzięciach ten zakres jest do przewidzenia, albo w miarę jest on znany i naprawdę nie jest aż tak przekomplikowany, żeby się go nie udało ustalić, tylko jednak ten aspekt przyrostowości. Wiele zespołów ma problem z Celami Sprintu, ponieważ Sprinty nie przynoszą przyrostów i wynika to z tego, że jest to po prostu tak poukładane, że i tak musimy zrobić wszystko, a w dodatku wśród wielu możliwych kombinacji i realizacji pewnego zakresu wybierana jest nie ta, która daje pewną przyrostowość, daje pewną celowość wykonania kolejnych kroków, tylko taka, która z jakiegoś innego powodu ładnie pasuje, na przykład zróbmy cały pierwszy ekran. Chociaż nawet jeśli wtedy to byłoby ujęte jako Cel Sprintu, to może jeszcze nie byłoby tragedii, no ale tej przyrostowości tu nie ma i cała ta koncepcja robienia pełnych kroków i osiągania pewnych sensownych celów zanika.

Kuba: Inny powód, szósty już, to to, że realizowanych jest wiele równoległych wątków w jednym Sprincie. To jest klasyk, który najczęściej prowadzi do takiego antywzorca, który nazywamy z Jackiem wielocelem. Czyli zespół ma w celu zrobić funkcjonalność x, poprawić czynnik KPI, ABC, o Y oraz rozwiązać 10 błędów. Ten wielocel najczęściej można poznać po połącznikach w formule celu, gdzie wszyscy widzą i wiedzą, że to jest dwie, trzy, cztery, czasem nawet więcej wyraźnie odseparowanych rzeczy. Są one do wzięcia do Sprintu, tak podjął decyzję Product Owner. Być może samodzielnie, być może pod naciskiem również jakiegoś otoczenia, czy to interesariuszy, czy jakichś komitetów, czy jakichś jeszcze innych czynników. W to tak głęboko nie chcemy tutaj wnikać, no ale fakt jest w sumie prosty. Na planowaniu zespół w toku ustalania pracy dosyć łatwo odkrywa, że w zasadzie trzeba złapać wiele strok za ogon. Nie za bardzo, Product Owner jest skłonny do tego, żeby to zmienić. Ewentualnym takim mini rozwiązaniem jest powiedzenie sobie, że robimy bardzo dużo różnych rzeczy, ale do Celu Sprintu ląduje tylko jedna z nich, no ale to wtedy już wracamy mniej więcej do problemów, które wcześniej wspomniałem.

Jacek: Kolejny problem. Produkt nie jest rozwijany przez cele. Trochę o celu powiedziałem przed chwilą, mówiąc o Celu Produktu no i generalnie jest tak, że jeśli nie jest wykonana praca taka przed planowaniem Sprintu, nie mam na myśli tutaj tylko procesu Refinementu, ale takiej pracy nawet bardziej wysokopoziomowej, gdzie staramy się spojrzeć na produkt trochę z szerszej perspektywy, z lotu ptaka, no to potem jest problematyczne, żeby powiedzieć, jaki tak naprawdę jest Cel Sprintu. Jeżeli nie mamy ustawianego sensownego Celu Produktu, no to bardzo trudno może nam być ustalać te konkretne kroki, czyli Cele Sprintu, które do tego Celu Produktu będą nas prowadzić. Jeżeli Cel Produktu jest dla Ciebie interesującym tematem, to odsyłamy Cię do odcinka 111 wpisując adres porzadnyagile.pl/111

Kuba: Ósmym powodem problemu z ustaleniem Celu Sprintu może być to, że Backlog Produktu nie jest uporządkowany. Mamy tu na myśli, no może w skrajnym przypadku dosłownie takie coś, że, no dopiero na planowaniu Sprintu de facto ustala się co tam w tym Backlogu w zasadzie właściwie jest, na czym to polega. Często zespół dopiero na planowaniu ustala jakieś kryteria wycenia, robi estymaty, dzieli zadania. To wszystko powoduje, że są ważniejsze rzeczy niż rozmowa o Celu Sprintu. No ale przechodząc nawet czy łącząc się z tym, co chwilę temu Jacek powiedział, no, jeśli Backlog Produktu jest nieuporządkowany, no to nie było prawdopodobnie czasu na rozmowę o Celach Produktu jako całości o jakichś kolejnych większych krokach, przyrostach czy nawet właśnie o pomysłach na to jak rozwijać ten produkt i jakie cele on tutaj mógłby w sobie zawierać. Najczęściej wynika to z niewystarczającego czasu na Refinementy, o czym jeszcze dzisiaj trochę wspomnimy, no ale jednym z pytań jakie bym zadał zespołowi, który ma problem z Celami Sprintu, to jest właśnie rozmowa – A jak wygląda wasz Backlog Produktu? Na jak dużo w przód ten Backlog Produktu jest gotowy albo chociaż rozpoczęty? W takich dyskusjach, pracach, aktywnościach refinementowych różnego typu, no bo tu widzimy bardzo silną korelację, nieuporządkowany Backlog powoduje trudności z planowaniem i m.in. z ustalaniem Celu Sprintu.

Jacek: Kolejny problem, który uniemożliwia łatwe i skuteczne tworzenie Celu Sprintu to sytuacja, w której zespół rozwija wiele produktów jednocześnie bądź jeśli nie mówimy o produktach, to projektów. Jest to sytuacja, w której zespół jest traktowany jako pewien, nazwijmy to, zasób, do którego można wrzucać sporą liczbę różnych wątków, streamów, kontekstów. Co zwykle prowadzi do tego, że pojedyncze osoby lub ewentualnie jakieś bardzo małe podgrupki, 2 może 3-osobowe są w stanie taki jeden z wątków obsłużyć. Jeśli takich wątków mamy kilka na Sprint, to oczywiste jest, że nie jesteśmy w stanie stworzyć Celu Sprintu, który można by powiedzieć, że jest wspólny dla całego zespołu. Taki Cel Sprintu powinien co do zasady jednak angażować większość zespołu tak, żeby rodziło się pewne poczucie zespołowości, poczucie grania do wspólnej bramki. Jeżeli tych wątków jest wiele, no to tak naprawdę wykluczamy sobie możliwość, żeby stworzyć Cel Sprintu dający taką wartość dla zespołu, pod tytułem, jesteśmy tutaj razem chcemy wspólnie osiągnąć jakiś konkretny cel.

Kuba: W skrajnym przypadku to może wręcz oznaczać, że każdy członek zespołu ma swój Cel Sprintu, ponieważ jest tyle wątków w zespole ilu członków. No to zupełnie się nie klei. Przedostatni powód podobny trochę do tego, co Jacek powiedział, to zespół nie tworzy kompletnego produktu. Tutaj ponownie jest temat tego jak poukładany jest zespół, tylko tym razem zespół nie ma wiele produktów jak w Jacka przykładzie, tylko zespół nie ma całego produktu. To może być zespół złożony wyłącznie na przykład w jednej specjalizacji technologicznej, ale produkt ma parę warstw i te parę warstw jest już w innych zespołach, a może to jest zespół złożony wyłącznie z wybranych kompetencji, ale nie jest w stanie jako zespół, jako całość stworzyć sensownego produktu. I tutaj mamy do czynienia wtedy z takim przypadkiem, że te Cele Sprintu albo są takie zupełnie, zupełnie na odwal się. No bo możemy wyłącznie postawić serwis, ale w zasadzie to nie jest ani nawet funkcjonalność. A to na pewno nie jest żaden cel biznesowy, to jest co najwyżej osiągnięcie jakiegoś tam etapu w rozwoju, no albo ten zespół ma poczucie, że to jest jakaś bzdura, że ten taki sensowny cel, to jest coś, co się ustali na poziomie kilku zespołów, a może gdzieś enigmatycznie nawet nie wiadomo gdzie. Może na jakimś komitecie albo właśnie w jakimś zespole zarządzania, ale na pewno nie na poziomie tego konkretnego zespołu. No i myślę, że kluczowy akcent jest tutaj na to jak skonstruowane są w ogóle zespoły w tej organizacji, no ale nie winiłbym tego pojedynczego zespołu o to, że no, jeśli nie stworzą produktu, no to też bardzo trudno oczekiwać, że będą umieli powiedzieć, jaki mają Cel Sprintu.

Jacek: I ostatnia przeszkoda utrudniająca tworzenie sensownych Celów Sprintu to sytuacja, kiedy zespół realizuje głównie zadania utrzymaniowe. Jakieś drobne zlecenia rzeczy, które są od siebie bardzo różne to jest trochę podobna sytuacja do tych dwóch poprzednich punktów, o których mówiliśmy. Jednak jest o tyle specyficzna, że spotykamy zespoły, które nazywają siebie bądź nazywane są w organizacji zespołami utrzymaniowymi. Czasem jest to utrzymanie, które dotyczy konkretnego produktu, czasem utrzymywany jest obszar. Natomiast to, co jest niezmienne w tych zespołach to to, że bardzo często jest trudno przewidzieć, czym tak naprawdę ten zespół będzie się zajmował. Spora część ich pracy to jest reagowanie raczej na to, co się dzieje dookoła, niż realizowanie jakiejś wizji, jakiejś konkretnej koncepcji. Oczekiwanie od takiego zespołu, że wymyśli, wybierze sobie jakieś sensowne Cel Sprintu, może być trudne. Wyobrażam sobie sytuację, że w ramach utrzymania, przykładowo zmieniana jest jakaś konkretna wersja biblioteki i to wymaga pracy na wielu frontach w różnych miejscach. Wtedy być może jest to jakiś kandydat na Cel Sprintu, natomiast w sytuacji, kiedy wpadają różne zadania od różnych interesariuszy z różnych stron organizacji, próba stworzenia wspólnego Celu Sprintu dla tak skonstruowanego zespołu może być mrzonką.

Kuba: Ok, zanim zaczniemy ostatni rozdział, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Dobrze, no to narysowaliśmy z Kubą, to jakie mogą być powody, że Cel Sprintu jest trudno skonstruować. To pokazuje też trochę jak myślimy o problemach, kiedy pracujemy z klientami. Natomiast teraz chcielibyśmy się skupić na tym, co tak naprawdę można byłoby zrobić, żeby z tymi problemami sobie poradzić. Jednocześnie nie mamy tutaj ambicji pokrycia wszystkich możliwych opcji, ponieważ zrobiliśmy to już we wspomnianych na początku odcinka materiałach. Natomiast kilka rozwiązań zaproponujemy pod Twoją rozwagę.

The post Dlaczego tak trudno ustalić Cel Sprintu? first appeared on Porządny Agile.