Blog

Co zrobić, jeśli Zespół nie buduje działających produktów co Sprint? Jak spowodować, żeby Zespół często i regularnie osiągał Cel Sprintu? W jaki sposób zredukować ilość wymagań, które wracają nieukończone do Backlogu Produktu na koniec Sprintu?

Te pytania często pojawiają się na szkoleniach dla Scrum Masterów. Niestety nie ma na nie jednej odpowiedzi, pasującej do każdego Zespołu. Dlatego nie będę nawet próbował takiej odpowiedzi udzielić. Zamiast tego wskażę kilka obszarów, które warto sprawdzić.

1. Czy Developerzy rezerwują czas na rzeczy nieprzewidziane?

Developerzy powinni pozostawić część czasu, jakim dysponują w Sprincie, na poradzenie sobie z problemami, które ujawnią się dopiero po zakończeniu Planowania. W domenie złożonej (np. przy wytwarzaniu oprogramowania) jest niemal pewne, że osiągnięcie Celu Sprintu wymagać będzie wykonania prac wcześniej nieprzewidzianych, a plan działania w mniejszym lub większym stopniu trzeba będzie zmieniać, być może wielokrotnie.

Bardzo złym pomysłem jest planowanie pod korek, czyli alokacja całego dostępnego czasu bez pozostawienia choćby niewielkiej rezerwy. To, jak duży taki bufor bezpieczeństwa powinien być, wynika najczęściej z przebiegu wcześniejszych Sprintów. Z obserwacji różnych Zespołów wynika, że zazwyczaj Developerzy rezerwują na nieplanowe działania około 15-20% czasu, jakim dysponują w Sprincie. To dobra praktyka, zwłaszcza dla niedojrzałych, dopiero startujących Zespołów, które niesione entuzjazmem bywają nadmiernie optymistyczne w ocenie swych możliwości. Zapas czasu na radzenie sobie z nieprzewidywalnością na pewno im się przyda.

2. Czy Developerzy adaptują plan działania w trakcie Sprintu?

Developerzy powinni często i regularnie sprawdzać postęp prac i adekwatność planu działania na pozostałą część Sprintu. A gdy wykryją, że wymaga on zmiany, dokonują jej niezwłocznie. Inaczej mówiąc, odbywać powinny się efektywne Daily Scrumy, które pozwalają Developerom kontrolować sytuację i dostosowywać sposób postępowania do bieżącej sytuacji.

Jeśli zamiast tego Developerzy od początku do końca Sprintu trzymają się początkowych planów, ignorując wszelkie potrzeby zmian albo ociągając się z nimi, wtedy w ogóle nie będą reagować na nieprzewidziane zdarzenia, albo ich reakcja będzie mało efektywna. Może też zabraknąć czasu na poradzenie sobie z jakimś problemem, który nie zostanie zauważony w porę, lub za rozwiązywanie którego Developerzy zabiorą się zbyt opieszale.

3. Czy wśród Developerów istnieje wspólnota pracy?

Skoro już mowa o Daily Scrumie: to zdarzenie ma na celu synchronizację działań Developerów pracujących wspólnie nad osiągnięciem Celu Sprintu. Warto zwrócić uwagę, że nie można uznać za prawdziwą wspólnotę pracy developmentu, w którym realizacja zmian w produkcie jest przerzucana od osoby do osoby w zależności od potrzebnych kompetencji. W takim przypadku może i Zespół jako całość robi wszystko wspólnie, ale w praktyce każdy Developer zajmuje się czym innym.

Prawdziwa wspólnota pracy (czyli praca zespołowa) polega na łączeniu kompetencji wielu osób, by nawet duże i skomplikowane zmiany realizować szybko – najlepiej sekwencyjnie jedna po drugiej. Dzięki temu ograniczone zostaje ryzyko, że wszystko „prawie uda się skończyć”, ale zabraknie czasu i w konsekwencji Sprint zakończy się brakiem wytworzenia czegokolwiek.

Poza tym, jeśli każdy z Developerów skupia się nad „swoimi” zadaniami, realizując je w sposób ustalony w czasie Planowania Sprintu, wszystkie niespodziewane problemy będą sierotami czekającymi aż ktoś w końcu się nimi zajmie. Developerzy, patrząc na listę „swoich” zadań, mogą mieć poczucie, że Sprint idzie świetnie i zignorować (przeoczyć) oczywiste sygnały zbliżającej się katastrofy.

