30 czerwca 2021Scrum

Najczęstsze problemy Zespołów Scrumowych

Nie popełniaj tych błędów! Dowiesz się, z jakimi problemami najczęściej borykają się Zespoły Scrumowe. Dla każdego z nich przygotowaliśmy po trzy pomysły jak ich uniknąć. Zawarte w nagraniu rady wynikają z naszego doświadczenia i zostały przez nas sprawdzone podczas wsparcia wielu zespołów w wielu organizacjach.

Porządny Agile · #066 – Najczęstsze problemy Zespołów Scrumowych

W naszej praktyce pracy konsultanckiej spotykamy się z różnymi problemami Zespołów Scrumowych. Pięć z nich pojawia się najczęściej i na nich się dziś skupimy, podając jednocześnie po 3 rozwiązania dla każdego z osobna.

5 najczęstszych problemów Zespołów Scrumowych

1. Niedotrzymywanie terminów

Obiecywanie terminów, które są potem przekraczane, wiąże się z brakiem planu działania. Stąd też niezwykle ważne jest przygotowanie planu pracy w zespole. W ramach planowania Sprintu ustalić należy nie tylko jego celu, zakres realizowanych prac, ale także określenie sposobu pracy, odpowiedzialności za poszczególne zadania i zależności, zarówno między zadaniami, jak i osobami je realizującymi.

Tworząc taki plan pracy, można od razu zauważyć, które rzeczy są niewykonalne, bo przykładowo jedna osoba jest zbyt przeciążona zadaniami. Łatwiej też określić realistyczne terminy realizacji poszczególnych zadań.

Z planowaniem wiążę się druga wskazówka pomagająca dotrzymać obiecane terminy. Jest nią korzystanie z danych historycznych przy tworzeniu planu. Poprzez dane historyczne mamy na myśli: wcześniejsze rezultaty i wyniki, czy liczba zrealizowanych zadań. Z kolei jeśli zespoły korzystają z systemów estymowania relatywnego, to warto podsumować Story Pointy. Określając ile zadań realnie jesteśmy w stanie zrealizować można skorzystać z techniki Yesterday Weather. Polega ona po prostu na spojrzeniu na ostatni wynik Sprintu i na tej podstawie dobranie liczby elementów, które chcemy zrealizować w nadchodzącym Sprincie.

Zdarza się tak, że terminy nie zostają dotrzymane ponieważ podjęta została praca, która jest nieprzygotowana do realizacji, albo też niewystarczająco znana zespołowi. Stąd też trzecią radą w tym temacie jest inwestycja czasu w Refinement. Całym zespołem warto poświęcić pewnie procent czasu w trybie ciągłym na doskonalenie Backlogu Produktu, szukanie pełnego zrozumienia produktu, budowanie kryteriów akceptacji, rozpisywanie elementów na drobniejsze kawałki.

To właśnie niewystarczająca znajomość produktu często powoduje, że zespół nie potrafi dobrze rozplanować pracy i nie wyrabia się z terminami. Refinement, który wraz z Retrospektywą, są najczęściej pomijane w celu zyskania czasu, mogą prowadzić do błędnego koła ratowania terminów i ciągłego stresu w zespole.

Szczegółowo o technikach Refinementu mówiliśmy w 9 odcinku naszego podcastu, który możesz posłuchać tutaj.

2. Błędy i awarie po wdrożeniu

Drugim najczęstszym problemem, z którym się spotykamy, są sytuacje, w których po wdrożeniu pojawia się mnóstwo błędów i awarii, także takich, które blokują dostęp do produktu.

W tej sytuacji radzimy zdefiniować oraz przestrzegać Definicji Ukończenia.

Pierwszym krokiem w tym celu jest zdefiniowanie dokumentu, czyli miejsca, w którym będą spisane konkretne ustalenie przedyskutowane wewnątrz zespołu. Dzięki temu mamy jasność, że wszyscy zgadzają się na to, na co się umawiamy. Kolejny krok, już trudniejszy, to przestrzeganie Definicji Ukończenia w praktyce. Pomóc w tym może umieszczenie Definicji Ukończenia w widocznym dla wszystkich miejscu, np. jej wydrukowanie i przywieszenie na ścianie lub umieszczenie jej w naszym narzędziu do zarządzania zadaniami. Istotne jest też przestrzeganie dyscypliny i zobowiązanie zespołu do utrzymywania pewnego, powtarzalnego standardu. Zmniejszy to pokusę odpuszczania sobie jakiś drobnych testów czy poprawienia błędów, które się potem piętrzą i prowadzą do awarii.

Drugą radą jest korzystanie z konkretnych, zwinnych praktyk programistycznych, takich bardziej technicznych. Zaliczyć tu możemy np. automatyzowanie pracy, ciągła integracja i refaktoryzacja kodu.

Trzecią radą jest częstsze wdrażanie mniejszych kawałków produktu. Związane jest to, z tym że zwykle jest tak, że im większy kawałek produktu chcemy udostępnić naszym użytkownikom, tym większa jest szansa, że zabraknie nam czasu, żeby przetestować całość przed oddaniem do użycia. Dlatego dobrą praktyką jest dzielenie sobie pracy na małe kawałki. Pozwala to na szybsze stworzenie zmiany i szybsze jej przetestowanie. Szybciej też otrzymamy informację zwrotną i recenzję w przypadku procesów w stylu Code Review.

3. Rozczarowujące efekty pracy

Problem ten rozpatrujemy z perspektywy biznesowej, w której powstał produkt i nie przekłada się to na wyniki biznesowe, ani na zadowolenie użytkowników.

Pierwszym rozwiązaniem jest zapewnienie kontekstu biznesowego w zespole. Niezwykle istotne jest to, aby zespół rozumiał produkt, znał jego kontekst, rozumiał wybraną strategię marketingową czy biznesową. Stąd też interesarusze, zwłaszcza Product Owner, powinni jasno przekazać wizję produktu, konkretne potrzeby grupy docelowej, charakterystykę klienta oraz oczekiwania organizacji względem produktu.

Uzupełnieniem tego kontekstu biznesowego jest zmniejszenie odległości zespołu od użytkownika końcowego. Mamy tu na myśli testy z użytkownikami już na wczesnych etapach tworzenia produktu, tak aby poznać ich spostrzeżenia, problemy, na jakie natrafiają, czego jeszcze oczekują.

