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 zespół zostawia sobie przestrzeń na rzeczy nieprzewidziane?

Czy planowanie zespołu jest racjonalne i pozostawia bufor na coś niespodziewanego, co może zdarzyć się w czasie sprintu? Wszak w domenie niestabilnej złożoności na pewno w trakcie prac ujawni się coś, o czym nie było wiadomo w czasie planowania. Lub wydarzy się coś, co wymagać będzie zmiany planów w trakcie sprintu.

Dlatego złym pomysłem jest planowanie „pod korek”. To, jak duży bufor powinno się zostawić, powinno wynikać z historii wcześniejszych sprintów. Z obserwacji różnych zespołów wynika, że zazwyczaj pozostawiają one bufor rzędu 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 zespół dokonuje niezbędnych zmian planów w trakcie sprintu?

Czy w czasie sprintu dochodzi do realnego sprawdzenia i adaptowania planów działania w oparciu o to, co ujawnia się w kolejnych dniach? Inaczej mówiąc, czy Daily Scrum skutkuje dostosowaniem planów i działań do bieżącej sytuacji?

Jeśli zamiast tego zespół do końca postępuje według początkowych planów, ignorując potrzebę zmian, bardzo późno reagował będzie na nieprzewidziane zdarzenia i problemy ujawnione już w trakcie sprintu. Wtedy może braknąć czasu na poradzenie sobie z nimi, zwłaszcza gdy ujawnione nowe tematy podjęte zostaną zbyt późno.

3. Czy w zespole istnieje jakakolwiek wspólnota pracy?

Skoro już mowa o Daily Scrumie: czy zespół pracuje nad czymkolwiek wspólnie? Przy czym nie chodzi mi o taki model działania, w którym praca nad wymaganiami jest przenoszona od osoby do osoby, w zależności od potrzebnych kompetencji. Chodzi o dążenie zespołu do jak najszybszego zrealizowania rozpoczętych prac z wykorzystaniem wszystkich posiadanych umiejętności.

Jeśli każdy z developerów skupia się nad „swoimi” zadaniami, realizując je w sposób ustalony w czasie planowania sprintu, wszystkie niezaplanowane kwestie 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 mogą zignorować (przeoczyć) oczywiste sygnały zbliżającej się katastrofy.

Im mniej pracy zespołowej, tym trudniej też zauważyć, że się „utonęło” w jakiejś pracy bez szans na jej szybkie ukończenie. Każdy robi „swoje” i bardzo późno okazuje się, że nie uda się tego poskładać w jedną całość, czyli działający produkt.

4. Czy w zespole nie ma silosów kompetencyjnych?

Czy nie jest tak, że konkretne osoby (często z góry wiadomo które) zawsze wykonują konkretne rodzaje prac? I że zespół tak „optymalizuje” swoją pracę, 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 powoduje, że sprint zamienia się w mini-kaskadę, w której dopiero na końcu sprintu składa się produkt w całość i panicznie testuje w nadziei, że nie ujawnią się błędy. Marnowana jest też 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 itd.), prawie na pewno nie zostanie zrealizowana, zanim osoba o „odpowiednich kompetencjach” nie ukończy innych, wcześniej planowanych działań. Lub będzie ona zmuszona do przełączania między dwoma kontekstami, co skutecznie spowolni jej działania. W efekcie pilna praca może zostać odłożona na potem – i zrealizowana zbyt późno, by możliwe jeszcze było osiągnięcie celu sprintu.

Zespół w 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 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 zespół ogranicza ilość wymagań realizowanych jednocześnie?

Czy zespół realizuje minimalną ilość wymagań na raz tak, by jak najszybciej je skończyć, zanim rozpocznie pracę nad kolejnymi? Czy też raczej jest to „szeroka tyraliera”, w wyniku której dopiero pod koniec sprintu wszystko zaczyna być składane w całość – niekoniecznie z powodzeniem?

Prawo Little’a określa zależność średniego czasu realizacji prac od średniej ilości prac wykonywanych jednocześnie. Tą zależnością jest średnia przepustowość, a więc realne możliwości dostarczania przez zespół developerski czegoś, co działa. Tę średnią przepustowość można oczywiście powoli zmienić (kluczowe słowo to: powoli), ale w krótkim przedziale czasowym jest stała.

A to oznacza, że robiąc wiele rzeczy na raz, zespół z definicji będzie je robił długo. Być może przez cały sprint. Być może na tyle długo, że ewentualne problemy ze zintegrowaniem wszystkich realizowanych wymagań w całość, w ramach jednego produktu, okażą się zbyt duże i braknie czasu, by sobie z nimi poradzić.

6. Czy zespół regularnie podnosi poziom swoich praktyk?