Im mniej pracy zespołowej, tym trudniej zauważyć, że się utonęło w jakiejś pracy bez szans na jej szybkie ukończenie albo że idzie się w złą stronę. Na kolegów z Zespołu nie można za bardzo liczyć, bo każdy z nich skupiony jest na czym innym.

Oczywiście w końcu trzeba poskładać poszczególne kawałki w jedną całość, co następuje zwykle bardzo późno w Sprincie i jest trudne. Czemu? Cóż, Developerzy dobrze rozumieją tylko te zmiany w produkcie, którymi się zajmowali, a całości nie ogarnia nikt. Jednocześnie czasu na integrację i potwierdzenie, że jej efekt spełnia wymogi zawarte w Definicji Ukończenia, jest niewiele. Szansy na ewentualne poprawki właściwie nie ma już wcale.

4. Czy w Zespole istnieją silosy kompetencyjne?

W wielu Zespołach zdarza się, że konkretni Developerzy zawsze wykonują określone rodzaje prac. I że tak „optymalizują” swoje działanie, by każdy robił to, na czym zna się najlepiej, nawet jeśli powoduje to przestoje i generuje zależności.

Ten sposób organizacji pracy zamienia Sprint w minikaskadę, w której dopiero na końcu iteracji składa się produkt w całość i panicznie testuje się go w nadziei, że nie ujawnią się błędy. Marnowana jest okazja, by robić coś wspólnie, więc zanika wspomniana wcześniej wspólnota pracy.

Jest jeszcze jeden negatywny efekt istnienia silosów: jeśli pojawi się nieplanowana praca (problem, błąd do naprawienia itd.), prawie na pewno nie zostanie zrealizowana, zanim osoba o „odpowiednich kompetencjach” nie ukończy tego, czym się aktualnie zajmuje. Alternatywnie, będzie ona zmuszona do przełączania między dwoma tematami, co skutecznie spowolni postęp prac. W efekcie coś, co wymaga pilnej reakcji, bywa odłożone na później, albo jest robione powoli, dramatycznie obniżając szansę na osiągnięcie Celu Sprintu.

Zespół wpada w ten sposób w pułapkę, którą sam na siebie zastawił. Możliwość zauważenia problemu i adekwatnej oceny jego wpływu na przebieg Sprintu jest zawsze ograniczona do kilku osób, mających stosowne kompetencje. A bywa i tak, że Developerzy ignorują problem, który widzą, bo nie należy on do „ich” obszaru odpowiedzialności – czekają, aż zajmie się sprawą „odpowiednia” osoba (ekspert).

Istnienie silosów zazwyczaj wynika z niewiedzy, że można pracować inaczej. Czasami za ich powstaniem kryją się obawy Developerów, że nie poradzą sobie z czymś, w czym nie są ekspertami. Natomiast zdarza się, że silosy powstają, bo otoczenie Zespołu (np. kierownicy liniowi) oczekują od Developerów, że będą się oni zajmować tym, na czym znają się najlepiej. Aby pozbyć się silosów w takim przypadku, nie wystarczy już pracować z samym Zespołem – trzeba zająć się również jego otoczeniem.

5. Czy Developerzy kontrolują WIP?

WIP, czyli ilość pracy w toku (ang. work in progress) to ilość pracy, która realizowana jest jednocześnie. Przy czym nie chodzi tu o pojedyncze czynności Developerów, bo przecież jest oczywiste, że każdy z nich będzie nieustannie czymś zajęty, np. wykonując różne działania w ramach realizacji tego samego elementu Backlogu Produktu. Chodzi o liczbę nośników wartości, które przetwarzane są równocześnie w jakimś procesie.

W przypadku Scruma nośnikami wartości są zazwyczaj elementy Backlogu Produktu, a ich przetwarzanie to po prostu development. Na WIP składać się więc będą wszystkie elementy Backlogu Produktu, których implementacja już się rozpoczęła, a jeszcze nie została zakończona.

Developerzy w niektórych Zespołach świadomie kontrolują WIP, realizując minimalną liczbę zmian w produkcie naraz. Dużo częściej zdarza się jednak, że Developerzy idą szeroką tyralierą, czyli każdy z nich zajmuje się implementacją innego elementu Backlogu Produktu. Ten sposób pracy ma jakoby zwiększać szansę na zrealizowanie wszystkich zaplanowanych w produkcie zmian przed końcem Sprintu, bo im wcześniej rozpoczną się prace, tym więcej czasu będzie na development. Niestety, to nieprawda.