Trzecią radą jest robienie małych eksperymentów i korzystanie z wniosków, które na ich podstawie wyciągnęliśmy, a także częsty kontakt z klientem. Rozczarowujące efekty mogą być właśnie wynikiem tego, że cały projekt czy wdrożenie traktowany jest jak coś wielkiego, bez etapów pośrednich, małych kroków, częstszych testów. Porządny Scrum to taki, gdzie najrzadziej raz na Sprint, a może nawet jeszcze częściej, dajemy przyrost, pokazujemy jakieś efekty pracy zespołu. I ten najmocniej rozumiany przyrost trafia do klienta lub użytkownika końcowego. Wówczas otrzymujemy feedback. Może on być pesymistyczny, gdzie klient na podstawie prototypu lub mikro wersji produktu stwierdza, że nie tego oczekuje, że nic mu on nie daje. Wówczas możemy szybko skorygować obrany kurs lub naprawić to, co do tej pory przyszykowaliśmy. Jednak feedback może być też bardziej optymistyczny, gdzie klient jest zadowolony z efektów pierwszych prac i tego właśnie oczekiwał. Wówczas należy bazować na tych szczególnie dobrych elementach i pogłębiać sukces w ten sam sposób.

Przy okazji zachęcamy do posłuchania 31 odcinka naszego podcastu, w którym rozmawiamy o kwestiach związanych z zaangażowaniem zespołu w pracę w celu uzyskania lepszych rezultatów. Odcinek znajdziesz w swojej aplikacji do słuchania podcastów lub na stronie porządnyagile.pl/31.

4. Udawanie, że nie ma problemu

Sytuacja, w której udajemy, że nie widzimy problemu, który się pojawił, jest również często przez nas obserwowania.

Pierwsza rada, to przede wszystkim podczas Retrospektywy Sprintu pokazywać słonia w pokoju. Czym jest ten słoń w pokoju? To jest właśnie ten temat, o którym nie chcemy opowiadać, ale podobnie jak słonia w pokoju, trudno go nie zobaczyć, oddziałuje on na nas. Potrzeba tu pewnej odwagi, aby poruszyć ten temat, zwłaszcza wiedząc, że dyskusja będzie trudna, a nawet nieprzyjemna. Może się też tak zdarzyć, że ów “słoń” zajmie cały czas przeznaczony na Retrospektywę Sprintu lub jeszcze kolejne dedykowane temu tematowi spotkanie. Takim słoniem w pokoju mogą być problemy, które poruszamy właśnie w tym odcinku.

Kolejną poradą kierujemy zwłaszcza do liderów zespołów. Jeśli widzicie problem oraz to, że inni nie chcę go przedyskutować, to sprawdźcie, czy środowisko pracy nie jest demotywujące. Być może są jakieś elementy, które negatywnie wpływają na zaangażowanie zespołu. Mogą to być konkretne procesy, zachowania menedżerów organizacji, toksyczne osoby lub niezrozumiałe zmiany. To wszystko może sprawić, że zespół nie będzie chciał utrudniać sobie życia rozmowami o usprawnieniach lub nie będzie widzieć sensu w ich wdrażaniu. Bardzo wierzymy w to, że jeśli pracujemy w przyjaznym, wspierającym środowisku to rodzi się poczucie zespołowości, a świadomość realizacji wspólnego celu ułatwia rozmowy na trudne tematy.

Ostatnią poradą w tym punkcie jest korzystanie z technik prowadzenia trudnych rozmów. Bo nie jest sztuką rozpoczęcie tematu i potem doprowadzenie do konfliktu. Sztuką jest takie poprowadzenie rozmowy, podczas której zespół skupi się na rozwiązaniu problemu, a nie na szukaniu winnego. Z naszej strony proponujemy wykorzystanie techniki FUKO, w której w sposób ustrukturyzowany dajemy informację zwrotną. Jest to generalnie filozofia prowadzenia dialogu, który nie jest ofensywny, czyli NVC.

5. Potrzeba robienia więcej niż obecnie

Taka potrzeba i presja może wychodzić nie tylko od zarządzających organizacją czy Product Ownerów, ale także sami członkowie zespołu mogą wytwarzać między sobą napięcie i przymus szybszej realizacji zadań.

Pierwszą poradą jest odwrócenie perspektywy i zamiast patrzenia na ilość wykonanej pracy (liczbę ficzerów, Story Pintów, tasków), to spojrzenie na wartość dodaną płynącą z tej pracy. Nie ma znaczenia ile pracy wykonasz jeśli ta praca nie wnosi żadnej wartości. Dlatego powinniśmy znaleźć mierniki, które pozwolą nam określić, co jest wartością w tworzonym produkcie. To ułatwi też lepiej selekcjonować zadania, które należy wykonać w kolejnym Sprincie.

Druga porada to poszukiwanie i likwidowanie marnotrawstwa. Przykładem może być oczekiwanie, czyli sytuacja w której stworzymy wiele jakichś zmian backendowych, a one będą leżeć i czekać, aż w kolejnym Sprincie np. zostanie doprodukowany frontend do tego. Innym przykładem jest oczekiwanie na testy stworzonej funkcjonalności lub na Code Review. Tutaj warto zastanowić się jak te momenty oczekiwania zredukować, a także jakie elementy możemy usunąć z procesu.

Ostatnią poradą jest skupienie się całego zespołu na celu Sprintu. Zdarza się często tak, że pomimo tego, że do zrobienia jest wiele więcej, niż zespół jest w stanie zrobić, to, ogrom energii i czasu poszczególnych osób w zespole przekierowywane jest na rzeczy, które nie są istotne, które nie są celem danego Sprintu, które są jakąś pracą taką poboczną. Dodatkowo może dojść do sytuacji, w której zespół rozdziela swoją pracę na indywidualne kawałki. Różne osoby realizują jakieś małe cząsteczki w oderwaniu od reszty, niekoniecznie intensyfikują swoją pracę, niekoniecznie sobie wzajemnie pomagając. To wszystko sprawia, że po pierwsze nie tworzymy zespołu, po drugie nie realizujemy tego, co jest naprawdę najważniejsze. Stąd też zobowiązanie do skupienia się na celu Sprintu, wymienianie się wiedzą, wspólne nakręcanie się optymalizuje pracę zespołu.