Czy zespół doskonali sposób, w jaki buduje produkt? Uczy się nowych praktyk, dokonuje zmian sposobu pracy w każdym sprincie tak, by ujawnione niedociągnięcia szybko eliminować? Jeśli nie, na poprawę nie ma co liczyć.

Wiele zespołów decyduje się jedynie raz na wiele miesięcy dokonać jakiejś gruntownej zmiany, która „natychmiast” daje dużą poprawę. W czasie od jednego takiego zrywu do kolejnego usprawnienia nie są w ogóle realizowane. W efekcie bardzo szybko nawarstwiają się problemy, które powodują, że ze sprintu na sprint pracuje się coraz trudniej. W efekcie szansa na osiąganie celu sprintu sukcesywnie spada.

Taki model dbania o jakość wytwarzanych rozwiązań powoduje, że zespół zatraca umiejętność jednoczesnego budowania produktu i wprowadzania usprawnień. Przełącza się między trybem „produkowania” i „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 zespół rozumie, co wytwarza i po co to robi?

Czy developerzy wiedzą, czym jest produkt, jaki budują? Czy wiedzą, dla kogo wytwarzają poszczególne rozwiązania? Brak tej wiedzy utrudnia skuteczne działanie, 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. A nie da się zainteresować czymś, czego się nie rozumie. Dlatego konieczne jest przedstawienie zespołowi wizji produktu i przyczyn, dla których backlog produktu ma taką a nie inną zawartość i kolejność elementów.

8. Czy zespół dostarcza rozwiązania, czy raczej realizuje zlecenia?

Czy w backlogu produktu są zadania czy wymagania? Inaczej mówiąc: czy developerzy dostają problem biznesowy do rozwiązania i sami decydują, co z nim zrobić, czy też raczej mówi im się jakie rozwiązanie jest potrzebne i oczekuje, że zrobią to jak najszybciej?

To drugie podejście może ograniczać możliwości i chęci zespołu, by korzystać ze wszystkich posiadanych kompetencji i na pewno nie sprzyja dużemu zaangażowaniu. Wysysa to również z zespołu odpowiedzialność za uzyskanie działającego produktu: wszak robią, co im kazano, a jak okaże się, że nie da się zrealizować zleconych zadań, to już trudno…

Innym skutkiem takiego postępowania będzie ogromna szczegółowość wymagań, bo zespół domagał się będzie „konkretów”. Skoro sam nie decyduje, jak rozwiązać problem biznesowy, musi dostać szczegółowy projekt, odpowiedzi na wszystkie pytania, niezbędne dane itd. To konsumuje czas, który mógłby poświęcony zostać na budowanie produktu, bo zespół wraz z Product Ownerem skupiony będzie na niezdrowej formie pielęgnacji backlogu.

9. Czy zespół ma przestrzeń do samoorganizacji?

Czy zespół ma dość swobody, by samodzielnie organizować swoją pracę? Czy też większość rzeczy, jakie robi, jest sterowana przez ograniczenia managementu, wytyczne ekspertów, polecenia kierownictwa itd.?

Sytuacja, w której osoby nie uczestniczące w pracach w sprincie mają znaczący wpływ na sposób pracy zespołu, skutkuje bardzo nieoptymalną organizacją działań. Co więcej, może pozbawiać developerów poczucia wpływu na to, co się dzieje, obniżać zaangażowanie, wyciągać z zespołu odpowiedzialność…

10. Czy celem zespołu na pewno jest zbudowanie działającego produktu?

Czy wszyscy rozumieją, że celem sprintu nie jest „dowieźć za wszelką cenę” to, co podjęte zostało do realizacji, ale uzyskać wartość, o ile jest ona w ogóle możliwa do wytworzenia?

Sprint to hipoteza, że coś da się zrobić i będzie to miało wartość. Ta prognoza zespołu i Product Ownera czasami się nie potwierdza, i nie oznacza to wcale, że sprint zakończył się niepowodzeniem. Odkrycie, że coś jest niemożliwe, pozwala podjąć empiryczną decyzję, co dalej.

Oczywiście nie nawołuję tu do tego, żeby nie przejmować się tym, iż nie udało się nic dostarczyć w sprincie – ale warto zachować zdrowy osąd i nie dążyć do tego by bezwzględnie każdy sprint musiał coś dostarczyć. A już na pewno celem nie powinno być „zagwarantowanie”, że wszystko będzie zrobione.

Bardzo często skupienie na „dowiezieniu” wynika z presji na zespół, by dostarczać jak najwięcej, jak najszybciej, często bez dobrego wyjaśnienia po co. W efekcie zespół zaczyna robić dużo zmian w produkcie, kosztem jakości, 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.

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 tak, by często i regularnie był w stanie budować działający produkt.