Prawo Little’a powiada, że średni czas wykonania pracy jest wprost proporcjonalny do średniej ilości pracy wykonywanej równocześnie, a odwrotnie proporcjonalny do średniej ilości pracy, jaką udaje się ukończyć w jednostce czasu. Ta ostatnia wartość (nazywana przepustowością) jest stosunkowo stała, bo wynika z możliwości wytwórczych Developerów. W szczególności nie da się jej podnieść w sposób gwałtowny z dnia na dzień.

Z prawa Little’a wprost wynika, że przy względnie stałej średniej przepustowości, im więcej rzeczy realizowanych jest równocześnie (im wyższy jest WIP), tym dłużej będzie trwać praca nad nimi. Jeśli więc Developerzy robią wszystko na raz, rośnie prawdopodobieństwo, że zmiany w produkcie będą trwać długo i skończone zostaną na styk tuż przed Przeglądem Sprintu (o ile w ogóle). Jeśli natomiast kontrolują WIP, utrzymując jego niski poziom (np. realizują zmiany sekwencyjnie jedna po drugiej), implementacja zmian w produkcie trwa krócej, a w najgorszym przypadku zabraknie czasu tylko na to, co robione było pod sam koniec Sprintu.

6. Czy Zespół podnosi poziom używanych praktyk?

Członkowie Zespołu (Developerzy, Product Owner i Scrum Master) powinni nieustannie szukać usprawnień, które udoskonalą sposób ich pracy. Wymaga to uczenia się nowych praktyk i narzędzi, poszerzania kompetencji, eliminowania wspomnianych wcześniej silosów, eksperymentowania ze sposobem organizacji pracy i eliminowania zidentyfikowanych utrudnień. Bez tego na podniesienie efektywności i skuteczności działania Zespołu Scrum nie ma co liczyć.

Wiele Zespołów decyduje jedynie raz na wiele miesięcy o przeprowadzeniu usprawnienia, które ma formę gruntownej zmiany i powinna „natychmiast” dać dużą poprawę. Czasem się to udaje, częściej nie. Oczywiście w czasie od jednego takiego zrywu do kolejnego żadne usprawnienia nie są realizowane. W efekcie bardzo szybko nawarstwiają się problemy, które powodują, że ze Sprintu na Sprint pracuje się coraz trudniej. Szansa na osiąganie Celu Sprintu sukcesywnie spada.

Z czasem Zespół, który w ten sposób podchodzi do dbania o własny rozwój, zatraca umiejętność jednoczesnego budowania produktu i wprowadzania usprawnień. Dotyczy to zwłaszcza Developerów, którzy przełączają się między trybem produkowania rozwiązań i trybem ich naprawiania lub udoskonalania. W praktyce ten drugi tryb sprowadza się do usuwania nagromadzonego długu technicznego, a tuż po zakończeniu tego procesu, w najlepszym razie, Zespół znajduje się w punkcie wyjścia. Mówiąc dosadniej, taki Zespół w ogóle się nie rozwija, a co najwyżej utrzymuje status quo.

7. Czy Developerzy rozumieją, co i po co budują?

Developerzy powinni rozumieć, czym jest produkt, który rozwijają: znać jego wizję, Cel Produktu, z którego wynika aktualny Backlog Produktu, rozumieć potrzeby interesariuszy, jakie są w tym Backlogu opisane poszczególnymi elementami. Powinni też rozumieć, jakie standardy musi produkt spełnić, żeby zapewnić adekwatność Definicji Ukończenia, którą się posługują.

Brak tego wszystkiego utrudnia Developerom skuteczne działanie, a nierzadko je uniemożliwia, bo ciężko dobrze zrobić coś, czego się nie rozumie.

Równie ciężko jest robić dobrze to, czym nie jest się choć trochę zainteresowanym i do czego nie ma się motywacji. A nie da się zainteresować produktem, o którym nic się nie wie. Podobnie jak nie ma co liczyć na zaangażowanie ludzi, jeśli mają poczucie, że jedyną realną wartością w tym, co robią, jest otrzymywana wypłata.