A jakie problemy w Zespołach Scrumowych obserwujesz Ty? Czy, któreś z wymienionych przez nas zdarzają się też w Twoim zespole?

Dodatkowe materiały

Transkrypcja podcastu „Najczęstsze problemy Zespołów Scrumowych”

Jacek: W dzisiejszym odcinku porozmawiamy o najczęstszych problemach Zespołów Scrumowych. Zastanowiliśmy się z Kubą, z jakimi problemami najczęściej spotykamy się w praktyce pracy konsultanckiej. Zebraliśmy te problemy i przygotowaliśmy dla Was rozwiązania.

Kuba: Tych problemów, które wymienimy – będzie pięć. Do każdego z tych problemów też wyselekcjonowaliśmy po trzy rozwiązania, które przychodzą nam do głowy jako te, najbardziej obiecujące. Te, które też najczęściej próbujemy zarekomendować, czy sami też wprowadzamy. I przechodząc od razu do rzeczy, bo odcinek będzie tłusty od różnych możliwych rozwiązań, to przejdźmy do pierwszego problemu. Pierwszy problem, który spotykają Zespoły Scrumowe to to, że obiecują terminy, których potem nie dotrzymują. Mam tu na myśli taką sytuację, że zespół sobie planuje pracę. Planuje pewien zakres pracy na Sprint. Może też planuje pracę na jakiś dłuższy horyzont czasowy, na przykład kilka Sprintów, jakieś wdrożenie projektu, czy kolejnej wersji produktu i te terminy okazują się być niedotrzymywane. I pierwsze rozwiązanie możliwe na taką sytuację – brzmieć może ono banalnie, ale problem z takim dotrzymywaniem terminów wynika z tego, że w wielu Zespołach spotykam to, że nie ma żadnego planu. Więc pierwsza porada – Przygotuj plan pracy w zespole. Planowanie Sprintu to nie tylko ustalenie celu Sprintu, to nie tylko ustalenie zakresu prac, które będą realizowane, ale to też przygotowanie sobie pewnego pomysłu na to, jak będziemy pracować w Sprincie. Kto co zrobi? Jak to się będzie układało czasowo? Czy są jakieś zależności między zadaniami, ale też zależności między osobami w zespole? No i to wszystko może rzutować na to, że już w zasadzie, gdy przysiądziemy do takiego planu pracy, zobaczymy, że albo pewne rzeczy są niewykonalne, bo na przykład za dużo jest zależności, albo jedna osoba jest zbyt przeciążona – na przykład tester w końcówce Sprintu. Ale też może się okazać, że będziemy wyczuleni na jakieś takie krytyczne momenty, czy takie newralgiczne momenty w Sprincie, czy nawet w sekcji, czy grupie kilku Sprintu, które nas doprowadzą do pewnego większego projektu. Czyli podsumowując tę poradę – przygotujmy zespołem plan pracy, zwizualizujmy sobie, poukładajmy sobie to, jak chcemy tę pracę wykonać. Tak, żeby albo wyłapać, że będziemy obiecywać ten nierealistyczny termin – w sensie jak tylko do tego przysiedliśmy, to już widzimy, że nie mamy szans, lub żeby też być wyczulonym na takie jakieś trudne momenty w pracy zespołu, które mogą stawiać pod znakiem zapytania realność zrealizowania terminu pewnych prac.

Jacek: Druga wskazówka, która pomaga dotrzymywać terminy, w szczególności w tym ujęciu takim krótkoterminowym – jak mówił Kuba, czyli ta nasza prognoza na planowanie Sprintu, no to jest użycie danych historycznych do planowania. Czyli do tego wszystkiego, co Kuba powiedział, ja bym dorzucił to, że warto spojrzeć na nasze historyczne rezultaty, jakie mamy wyniki – jeżeli chodzi o Sprint. Mam tutaj na myśli, czy ilość zrealizowanych zadać, czy jeżeli jakieś zespoły korzystają z systemów estymowania relatywnego, to może warto podsumować Story Pointy, jeżeli zespół czymś takim dysponuje. I tutaj usilnie rekomenduję, żeby spojrzeć jednak, ile realnie jesteśmy w stanie zrealizować, na przykład używając techniki Yeasterday Weather, czyli patrzymy na ostatni wynik naszego Sprintu i na tej podstawie, a nie na podstawie myślenia życzeniowego dobieramy ilość elementów, które przewidujemy, że zrealizujemy w trakcie nadchodzącego Sprintu. Mówiąc o tej poradzie, mam takie podobne poczucie jak Kuba przed chwilą, że jest to taki absolutny banał. Natomiast bardzo często w swojej praktyce konsultanckiej widzę sytuacje, w których zespół planuje. I tak naprawdę do końca, że jeszcze kolejne zadanie, że jeszcze jeden element, że jeszcze jedno story sobie dokładają. Tak więc prosta porada – użyj danych historycznych do planowania.

Kuba: I trzecia rzecz, która nam przychodzi w temacie obietnic, które później nie są dotrzymywane, to jest pewna hipoteza, albo pewne podejrzenie, że to niedotrzymanie terminów wynika z tego, że podjęta została praca, która jest albo nieprzygotowana, albo niewystarczająco znana zespołowi, albo też być może na przykład wystarczająco drobno podzielona. Więc porada trzecia na niedotrzymywanie terminów, być może ta już mniej już taka wprost oczywista – zainwestuj czas w Refinement. Całym zespołem poświęćmy pewien procent czasu w trybie takim ciągłym, takim rutynowym na to, żeby ciągle doskonalić Backlog Produktu, ciągle szukać pełnego zrozumienia, budować kryteria akceptacji, rozpisywać też te elementy właśnie też na drobniejsze kawałki. Być może regularnie robić sesje Story Mappingu. No technik na Refinement jest cała masa. Wymieniliśmy je w odcinku dziewiątym i tutaj w tym nagraniu nie będziemy już tego powtarzać. Zapraszam Cię do odsłuchania odcinka dziewiątego o Refinemencie. Natomiast no jakby tutaj przypomnimy, czy zwrócimy uwagę na taką dosyć prostą zależność. Wiele zespołów się nie wyrabia z pracą, albo nie umie jej dobrze ocenić, czy dobrze też rozplanować. Dlatego że po prostu nie wystarczająco dobrze ten produkt, który jest do zrobienia, jest zespołowi znany. Kontekst tego produktu nie jest znany. No i to wszystko wynika z tego, że po prostu nie poświęciliśmy na to odpowiednio dużo czasu. A co gorsza może się tak zdarzyć, że tutaj wpadniemy w jedną z możliwych takich pętli bardzo niebezpiecznych, że nie wyrabiamy się, więc musimy ratować termin. Więc nie robimy Refinementu na kolejny Sprint, więc znowu się nie wyrobimy i to może tak już z nami zostać. Więc tutaj jest to miejsce, gdzie ktoś musi bardzo mocno postawić sobie takie zobowiązanie, może najlepiej, żeby cały zespół to odczuwał, że – słuchajcie, najbliższy Sprint, koniecznie robimy ten Refinement. To nie jest spotkanie opcjonalne, czy tam warsztaty, albo jakaś praca, z której możemy zrezygnować, jeśli jesteśmy pod presją czasu. Nie. Bo my nigdy nie wyjdziemy z tej presji czasu, jeśli tego Refinementu nie zrobimy.

Jacek: Refinement i Retrospektywa, to są te dwa wydarzenia, które bardzo często są wybierane jako te, z których zrezygnujmy, żeby zyskać trochę czasu, no ale paradoksalnie efekt będzie odwrotny, niż się spodziewamy. Na dobre to na pewno nie wyjdzie. Drugi najczęstszy problem, z którym się spotykamy, to sytuacja, w której po wdrożeniu pojawia się całe mnóstwo błędów i awarii. Czyli z jednej strony dowiadujemy się już z systemu produkcyjnego, że no to, co przygotowaliśmy, nie działa tak, jak powinno. Gorsza sytuacja jest taka, kiedy pojawia się awaria w takim rozumieniu, że ona blokuje na przykład kompletnie dostęp do produktu. No i co tutaj można zrobić?

Jacek: Pierwsza porada, którą chcemy zarekomendować w tym kontekście, to jest porada – zadbaj o zdefiniowanie oraz przestrzeganie Definicji Ukończenia. Definicja ukończenia, można o niej pomyśleć jako o takiej pewnej bramce, która zapewnia nam zarówno kompletność naszego przyrostu, jak i też dba o to, żeby był on odpowiedniej jakości. Pierwszy krok, żeby wykorzystać Definicję Ukończenia, to jest oczywiście zdefiniowanie dokumentu, czy jakiegoś takiego miejsca, w którym będziemy mieć spisane, przygotowane jakieś konkretne ustalenia, które wewnątrz zespołu zostaną przedyskutowane. To jest jakby pierwszy krok – czyli musimy mieć przede wszystkim zgodę w zespole, na co my się tak naprawdę umawiamy. No i jeżeli mamy już takie coś przygotowane, no to oczywiście kolejny krok. Nie wiem, czy nie trudniejszy. No to jest przestrzeganie Definicji Ukończenia w praktyce. To, co może pomóc, to na pewno, jeżeli pracujemy na jakiejś wspólnej przestrzeni, to posiadanie tej Definicji Ukończenia gdzieś na widoku. Możemy ją wydrukować, gdzieś tam sobie przywieźć. Jeżeli nie, no to możemy sobie w ramach narzędzia, z którego korzystamy dołożyć jakieś check box, jakiś przypominacz, żeby zanim coś uznamy, że jest zakończone – mówiąc tak obrazowo, przeciągniemy do tej kolumny Done, no to żeby jednak wcześniej sprawdzić, czy to faktycznie wszystko to, co sobie zdefiniowaliśmy, zostało przez nas uwzględnione.

Kuba: I nawiązując do tego, co mówisz Jacek o tych kwestiach Definicji Ukończenia, to ja tutaj zwrócę uwagę na to, że taki aspekt Scruma powiązany z Definicją Ukończenia, to to przestrzeganie pewnej dyscypliny. I tutaj zespół się jakby wzajemnie zobowiązuje do tego, że mamy pewien standard. Standard, który jest powtarzalny. Standard, który będzie w szczelny sposób przestrzegany. I wielokrotnie widzę, że takim proszeniem się o kłopoty, to jest właśnie przymykanie oka, jakieś takie odpuszczanie sobie. Na przykład odpuszczenie sobie poprawienia błędów, odpuszczenie sobie zrobienia dobrych testów, czy nawet jakiejś rzeczy takich bardzo porządkowych związanych ze środowiskami z dokumentacją. I to się wszystko później strasznie mści. Mści się, gdy trzeba naprawić, ale nawet tu też na pewno jest zależność między tym, że robimy to jakość tak trochę umownie i ona nam trochę umownie wychodzi i niestety się te jakby błędy piętrzą. Awarie sprawiają, że też mamy jakieś stresujące sytuacje zaraz po wdrożeniu, czy w kolejnych sprintach. Więc tutaj całym zespołem zgódźmy się na zdyscyplinowane przestrzeganie tej Definicji Ukończenia. Druga rada, która jest związana z jakością – mniej może taka organizacyjna, czy porządkowa, DoD jest taką jednak umową zespołu, to jest też ta strona do zrobienia po prostu techniczna, praktyczna. Korzystanie z konkretnych praktyk, zwinnych praktyk programistycznych. I co tutaj mamy na myśli Jacek?