Przedstawienie wizji produktu i szerszego kontekstu, w jakim on powstaje, to praca dla Product Ownera, ale często najpierw zadbać musi o to Scrum Master – uświadamiając Product Ownerowi jego odpowiedzialność. Nie oznacza to oczywiście, że sami Developerzy nie mogą domagać się informacji o produkcie: nie tylko mogą, ale wręcz powinni, jeśli mają poczucie, że produkt jest niezrozumiały lub wydaje się mało sensowny.

8. Czy Developerzy mogą decydować o rozwiązaniach?

Elementami Backlogu Produktu powinny być opisy potrzeb interesariuszy lub problemów, których rozwiązanie przyniesie im korzyści. Inaczej mówiąc, nie powinna to być lista zadań do wykonania przez Developerów, bo to przecież oni powinni proponować rozwiązania i zarządzać samodzielnie sposobem ich implementacji.

Oczywiście czasami zdarzą się wyjątki, ale nie jest korzystne, gdy ktoś niebędący częścią Zespołu Scrum (architekt, ekspert, kierownik itd.) mówi Developerom, jak powinni budować produkt i jakie konkretnie rozwiązania będą właściwe. Takie osoby mogą opracowywać różne rekomendacje lub wręcz definiować standardy i domagać się ich przestrzegania, ale to Developerzy powinni decydować o użyciu tych rekomendacji i sposobie, w jaki zapewnią zgodność developmentu z obowiązującymi standardami.

Ograniczanie decyzyjności Developerów uzależnia Zespół od osób niebiorących udziału w Sprintach, powoduje opóźnienie reakcji na nieprzewidziane zdarzenia, prowadzi do miernego wykorzystania kompetencji, jakie mają Developerzy i obniża poziom ich zaangażowania (nikt nie lubi być jedynie siłą roboczą bez realnego wpływu na wykonywaną pracę). Nieuchronnie wysysa to również z Zespołu Scrum odpowiedzialność za uzyskanie działającego produktu: wszak Developerzy robią, co im kazano, a jeśli okaże się, że nie da się zrealizować zleconych zadań, to już trudno. Niech się tłumaczy ten, kto te zadania definiował…

Innym skutkiem takiego postępowania będzie ogromna szczegółowość elementów Backlogu Produktu, bo Developerzy domagać się będzie konkretów i precyzyjnych opisów. Skoro sami nie decydują, jak rozwiązać problem biznesowy, muszą dostać szczegółowy projekt, odpowiedzi na wszystkie pytania, niezbędne dane itd. To zabiera czas, który mógłby poświęcony zostać na budowanie produktu, ale Developerzy wraz z Product Ownerem zajęci będą pielęgnacją Backlogu Produktu.

Co gorsza, istnieje spore ryzyko, że tak tworzony Backlog Produktu będzie najzwyczajniej marny. O jego zawartości decydować się będzie w znacznej mierze ponad głowami Developerów, którzy będą potem musieli poszczególne elementy jakoś zrealizować. Jeśli w Backlogu umieszczone zostaną głównie zadania (opisy konkretnych działań, jakie mają wykonać Developerzy), dojdzie do niezdrowej sytuacji, w której ktoś, spoza Zespołu Scrum decyduje w znacznym stopniu o tym, jak ma zostać zorganizowany development w tym Zespole.

9. Czy Zespół ma możliwość samozarządzania?

Zespół Scrum musi mieć dość swobody, by samodzielnie organizować swoją pracę. Nie może być tak, że większość pracy, jaką wykonują ludzie w tym Zespole, polega na realizowaniu zadań zdefiniowanych przez kierownictwo, ekspertów lub interesariuszy.

Brak możliwości samozarządzania doprowadzi do wyssania odpowiedzialności z Zespołu. Developerzy nie będą mieli realnego wpływu na to, jak ma przebiegać development ani na finalną jakość produktu, Product Owner zamieni się w „operatora Backlogu Produktu”, a Scrum Master będzie pilnował, by przestrzegany był jakiś narzucony proces. Ze Scrumem nie będzie to miało nic wspólnego poza nazwami i pozorami.

10. Czy celem Zespołu jest budowanie wartościowego produktu?

Celem każdego Sprintu powinno zbudowanie takiego produktu, który przyniesie interesariuszom realną korzyść. Rozwiązanie, które sypie się ze względu na problemy techniczne, jest bezwartościowe niezależnie od tego, jak bardzo jest rozbudowane.