Jacek: Tak. Generalnie może słowo jeszcze wprowadzenia. Jest sporo praktyk, takich nazwijmy to procesowych, które bardzo łatwo zaobserwować. Czyli przykładowo praktyka codziennego stand-upu, czy praktyka posiadania osoby takiej, która reprezentuje potrzeby klienta w Scrumie, to mówimy tutaj o odpowiedzialności Product Ownera. Natomiast jest cała masa również takich praktyk, które nazwałbym praktykami czy technicznymi, czy praktykami programistycznymi. Czyli takie praktyki, jak na przykład automatyzowanie pracy, czy takie rzeczy jak częste tworzenie buildów, czyli budowanie kodu. Integrowanie różnych fragmentów wytworzonych przez różne osoby, bądź zespoły w jedną całość i upewnianie się jak najwcześniej, że to wszystko działa tak, jak sobie przewidzieliśmy, czy ciągła integracja, refaktoryzacja kodu. Jest sporo pojęć i sporo praktyk, a już w ogóle cała masa literatury, jak zrobić to dobrze i zwracamy na ten punkt szczególną uwagę, obserwując pewien taki trend, że jest spory zachłyśnięcie Scrumem, zmiennością, ogólnie w organizacjach. Natomiast trudno oczekiwać, że na przykład ten konkretny framework da nam wartość, jeżeli pod spodem będziemy wytwarzać oprogramowanie czy produkty cyfrowe, że tak powiem po staremu, nie wykorzystując tych narzędzi, które akcelerują i wzmacniają taką procesową zwinność. Tak więc zdecydowanie, jeżeli w Twojej organizacji widzisz braki w tym obszarze, to jest to temat, którym na pewno warto się zainteresować.

Kuba: Warto się też zainteresować tym, zwłaszcza jeśli takie braki widzisz w sobie, bo też wiemy – ja też jestem np. osobą bez backgroundu technicznego. No i to wtedy niektórzy traktują jako coś, co stoi obok Scruma. Nie poruszamy tego tematu. Nie rozmawiamy o tym i nagle się okazuje, że te aspekty jakościowe w naszym zespole są niewystarczająco dobrze poruszone. Nie trzeba się na tym znać na wylot, nie trzeba osobiście umieć to wprowadzić w swoim zespole, ale w szczególności zwracajmy na to uwagę, zadajmy pytania, spróbujmy to zrozumieć lub poszukamy w organizacji kogoś, kto może nam w tym pomóc, żeby takie aspekty były zauważalne, promowane, dzielona wiedza na ten temat.

Jacek: Trzecia porada, którą dla Ciebie mamy, to porada, która brzmi – wdrażaj częściej mniejsze kawałki produktu. Generalnie jest tak, że im większy kawałek kodu, czy im większy kawałek produktu chcemy udostępnić naszym użytkownikom, no tym generalnie jest większa szansa, że zabraknie nam czasu, żeby przetestować całość, czy przeoczymy jakiś element, czy kawałek produktu. Dlatego dobrą praktyką jest dzielenie sobie pracy na małe kawałki. To powoduje, że jesteśmy w stanie szybciej wyprodukować zmianę, jesteśmy w stanie tę zmianę szybciej przetestować, bo jest ona mniej złożona. Jeżeli mamy jakieś proces w stylu Code Review, czyli ktoś inny niż my patrzy na nasz kawałek kodu, żeby dać do niego informację zwrotną, to to też szybciej taką recenzję dostaniemy, no bo do obejrzenia jest, nie wiem, 25 linijek kodu, a nie tysiąc. No i tak samo z jakimiś testami automatycznymi, czy też z dalszym procesem wdrażania na produkcję. Im ta zmiana jest mniejsza, tym ten czas do informacji zwrotnej jest krótszy. Całe przetwarzanie takiej zmiany trwa krócej. No i na wcześniejszym etapie jesteśmy w stanie odkryć, że jakieś tam obszary naszego produktu są na niedostatecznie dobrym poziomie jakościowym. Tak więc dzielenie na mniejsze kawałki, jest to zdecydowanie praktyka, którą mocno rekomendujemy.

Kuba: Trzeci problem, jaki chcemy zaatakować w odcinku – to efekty pracy zespołu są rozczarowujące. Mamy tu na myśli taką sytuację bardziej biznesową, czy tę perspektywę produktu. Zespół pracował, pracował, pracował, wdrożył i nie ma rezultatów. Nie ma spodziewanych wyników biznesowych. Użytkownicy wcale nie są zachwyceni. Biznes wcale nie dostał tej wartości, na którą czekał. Obietnica dużej wartości dodanej okazuje się być nieprawdziwa. I tutaj kilka rozwiązań na taką sytuację, która niestety bywa też częsta. Pierwsze z nich to zapewnienie kontekstu biznesowego w zespole. Jeśli jest tak, że zespół zrealizował jakieś rozwiązanie, które okazuje się być niedopasowane, nie wystarczająco dobre. Być może ma jakieś luki ,albo jakieś takie ewidentne jakieś takie bym powiedział błędy, jeśli chodzi o pewne pomysły. To moją mocną hipotezą jest to, że zespół po prostu nie rozumie produktu. Nie zna kontekstu, nie rozumie strategii, jaką wybieramy – biznesowej czy jakiejś marketingowej. Te wszystkie kwestie prawdopodobnie spowodowały, że to rozwiązanie jest niewystarczająco dobre. Czyli tu zwłaszcza strona biznesowa, zwłaszcza interesariusze, zwłaszcza Product Owner, jeśli mamy jakichś ekspertów biznesowych w zespole, to również od takich osób oczekiwałbym, że będą propagować do wszystkich pozostałych członków Zespołu Scrumowego informacje na temat tego, jaka jest wizja produktu. Jakieś konkretne potrzeby grupy docelowej. Sama definicja tej grupy docelowej. Więc tutaj wiele można zrobić, żeby cały Zespół Scrumowy rozumiał kontekst tego, czym jest nasz produkt, kim jest nasz klient i czego też oczekuje organizacja, czy w którą stronę organizacja chce się przesunąć, jeśli chodzi o tę definicję produktu.

Jacek: W pewnym sensie pogłębieniem tej wskazówki, którą Kuba się przed chwilą podzielił, jest taka porada, żeby zmniejszyć odległość zespołu od użytkownika końcowego. I to jest myślę – coś takiego, dodatkowego, co możemy zrobić, oprócz takiego nazwijmy to suchego kontekstu biznesowego, który dostarczamy w zespole. I tutaj mam swoje własne doświadczenia z pradawnych czasów, kiedy budowałem swój własny produkt, że pomimo iż jest to takie początkowo niekomfortowe, no bo jednak pokazujemy to nasze dziecko. I ktoś zaczyna obsługiwać nasz produkt i tutaj sobie mlaśnie, tutaj coś w sobie chrząknie, tutaj mówi, ale zupełnie nie wiem, gdzie mam kliknąć i o co chodzi. A dlaczego to działa tak wolno i tak dalej. Więc jakby to może być początkowo takie niekomfortowe doznanie. Jednak im więcej czasu spędzimy z taką osobą, tym lepiej zrozumiemy, jakie ta osoba ma potrzeby, jakie ma problemy. Sporo też ciekawych informacji jesteśmy w stanie z takich spotkań z prawdziwym użytkownikiem produktu wyciągnąć. Dodam taką smutną refleksję, że rzadko to widzę w organizacjach. Może to jest kwestia, że w jakimś konkretnym typie organizacji najczęściej się pojawia. Natomiast, no bardzo często jest tak, że zespół, który wytwarza produkt, nigdy nie miał szans zobaczyć prawdziwego użytkownika. Posłuchać go. Zrozumieć jego problemy. A powiedziałbym, że jest to taka fundamentalna wartość, jeśli chodzi o podejście zwinne, żeby jednak tę odległość skracać. Tak więc zdecydowanie zachęcam Cię do poeksperymentowania z tą techniką i zastanowienia się, w jaki sposób można byłoby doprowadzić do tego, żeby zespół tę odległość do użytkownika końcowego zmniejszył.

Kuba: I trzecia porada w tej części odcinka, to jest założenie, żeby robić małe eksperymenty i wyciągać na ich podstawie wnioski. Ten problem, który tutaj zdefiniowałem na początku tego akapitu, on często w swojej źródłowej jakby praprzyczynie tego, że rozczarowujące efekty są całej pracy zespołu, jest to, że ta cała praca, to jest właśnie coś wielkiego. Coś dużego. Duży projekt, albo duże wdrożenie. Cały kwartał kminiliśmy, knuliśmy, jakoś szykowaliśmy się. Po czym buch na rynek i rynek jednak nie zareagował. Rynek jednak aż tak nie docenił tego, że się naprawdę mocno staraliśmy i naprawdę główkowaliśmy. Więc tutaj jest taka pułapka tego, że ten Scrum nie jest w taki porządny sposób wykorzystany. Tak to nazwijmy trochę tutaj, powołując się na tytuł naszego podcastu. Porządny Scrum dla mnie to też jest coś takiego, że najrzadziej raz na Sprint, a może nawet jeszcze częściej, dajemy przyrost, pokazujemy jakieś efekty. I ten prawdziwy przyrost, taki najmocniej rozumiany przyrost, to jest coś, co ląduje u klienta. To jest coś, co lądują użytkownika końcowego. Odbieramy feedback na ten temat. No i są dwa scenariusze. Ten scenariusz powiedzmy pesymistyczny. Zrobiliśmy jakiś bardzo wczesny eksperyment, mikro wersję, miały prototyp, jakkolwiek to nazwiemy i klient mówi – nie to jest zupełnie nie tego, czego chce. To mi nic nie daje. To nie jest w ogóle ten kierunek. No to jest pesymistyczny scenariusz, w tym sensie, że zupełnie nie trafiamy. Ale jeśli to jest mały eksperyment, no to też dzięki temu niewiele straciliśmy. Dosyć szybko korygujemy kurs albo porzucamy ten kierunek, albo naprawiamy to, co do tej pory przyszykowaliśmy.

Kuba: No i jest ta ścieżka optymistyczna. Druga flanka jakby. Czyli zrobiliśmy kawałek. Klient mówi – tak świetne, jeszcze bym potrzebował tego i tego, a w ogóle to nawet o tym wcześniej nie myślałem, ale bardzo mi się podoba to co przy okazji zrobiliście. Czyli takie znalezienie szczególnie dobrych elementów tego co zostało do tej pory wykonane i bazowanie na tym. Pogłębianie jakby tutaj jeszcze sukcesu tylko w ten sposób. Żeby to miało miejsce, no to powtórzę – tu musi być myślenie małymi eksperymentami i bardzo regularny kontakt z klientem. Czyli połączenie z tą radą, o której Jacek przed chwilą mówił. Jeśli będziemy robić małe eksperymenty i wyciągać na ich bazie wnioski najrzadziej co sprint, no to jest też spora szansa, że w ogóle nawet nie będzie rozmowy o tym, że tutaj jakieś rozczarowujące efekty. No bo co rusz poznajemy jakby nowe konteksty. Może się tak zdarzyć, że jednak w ogóle cała tutaj koncepcja produktowa jest po prostu błędna. No ale to przynajmniej wcześniej się o tym dowiemy. No i dla niejednej organizacji taki eksperyment, to też będzie coś wartościowego. Spróbowaliśmy jakiejś sfery czy jakiegoś tam kierunku. Okazuje się, że jednak nie jest wystarczająco obiecujący. No ale przynajmniej spróbowaliśmy. O takich kwestiach związanych z zaangażowaniem zespołu w pracę, też wciągnięciem zespołu po to, żeby uzyskiwać lepsze rezultaty, mówiliśmy w 31. odcinku, do którego też mocno zapraszam czy rekomenduję. Znajdziesz go albo w apce, tylko pewnie trzeba zescrollować, bo tych odcinków już mamy sporo lub pod adresem porządnyagile.pl/31