Przy czym w Scrumie Zespół nigdy nie ma stuprocentowej pewności, że prognozowane zmiany w produkcie uda się przed końcem Sprintu zaimplementować. Czasami iteracja kończy się odkryciem, że coś jest niemożliwe do zrealizowania lub bardzo kosztowne i przez to nieopłacalne. To oznacza, że czasami mimo braku „dowiezienia” czegokolwiek, Sprint wciąż może wykreować wartość, jaką jest w tym przypadku empiryczna wiedza, której można użyć do adaptacji planów dalszego rozwoju produktu.

Oczywiście nie nawołuję tu, by nie przejmować się tym, iż nie udało się nic dostarczyć w Sprincie. Zespół powinien w ramach Retrospekcji Sprintu poszukać sposobu na zminimalizowanie ryzyka, że taka sytuacja będzie się powtarzać.

Celem Zespołu zdecydowanie nie powinno nigdy być „dowiezienie wszystkiego za wszelką cenę” kosztem jakości i wartości produktu, jaki w takim procesie powstaje. A niektóre Zespoły potrafią iść w tym szaleństwie jeszcze dalej i za cel stawiają sobie zagwarantowanie, że wszystko zostanie zrobione, po czym próbują wywiązać się z tego absurdalnego zobowiązania nawet za cenę własnego zdrowia. Zdecydowanie nie ma to nic wspólnego z pracą zwinną, która polega na poszukiwaniu i wykorzystywaniu możliwości, a nie na ich nierozsądnym przekraczaniu.

Bardzo często skupienie na „dowożeniu” wynika z presji na Zespół, by dostarczać jak najwięcej, jak najszybciej, często bez dobrego wyjaśnienia po co. W efekcie Zespół zaczyna przedkładać produktywność i tempo prac ponad wartość i jakość dostarczanych rozwiązań, co bardzo szybko owocuje ogromnym długiem technicznym. Od pewnego momentu Developerzy działają pod podwójną presją: nadal trzeba się spieszyć i robić dużo, a czegokolwiek się nie tkną, wybucha im w rękach. Cel Sprintu udaje się wtedy osiągnąć najwyżej co kilka iteracji, o ile w ogóle.

Natomiast bywa i tak, że Sprinty służą realizowaniu wcześniej poczynionych planów, o których Zespół dowiaduje się od kierownictwa lub interesariuszy. Nawet Product Owner nie decyduje o kolejności ani zawartości Backlogu Produktu, tylko dostaje listę rzeczy, jaką ma tam umieścić i zrealizować wraz z Zespołem. Oczywiście towarzyszy temu niemal zawsze presja na „dowożenie” wszystkiego zgodnie z planem, bo w istocie jest to klasyczny projekt, ubrany dla upozorowania zwinności w szatki Scruma.

Łatwo domyślić się, że o żadnym sensownym Celu Sprintu nie ma w takiej sytuacji mowy, bo cóż niby miałoby nim być? Cel zawsze jest jeden: „dowieźć wszystko”. Nie jest to jednak Cel ani wartościowy, ani motywujący do wysiłku (a jeśli choć trochę motywuje, to jest to raczej presja, niż pozytywna zachęta do pracy).

Ze względu na absolutny brak znaczenia, Cel taki nie ułatwi Zespołowi podejmowania decyzji w trakcie Sprintu, a do tego ma tę paskudną cechę, że jest bardzo mało elastyczny: wystarczy, że choć jednej rzeczy nie uda się ukończyć i staje się nieosiągalny. A wiadomo, że wtedy interesariusze i kierownicy mają pretensje do Zespołu, bo jakże to tak można „nie dowieźć” zaplanowanych rzeczy…

Twoja kolej, Scrum Masterze

Wymieniłem kilka obszarów, którym należy się przyjrzeć. Oczywiście, nie jest to kompletna lista, ale stanowi dobry początek. Jeśli zatem jesteś Scrum Masterem, poszukaj odpowiedzi na dziesięć pytań wymienionych powyżej. Wtedy zapewne zobaczysz, jak i w czym warto pomóc Zespołowi, by często i regularnie był w stanie budować działający produkt. Podkreślam: Zespołowi, a nie samym Developerom, bo choć to oni tworzą Przyrosty (stąd też większość pytań związana jest z ich pracą), nad dostarczeniem wartości i osiągnięciem Celu Sprintu pracuje zawsze cały Zespół Scrum.