Jacek: Czwartym, przedostatnim najczęstszym problemem Zespołów Scrumowych, z którym się spotykamy, to sytuacja w której, gdy pojawia się problem, to udajemy, że go nie widzimy. No i cóż, tutaj generalnie taką paradą, którą mamy, to jest porada, która brzmi – pokazuj słonia w pokoju podczas Retrospektywy Sprintu. Czym jest ten słoń w pokoju? No jest to temat, o którym nie chcemy opowiadać, no ale tak jak słoń w pokoju jest trudny do niezobaczenia, tak samo ten problem po prostu na nas oddziałuje. No i on z nami jest. Jesteśmy przyciśnięci, ściśnięci i dociśnięci, no ale udajemy, że jest fajnie i rozmawiamy o czymś innym. Tak więc, no tutaj generalnie raczej bym nie szedł w jakieś konkretne, powiedzmy techniki, które można wykorzystać na Retrospektywie Sprintu, a na pewno takie są, jak nie, to można wymyślić. Ja raczej bym tutaj poszedł jednak w taką bardziej miękką stronę. Czyli moim zdaniem potrzeba odwagi i potrzeba pewnego stopnia przywództwa, żeby jednak powiedzieć – słuchajcie, a ja generalnie chciałbym czy chciałabym zwrócić uwagę na problem X albo na problem Y. I to jest odwaga, żeby albo o tym powiedzieć, albo żeby w procesie zbierania tematów do Retrospektywy na jakiejś tam kartce, na Muralu, czy na zwykłym post-it napisać, że jednak jakiś tam problem duży widzimy. Nawet wiedząc o tym, że dyskusja będzie nieprzyjemna albo ciężka, albo trudna. A często też odkrycie takiego słonia w pokoju może doprowadzić do tego, że właściwie to całą Retrospektywę Sprintu, a może nawet inne dedykowane spotkanie będziemy potrzebowali poświęcić, żeby ten problem rozwiązać. Natomiast bez rozwiązania tego problemu może być tak, że po prostu nie ruszymy dalej.

Kuba: I tym słoniem w pokoju mogą być takie problemy, które poruszamy w tym odcinku. Więc tutaj zapraszamy Cię Słuchaczu lub Słuchaczko do tego, żeby też się zastanowić czy czasami te problemy, o których my tutaj tak sprawnie po kolei sobie wymieniamy, czy nie dotyczą też Twojego zespołu, czy części firmy, w której się znajdujesz? No ale mamy też na myśli również takie rzeczy międzyludzkie, jakieś rzeczy właśnie jakieś bardzo specyficzne dla danej sytuacji, gdzie po prostu wszyscy milczą, a problem jednak istnieje. Druga możliwa porada na temat tego co zrobić, gdy ignorujemy jakieś problemy, albo nie chcemy ich poruszyć, czy udajemy, że ich nie widzimy, że one nie istnieją. To zwłaszcza porada dla liderów zespołów, którzy jednak taki problem dostrzegają i dziwią się, dlaczego inni nie chcą tego tknąć – to sprawdzenie, czy środowisko pracy nie demotywuje. Tutaj taka bardzo konkretna koncepcja, w którą ja bardzo mocno wierzę to to, że o ile nie jesteśmy w stanie zmotywować ludzi, jakąś dobrą przemową sprawić, że nagle ludzie zaczną przenosić góry, to w drugą stronę to zjawisko może mieć miejsce. Czyli jakieś konkretne procesy, jakieś konkretne zachowania menedżerów organizacji. Jakaś konkretna toksyczna osoba. Jakieś może niezrozumiałe zmiany? To wszystko może powodować, że ludziom się bardzo mocno odechciewa. Odechciewa się do takiego stopnia, że niestety na przykład nie mają najmniejszego zapału do tego, żeby jeszcze sobie utrudniać życie jakimiś rozmowami o możliwych uprawnieniach. Być może nawet nie wierzę już w to, że to w ogóle jeszcze ma sens, żeby te usprawnienia do czegoś doprowadzały. I to jest trochę paradoksalna porada w temacie jakby niedostrzegania problemów w swoim własnym zespole, ale zwłaszcza gdy pracuję z organizacjami, w których np. menedżer zaczyna tak powiedzmy utyskiwać na to, że – zobacz kurcze, tyle problemów a oni o niczym nie wspominają, albo jak ja ich pytam, to mi nic nie mówią. To dosyć szybko odwracam uwagę tej osoby na to, ile jest do zrobienia wokół tego zespołu. Bo ja tu bardzo mocno wierzę w to, że jeśli otoczenie będzie takie wspierające, czy takie powiedzmy przyjazne, pozytywne, no to ludzie jednak będą chcieli rozmawiać o takich rzeczach. I jakby poczucie zespołowości i poczucie realizacji celu też doprowadzi do tego, że rozmawiamy o trudniejszych rzeczach. Ale jeśli to środowisko pracy, właśnie tak jak już może się trochę powtarzam, demotywuje ludzi, no to nie spodziewamy się, że nagle pomimo tej demotywacji, będą jeszcze gotowi atakować jakieś trudne wątki w tym jak współpracują, czy jak pracuje jako zespół.

Jacek: I lobie te poprzednie porady, one mocno zachęcają do tego, żeby podejmować rozmowy i patrzeć i zarówno w stronę zespołu, czy do wewnątrz zespołu, ale również też patrzeć na środowisko. Taką trzecią poradą, trochę zamykającą jest porada o tym, żeby skorzystać z technik prowadzenia trudnych rozmów. Czyli nie sztuką jest uruchomić taką rozmowę i doprowadzić do konfliktu, do wzajemnego obrażania się. Do sytuacji, która spowoduje, że ludzie jeszcze bardziej się zamkną w sobie, zamiast otworzyć. Sztuką jest poprowadzenie tego w ten sposób, żeby mimo wszystko pozostawić skupienie na problemie i na rozwiązaniu, natomiast trochę mniej tam poszukiwać kto był winien i jaką karę powinien ponieść. Tak więc przykładowe techniki, które tutaj mam na myśli, to jest, czy technika dawania w sposób taki ustrukturyzowany informacji zwrotnej na przykład FUKO, czy generalnie cała taka nazwijmy to filozofia prowadzenia dialogu, który nie jest ofensywny, czyli NVC.

Kuba: I ostatni problem, który poruszamy w tym odcinku, to takie stwierdzenie – potrzebujemy robić wiele więcej, niż obecnie robimy. I usłyszeć to możemy od zarządzających organizacją, którzy mają mocarstwowe plany, tylko przepustowość ich zespołów nie jest taką, jaką by chcieli. To usłyszymy od na przykład Product Ownerów, którzy podobnie mają cały długi Backlog Produktu, a te kolejne Sprinty nie są tak satysfakcjonujące, ale czasami nawet i sam zespół powie sobie między sobą, że kurcze, kurcze chcielibyśmy robić więcej, no ale z jakiegoś powodu to nam nie wychodzi. Jesteśmy w tym miejscu, gdzie jesteśmy. I tutaj Pierwsza porada jest taka trochę paradoksalna, czy takim odwróceniem perspektywy. Wiele osób, gdy mówi w ten sposób, jak zarysowałem w tym wstępie do tego problemu, to myśli jednak o ilości pracy wykonanej. A moja rekomendacja, to jest – spójrz na wartość dodaną z pracy, a nie ilość pracy wykonanej, nie urobek. I to jest czasami taka bardzo wielka pułapka, że wiele osób patrzy na przykład ilość ficzerów, ilość Story Pointów, jakichś kolejnych projektów, które są zrealizowane, a bardzo mało się rozmawia, jaka jest wartość tych wykonanych działań. I nie sztuką jest, czy to jest ślepa uliczka, żeby myśleć o tym, żeby zwiększać w ciemno w nieskończoność ilość wykonanej pracy. Jeśli ta wykonana praca jest bezwartościowa, albo jej wartość jest nikła. Więc tutaj coś, od czego trzeba zacząć to znalezienie takich jakichś mierników, może definicji tego, co tu jest wartością w naszym produkcie. I to nie zawsze będzie oczywiste, a później również rozpatrywanie czy kolejne wykonane kroki i kolejne działania kolejne elementy Backlog Produktu, które zostały skończone, dobrze wpływają na tę wartość dodaną. Czy te ficzery, czy te kawałki kolejnych elementów naszego produktu, który wykonaliśmy, czy one są korzystne dla naszego biznesu? Czy cokolwiek tym naszym biznesem tutaj jest? I może się okazać, że gdy zaczniemy rozmawiać o tym, jakie są korzyści z naszej pracy, to jakby kierunkiem wcale nie będzie – róbmy więcej Story Poitntów, tylko selekcjonujmy lepszej jakości, czy bardziej obiecujące kawałki produktu. Być może to nie ilość pracy, ale jej wartość jest to tym, co trzeba poprawić.

Jacek: Druga porada, która może poprawić problem, że chcemy więcej, niż jesteśmy obecnie w stanie dostarczyć, to porada, która zachęca do poszukiwania i likwidowania marnotrawstwa w procesie pracy. Czyli znów – nie zachęcamy do tego, żeby szybciej uderzać w klawiaturę, a raczej znów taka trochę kontr porada na zasadzie, spójrz na proces i zastanów się, czy na którymś z tych etapów jest, czy występuje marnotrawstwo? Przykład marnotrawstwa to jest np. oczekiwanie. Czyli co z tego, że naprodukujemy na przykład jakichś zmian backendowych, jeżeli te zmiany teraz będą leżeć i czekać aż w kolejnym Sprincie np. zostanie doprodukowany frontend do tego. Albo sytuacja, w której produkujemy jakiś kod, jakieś funkcje, czy funkcjonalności i oczekujemy na przetestowanie, czy oczekujemy na Code Review, czy oczekujemy na cokolwiek innego. Jak spojrzymy, no to suma tych wszystkich oczekiwań może być naprawdę znacząca i to, że ktoś tam się super bardzo stara i produkuje tylko po to, żeby to wrzucić do poczekalni, no to zdecydowanie to nie jest kierunek. Tak więc mocna rekomendacja, żeby spojrzeć na marnotrawstwa. Tych marnotrawstw jest więcej. Tutaj odsyłamy do właściwej literatury. No i poszukać takich elementów, które można usunąć z procesu pracy.

Kuba: I ostatnia porada w temacie robienia wiele więcej niż obecnie robimy, to porada skup się całym zespołem na realizacji celu Sprintu. Coś, co jest dla mnie niepokojącego w tego typu sytuacjach, to to, że dosyć często widuję fakt, że pomimo tego, że do zrobienia jest wiele więcej, niż zespół jest w stanie zrobić, to, co gorsza, i tak kupę energii, czy spory procent czasu poszczególnych osób w zespole przekierowywane jest na rzeczy, które nie są istotne, które nie są celem danego Sprintu, które są jakąś pracą taką poboczną. Jak już przy okazji robimy, to zróbmy jeszcze to. To jest jeden z przypadków, ale też osobny aspekt związany z takim skupianiem się. Zespół rozdziela swoją pracę na indywidualne kawałki. Różne osoby realizują jakieś małe cząsteczki, takie jak kawałki puzzla, gdzieś tam w separacji. Niekoniecznie intensyfikują swoją pracę, niekoniecznie sobie wzajemnie pomagając. Też bez przepływu energii, bez jakiegoś odblokowania się. Może też również takiego dodatkowego nakręcenia się do wykonywania pracy. No i to wszystko sprawia, że po pierwsze nie tworzymy zespołu, po drugie nie realizujemy tego, co jest naprawdę najważniejsze. No i też potencjalnie też rozwlekamy mocno swoją pracę. Więc tutaj takim sekretem, czy jedną z ważnych części Scruma, to jest powiedzmy – to zobowiązanie do skupienia się na celu Sprintu. Faktyczna praca całym zespołem w stronę tego, żeby ten cel osiągać. Osiągać jak najczęściej korzystać z okazji do tego, żeby też pracować więcej niż jedną osobę, żeby się wymieniać tą wiedzą, żeby się właśnie nakręcać. Wszystkie te rzeczy, które już wymieniłem.

Jacek: Rozmawialiśmy dzisiaj sporo o najczęstszych problemach Zespołów Scrumowych. Jeżeli ten temat jest dla Ciebie interesujący, to chciałbym zaprosić Cię na warsztaty Labirynty Scruma, 9-10 września w Warszawie. Będą to warsztaty stacjonarne, więc będzie też okazja, żeby spotkać się na żywo i porozmawiać. Gdzie skupimy się na tym, jak radzić sobie z najpopularniejszymi problemami w Scrumie i przepracujemy to sobie grupowo. Do końca lipca cena o 20 % niższa. Tak więc zachęcam do zapisywania się. Mam już pierwsze osoby na liście, tak więc zachęcam do przejścia na stronę labiryntyscruma.pl/szkolenie, żeby zarezerwować sobie miejsce.

Kuba: Jak zwykle notatki do tego odcinka z linkami do materiałów, które wspominamy, transksrypcją, zapisem wideo z sesji nagraniowej, znajdziesz na stronie porzadnyagile.pl/66

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.