Kiedy Scrum nie jest odpowiedzią?

Twój zespół startuje z nową inicjatywą i zastanawiasz się co wybrać. Jak ma pracować? Scrum nie zawsze jest tutaj pasującym wyborem. Jest jednym z najpopularniejszych frameworków i dlatego zwykle jest brany pod uwagę jako pierwszy. Rzucamy światło na to kiedy naszym zdaniem Scrum nie powinien być stosowany.

Najbardziej popularnym frameworkiem pracy w zespołach zwinnych jest Scrum. Jednak czy zawsze jest on dobrym wyborem? Kiedy Scrum nie powinien być stosowany i jakie czynniki na to wpływają?

Podejmując nową inicjatywę lub tworząc nowy zespół, warto się zastanowić jaki framework pracy zwinnej sprawdzi się najlepiej w tej konkretnej sytuacji, w tym zespole lub w tym projekcie. Mimo że Scrum jest najpowszechniejszą metodyką zwinną to są pewne kryteria czy też czynniki, kiedy to warto z niego zrezygnować. 

Kiedy Scrum nie powinien być stosowany?

1. Brak wspólnego celu

Pierwszym kryterium powodującym, że Scrum się nie sprawdzi, to sytuacja, gdy zespół nie ma wspólnego celu. Jest to bardzo istotny czynnik wpływający na pracę zespołu, ponieważ cel jest fundamentem pracy zespołu, wskazuje kierunek działania i sens realizacji projektu. Bez jednego celu lub przy kilku różnych celach, nawet przy wdrożeniu pewnych elementów Scruma, to jedna z wartości tego frameworku, czyli skupienie, będzie pogwałcona. W takim przypadku zespół będzie działał bez poczucia celowości, a każdy z członków będzie robił coś swojego.

Szczególnie niebezpieczną sytuacją jest brak jakiegokolwiek celu. Nie będzie tu wówczas miejsca na korzystne efekty, jakie przynoszą Sprinty. Nie da się ustalić Celu Sprintu, a praca zespołu będzie miała charakter mechaniczny.

2. Brak złożonego problemu do rozwiązania

Złożony problem to np. wypuszczenie na rynek nowego produktu lub nowa, bardziej innowacyjna wersja już istniejącego produktu. Przy starcie projektu, zespół jeszcze nie wie, jak do niego podejdzie, jak rozwiąże to zadanie. Jeśli brak jest takiego złożonego problemu, a zespół wykonuje powtarzalne czynności i zajmuje się powtarzalnymi, sprocedurozowanymi czynnościami to Scrum się nie sprawdzi, ponieważ nie wniesie żadnej wartości dodanej. 

Gdy wszystko jest przewidywalne i proste to wdrażanie mechanizmu wydarzeń scrumowych będzie tylko stratą energii i czasu zespołu. Nie ma tu co nas zaskoczyć i przykładowo przegląd Sprintu będzie tylko spotkaniem czysto formalnym czy statusowym. 

3. Brak kandydata na Product Ownera

Taka osoba powinna być reprezentantem potrzeb, reprezentantem biznesu, reprezentantem interesariuszy. Dobrego Product Ownera cechuje decyzyjność, która w wielu organizacjach wiąże się z pewnego rodzaju autorytetem czy zaufaniem całej organizacji do tej osoby. 

Rola Product Ownera jest na tyle krytyczna w Scrumie, że bez niego mogą pojawić się spore problemy i kłopoty.

4. Brak samodzielności i autonomiczności zespołu

Scrum się nie sprawdzi, gdy zespół nie ma zapewnionej autonomiczności i samodzielności, przez co nie jest on w stanie dostarczyć działającej wersji produktu. 

Może to wynikać z braku wszystkich niezbędnych kompetencji w zespole. Przykładowo w produkcie cyfrowym, zespół składa się z developerów od frontendu i backendu, ale brak w nim testerów, którzy stanowią odrębny zespół. Podobnie może być, gdy produkt składa się z różnych komponentów, za które odpowiedzialne są różne zespoły. I tu znów, żaden z tych zespołów nie dostarczy gotowej, działającej wersji produktu. Przykładem bardziej biznesowym będzie zespół odpowiedzialny za nową wersję sklepu internetowego. Bez udziału np. osób z marketingu, które wiedzą jak zachować np. spójność całej marki, trudno sobie wyobrazić wdrażanie zmian.

Spod punktu tego wymyka się sytuacja, gdy kilka czy kilkanaście współpracujących ze sobą zespołów – skalując się – są w stanie razem dostarczyć działający produkt. Istotna jest wtedy Definicja Ukończenia, wspólna dla wszystkich zespołów, które razem dostarczają przyrost.

5. Natura pracy nie wymaga współdziałania w zespole

W sytuacji, gdy zadania wykonywane przez członków zespołu mogą być wykonywane całkowicie samodzielnie, bez potrzeby synchronizacji się z pozostałymi osobami, to Scrum także nie ma racji bytu. Ludzie nie będą zaangażowani w działanie zgodne z elementami Scruma, a np. Codzienne Scrumy szybko zamienią się w nudne statusy. Najwięcej wartości z pracy w Scrumie występuje wtedy, kiedy ludzie w zespole współpracują, pomagają sobie, przekazują sobie fragmenty pracy i całościowo pracują na efekt pod tytułem “przyrost produktu”.

Podobnie będzie, gdy praca poszczególnych osób zależy od innych i muszą oni współdziałać, jednak nie są to osoby z jednego zespołu. Dzieje się tak dlatego, że Scrum nie jest metodą zarządzania zespołem kompetencyjnym, np. zespołem analityków, zespołem testerów, zespołem rekrutacji. Scrum musi bazować na zespole, który ze sobą współdziała i osiąga wspólne efekty.

Mówiąc bardziej obrazowo, Scum to jest sport zespołowy. Sporty zespołowe charakteryzują się tym, że pojedynczy, nawet najlepszy zawodnik, nie jest w stanie ponieść całej drużyny. To dobitnie widać w Polskiej reprezentacji w piłce nożnej. 

6. Członkowie zespołu nie mają przestrzeni czasowej na pracę w danym zespole

Jest to szczególnie niebezpieczne w zespołach projektowych, w których członkowie działają równocześnie przy różnych inicjatywach albo jest ich to praca dodatkowa.

Z taką sytuacją spotkaliśmy się akurat poza IT, gdzie Zespoły Scrumowe były powoływane jako coś dodatkowego, poza codziennymi obowiązkami. Członkowie dołączali dobrowolnie do takich inicjatyw i mimo początkowego entuzjazmu i energii wynikającej z nowego sposobu pracy, z czasem ta energia kończyła się. 

Powyższa sytuacja może być dobrym sposobem na sprawdzenie w organizacji czym jest Scrum, jednak najlepsze efekty uzyska się zawsze, jeśli członkowie Zespołu Scrumowego będą dedykowani i sto procent czasu będą wykorzystywać w tym projekcie. 

Scrum wymaga między innymi pewnego konkretnego mechanizmu spotykania się, poświęcenia uwagi na różne rzeczy takie jak: inspekcja, adaptacja procesu, czyli Retrospektywy. W każdym Sprincie trzeba mieć czas na zaplanowanie, regularne Daily Scrumy. Jeśli zespół będzie mógł wygospodarować czas np. tylko na te spotkania to, może nie wystarczyć czasu na pracę. Z kolei, gdy zaczniemy rezygnować z poszczególnych elementów Scruma, aby zyskać więcej czasu, to nie będzie to już wtedy Scrum. 

7. Zespół musi zrobić idealną wersję produktu za pierwszym razem

To sytuacja, w której nie ma miejsca na to, aby iteracyjnie dochodzić do wersji produktu spełniającej nasze oczekiwania. Brak tu przestrzeni czasowej na przebudowywanie wcześniejszych koncepcji i zespół ma tak naprawdę tylko jedną szansę na wykonanie konkretnego przyrostu produktu. Liczba Sprintów jest z góry określona, a każdy Sprint jest od początku dokładnie zaplanowany. 

Do takiej sytuacji może dojść, gdy faktycznie nie możemy sobie pozwolić na wielokrotne poprawianie, np. z uwagi na okrojony budżet lub umowa z partnerem biznesowym na to nie pozwala.

Chcemy tu też zaznaczyć, że wiele zależy od tego, co określimy sobie jako produkt. Można się spotkać z takim stwierdzeniem, że “Scrumem to domu byś nie wybudował”. My jednak podzielimy się z Tobą przykładem, który pokazuje zupełnie odwrotną sytuację. Pomagając zespołowi z biura architektonicznego, chcącemu pracować w Scrumie, ciekawym doświadczeniem było zdefiniowanie, czym jest produkt i co podlega iteracji. Architekci Ci projektowali całe zespoły budynków, np. osiedla czy zespoły biurowców. Wiadomym było, że nie będzie możliwym przesunięcie raz wylanych fundamentów, bo ktoś w kolejnym Sprincie stwierdzi, że światło będzie źle padać na chodnik. Dlatego iteracji podlegał projekt, a nie budynek. Pierwszy przyrost projektu to był luźny szkic. I tak stopniowo rozwijał się on z ogólnego zarysu koncepcji w kompletny projekt budynku ze szczegółowo rozpisanymi ścianami, kablami czy rurami. Proces ten trwał nawet w czasie trwającej budowy. Zespół architektów wielokrotnie poprawiał projekt budynku, a gdy ten projekt jest już w miarę ostateczny, sam budynek, w tych podstawowych kwestiach pozostaje już bez zmiany.

8. Planowanie przedmiotu pracy nie jest możliwe 

Mówimy tu o sytuacji, w której praca zespołu jest losowa, bardzo zmienna, a zespół nie jest w stanie zaplanować tygodniowego Sprintu, bo jutro lub za kilka dni może pojawić się zupełnie coś innego. Tu nie pomoże też regularnie zmieniany Cel Sprintu, gdyż będzie to bardzo frustrujące dla zespołu.

Przykładem jest zespół, który zapewnia bezpieczeństwo organizacji. Bardzo trudno mu tu zaplanować zajmowanie się spływającymi incydentami związanymi z bezpieczeństwem. Zazwyczaj pojawiają się one z różną częstotliwością, z różnym natężeniem i też mają różny priorytet, jeśli chodzi o szybkość interwencji. Podobnie jest z zespołem z help desku, gdzie trudno jest przewidzieć pojawiające się zgłoszenia od klientów. 

9. Firma nie jest gotowa zmieniać się w tych sferach, gdzie jest to niezbędne 

Scrum może powodować, że pewne problemy stają się bardziej widoczne i ma on sens jedynie wtedy, gdy problemy, które wynikną w efekcie pracy zespołu będą zaopiekowane. Nie na wszystko zespół ma pełny wpływ i może sam się nimi zająć. Wiele rzeczy może wymagać wsparcia organizacji lub z zewnątrz, np. gdy pracujemy z klientem zewnętrznym. 

Pracując w Scrumie jest wręcz pewne, że pojawią się czynniki wskazujące, że trzeba wdrożyć pewne zmiany. Jeśli jednak od początku będzie wiadomo, że zmiany mogą zajść wewnątrz zespołu, ale jego otoczenie (management, procesy, cała firma) mają pozostać niezmienne to odradzamy wdrożenie Scruma.

Podsumowując mamy 9 sytuacji, w których Scrum nie jest odpowiedzią i nie powinien być wdrażany:

1. Gdy zespół nie ma jednego wspólnego celu. 
2. Gdy zespół nie rozwiązuje złożonego problemu.
3. Nie ma kandydata na Product Ownera. 
4. Zespół nie jest w stanie samodzielnie dostarczyć działającego produktu.
5. Natura pracy nie wymaga współdziałania w zespole. 
6. Członkowie zespołu nie mają przestrzeni czasowej na pracę w tymże zespole. 
7. Zespół musi zrobić idealną wersję produktu za pierwszym razem.
8. Planowanie przedmiotu pracy nie jest możliwe. 
9. Firma nie zmienia się w tych sferach, gdzie jest niezbędna. 

Już na sam koniec, chcielibyśmy Was zaprosić na nasz Instagram @porzadnyagile, gdzie będziemy publikować merytoryczne i ciekawe fragmenty odcinków. Obserwujcie nas, komentujcie i zadawajcie pytania.

Przypominamy też o naszych kanałach na Twitterze, Linkedinie i Facebooku. Na wszystkich tych kanałach już od kilku odcinków intensywnie działamy publikując infografiki, podsumowania odcinków i skróty wideo. 

Transkrypcja podcastu „Kiedy Scrum nie jest odpowiedzią?”

Kuba: Dzisiejszy odcinek ma tytuł kiedy Scrum nie jest odpowiedzią. Pracujemy z firmami i często proszeni jesteśmy o porady na temat tego jak wystartować zespół, jak dobrać metodę pracy czy framework pracy. Jak pracować zwinnie, ale konkretnie? Nie dziwię się menedżerom, którzy w takiej sytuacji chcą dobrze wybrać. Potrzebują rekomendacji. Zespół potrzebuje doradztwa. Firma też może nie mieć na takim wczesnym etapie dobrego doświadczenia. Tak się składa, że Scrum jest najbardziej popularnym frameworkiem zwinnym, więc siłą rzeczy też wynika z tego pewien automatyzm, że skoro pracujemy zwinnie, to wybierzemy konkretnie framework Scruma. Niekoniecznie Scrum pasuje do wszystkich sytuacji i o tym właśnie będzie ten odcinek. Będziemy rzucać światła na temat tego kiedy naszym zdaniem Scrum nie powinien być stosowany. I nie mamy tu na myśli przypadków złego stosowania Scruma, tylko po prostu obiektywnie czynników czy kryteriów, które powodują, że Scrum po prostu nie jest właściwym rozwiązaniem do danej sytuacji, danego zespołu, danego projektu czy może nawet danej całej firmy. Dobra, przechodząc do rzeczy Jacek. Kiedy Scrum nie jest odpowiedzią?

Jacek: Kiedy zespół nie ma jednego wspólnego celu. To jest taki punkt pierwszy dla nas, który no jest istotny z tego względu, że ten wspólny cel jest takiego pewnego rodzaju fundamentem, pewnym takim spoiwem, taką latarnią morską, kompasem, który wskazuje kierunek i często też sens pracy zespołu. Jeżeli nie jesteśmy w stanie zapewnić takiego wspólnego celu, bo być może tych celów jest wiele albo w ogóle sobie nie zdecydowaliśmy żadnego, to praca w Scrumie może mieć charakter taki bardzo mocno mechaniczny. Pewne wbudowane w Scruma elementy, tak jak na przykład skupienie jako jedna z wartości, no będzie tutaj absolutnie pogwałcona. Na takiej zasadzie no, że nie będzie skupienia nad czymś jednym dużym i poważnym. No tylko tak sobie już dopowiem – każdy będzie robił coś swojego, albo zespół będzie robił coś bez poczucia tak naprawdę jaka jest tego celowość.

Kuba: I możemy mieć do czynienia z przypadkami, gdy nie ma w ogóle celu. Czyli nie ma jednego wspólnego celu, bo go nie ma wcale. I to jest strasznie niebezpieczna sytuacja, ponieważ wtedy cała ta korzystna sytuacja ze Sprintami i dążeniem do pewnego celu, wybranym Celem Sprintu, czyli całym Celem Produktu, to wszystko po prostu nie nastąpi. I tutaj bez tego zerowego kroku ustal jeden wspólny cel dla projektowanego czy startującego, czy przebudowanego Zespołu Scrumowego. To po prostu nie zagra. Tego kroku nie można pominąć. Jak ten krok pominiemy, to dalej będzie właśnie tak, jak mówisz – mechaniczność, czyli to jak my to rozumiemy. Takie spotykanie się dla spotykania, etykiety, pewne przybrane. Teoretycznie wszystko się zgadza, tylko za bardzo nie ma efektu. Scrum nie jest też odpowiedzią w sytuacji, gdy zespół nie rozwiązuje złożonego problemu. Co mamy tu na myśli? Czasami Zespoły Scrumowe powoływane są na bazie istniejących zespołów, które wykonują jakieś czynności, ale te czynności nie są złożonym problemem. Jak mówię złożony problem, to mam na myśli wypuszczenie produktu na rynek po raz pierwszy albo po raz pierwszy tego produktu. To jest jakaś innowacyjna czy kreatywna nowa wersja produktu, próba rozwiązania w nowy sposób czegoś, co do tej pory nie rozwiązywano. Zespół gdy zaczyna, trochę jeszcze nie wie, jak dokładnie to zrobi. Do rozwiązania jest to na poziomie rozwiązania, w sensie technicznie, to jest być może nawet sporo niewiadomych na poziomie biznesowym. Do tego Scrum się świetnie nadaje, ale w odwrotnym przypadku, gdy zespół robi jakieś powtarzalne czynności i to mówię, nie trywializując, bo wiele zespołów w wielu firmach, wiele osób, wielu profesjonalistów, zajmuje się relatywnie prostymi rzeczami. Powtarzalnymi, spocedurozowanymi, trzeba postępować według instrukcji. I w takich sytuacjach tutaj Scrum nie jest adekwatny, ponieważ nie da żadnej wartości dodanej, że w ten sposób pracujemy. 

Jacek: Żeby dać jakiś przykład do tego, co mówi Kuba. Jeżeli wszystko jest przewidywalne, wszystko jest proste, powtarzalne, no to przykładowo przegląd Sprintu no może być spotkaniem takim bardzo czysto formalnym, bądź spotkaniem wręcz statusowym. Bardzo podobnie może wyglądać sytuacja, w przypadku codziennego Scruma, gdzie nie będzie najprawdopodobniej jakiejś wielkiej przestrzeni do adaptacji planu, czy do jakiegoś takiego przegrupowania się, żeby zrobić coś lepiej, szybciej albo w ogóle, żeby zrobić, żeby zareagować na zmieniającą się rzeczywistość. Bo tak naprawdę to ta domena, w której się znajdujemy, jest tak poukładana, że właściwie nie ma co nas zaskoczyć. I uruchamianie całego tego mechanizmu wydarzeń scrumowych czy odpowiedzialności, no po prostu z mojej perspektywy może być zbędnym zarzutem, który nic nie da. Tylko w jakiś sposób tam skonsumuje energię i czas członków zespołu.

 Kuba: I tu może być taka sytuacja podobnie jak z tym jednym celem z poprzedniej części naszego odcinka, że być może zespół nie rozwiązuje złożonego problemu lub nie jest to tak dzisiaj zdefiniowane. Bo pracowałem z pewnym zespołem, który gdy zaczynałem z tym zespołem pracować, on myślał o sobie – naszym zadaniem jest regularne wysyłanie maili do wszystkich pracowników firmy. I to nie był złożony problem, ale jak sobie ten zespół zredefiniował sens funkcjonowania, naszym zadaniem jest to, żeby pracownicy byli dobrze doinformowani i mało tego wiemy, że dotychczasowe wysyłane maile nie za bardzo spełniają ten cel i nie mamy pomysłu, co spełni. To nagle się pojawił złożony problem, tylko trzeba było na niego wpaść. 

Jacek: Trzecim przypadkiem, kiedy Scrum nie jest odpowiedzią, jest sytuacja, w której nie mamy kandydata na Produkt Ownera. I to, co jest istotne w tym punkcie to to, że przede wszystkim chcielibyśmy mieć osobę, która powiedzmy, będzie reprezentantem potrzeb, reprezentantem biznesu, reprezentantem interesariuszy. Bardzo różnie sobie możemy na to spojrzeć. Ale na pewno mam tutaj na myśli osobę, która wie, dlaczego i co. Jeżeli taka osoba nie wyłania się na horyzoncie, no to zapala się nam żółta lampka. Natomiast jeżeli nie mamy dobrego kandydata na horyzoncie, no to zapala się czerwona. W takim sensie, że iluzja posiadania dobrego Product Ownera, czy ogólnie Product Ownera jest kusząca. Natomiast jeżeli to nie jest dobry kandydat, na takiej zasadzie, że ma odpowiednie kompetencje i doświadczenie i wiedzę, żeby pełnić tę rolę, no to bardzo szybko zobaczymy. I tu myślę z Kubą mamy bardzo podobne doświadczenia. To od razu będzie widać w efektach pracy zespołu.

Kuba: Na to co powiedziałeś, ja bym dorzucił, że dla mnie cechą dobrego Product Ownera jest jego decyzyjność. I ta decyzyjność w różnych organizacjach jest w różny sposób uzyskiwana, ale ona bardzo często wiąże się z jakiegoś rodzaju autorytetem lub zaufaniem całej organizacji, która z tego Product Ownera powołuje, którego później decyzję będzie szanowała, będzie jakby tutaj starała się, żeby ten Product Owner już faktycznie miał tę decyzję ze Sprintu na Sprint w ramach istniejącej pracy zespołu. Jeśli nie mamy nikogo w organizacji i teraz mówię tak bardzo z perspektywy zarządzającego, jeśli w mojej organizacji nie ma nikogo, komu bym powierzył taką odpowiedzialność, to po pierwsze – tak w ogóle to jest kłopot, ale po drugie nie ładowałbym się w takiej sytuacji w wykorzystanie frameworka scrumowego. Bo jednak ta odpowiedzialność product ownerska jest na tyle krytyczna, że robienie tego jakoś zastępczo albo spróbowanie Scruma bez Product Ownera, to jest poważne kłopoty. 

Kuba: Czwarta kwestia która, z którą Scrum nie pomoże, to jest sytuacja, w której zespół nie jest w stanie samodzielnie dostarczyć działającej wersji produktu. Zespół Scrumowy jest w pełni odpowiedzialny za ten swój produkt. Im jednak jest potrzebne, żeby tę samodzielność, autonomiczność temu zespołowi zapewnić. Mamy tu na myśli w szczególności tę sytuację, w której w skład zespołu wejdą wszystkie potrzebne kompetencje, wszyscy potrzebni specjaliści, profesjonaliści, którzy są niezbędni do tego, żeby w tym konkretnym produkcie osiągnąć rezultaty. I osiągnąć te rezultaty faktycznie. Czyli ten produkt jest skończony. Ta wersja jest zrobiona. To jest faktycznie działające. Cały ten cały ten poziom filozoficzny, że doprowadzamy nasz produkt na przykład na rynek, na przykład do użytkownika, na przykład do tej grupy odbiorców docelowych, a nie zadowalamy się jakiegoś rodzaju półproduktem czy takim produktem pośrednim.

Jacek: Tutaj przykłady, które przychodzą mi do głowy, jak słucham tego co mówi Kuba, to może być sytuacja, w której przykładowo nasz produkt jest podzielony bardzo mocno komponentowo. Jeżeli mówimy tutaj o produkcie cyfrowym. Jest to sytuacja, w której konkretny zespół odpowiada za jakiś moduł. Na przykład jakiś moduł Core, który powiedzmy jest jakimś tam sercem naszego systemu. No i teraz projekty czy inicjatywy, które płyną ze strony biznesu, najczęściej wymagają zmiany w wielu komponentach, żeby osiągnąć jakąś tam zmianę w naszym produkcie czy w naszym systemie. I teraz, jeżeli zespół tylko w tym swoim poletku może pracować nad tym jednym modułem, no to tak naprawdę to, co powiedziałeś jako coś, co powinno być spełnione – czyli zdolność do samodzielnego dostarczania działającego produktu, no nie będzie miała miejsca. Inny przykład taki może trochę prostszy, ale też częściej spotykany to jest sytuacja, w której zespoły są skonstruowane w taki sposób, że posiadają nie wszystkie kompetencje, które są potrzebne, żeby taki produkt zbudować. Znów przykład taki cyfrowy. Zespół testerów to jest oddzielny zupełnie zespół. Czyli nasz zespół, o którym teraz myślimy po prostu na przykład, ma frontend i backend deweloperów, ale nie ma kompetencji testerskich. No i znów, to jest sytuacja, w której wprawdzie kod zostanie dostarczony i to nawet może będzie działało, no ale tak naprawdę zostanie to przekazane gdzieś dalej do jakiegoś dalszego zespołu. To czego byśmy chcieli, czyli przyrost produktu na koniec Sprintu nie występuje. 

Kuba: Użyłeś dwóch przykładów cyfrowych. Ja dorzucę ze swojego doświadczenia przykład taki bardziej generalny, czy taki bardziej biznesowy. Wyobraźmy sobie, chociażby zespół, który odpowiada za jakiś produkt albo za jakąś usługę – na przykład nową wersję sklepu, do którego klienci w całej Polsce przychodzą. Trudno sobie wyobrazić, że zespół będzie iterował, rozwijał koncepcję czy to jakichś narzędzi, czy jakichś rozwiązań w tym sklepie, bez na przykład osoby z marketingu. Czyli rozwijamy nową technologię w sklepie, mamy jakieś nowe fajne ekrany albo nowe kasy albo jeszcze coś. Ale to nie wygląda, bo nie ma specjalistów od marketingu, więc to nie wygląda jak reszta marki, czy całej całego produktu, z którym działamy. A co w przypadku gdy mówimy o skasowaniu? Bo tutaj część z naszych słuchaczy na pewno bierze udział w takich zespołach, które sami nie są w stanie dostarczyć całego działającego produktu. Tutaj mieliśmy coś na myśli, gdy chwilę temu dyskutowaliśmy o tym w pełni działającym produkcie. 

Jacek: Tak. Jeżeli mamy kilka czy kilkanaście, w zależności od skali współpracujących ze sobą zespołów, które są w stanie dostarczyć działający produkt, no to to jest ten przykład, który wymyka się tutaj spod tego podpunktu. Czyli są w stanie zespoły skalując się dostarczyć coś działającego. No ale oczywiście to odbywa się kosztem jakiejś synchronizacji ustaleń, no chociażby jakiegoś jednego wspólnego punktu, w którym zgadzamy się, że przyrost produktu spełnia Definicję Ukończenia, która jest globalna dla wszystkich zespołów, co zapewnia to, że z perspektywy każdego zespołu wszystkie te elementy, które świadczą o kompletności jakości produktu, no zostały przez zespół zadbane i doprowadzone do takiego stanu, jaki byśmy chcieli. 

Jacek: Kolejnym przypadkiem, kiedy naszym zdaniem Scrum jest odpowiedzią, jest sytuacja kiedy natura pracy, którą wykonuje zespół nie wymaga współdziałania w zespole. I są to przypadki, kiedy zespół, jest bardziej z mojej perspektywy taka jednostka strukturalna zwykle podlegająca pod jakiegoś menadżera. Natomiast to jest właściwie jedyna rzecz, która łączy te osoby. Czyli gdybyśmy sobie spojrzeli na zadania, które wykonują osoby w tym zespole, to są to zadania, które mogłyby wykonywać absolutnie działając solo, nie synchronizując się z pozostałymi osobami. W takiej sytuacji wkładanie ludzi do Scruma i oczekiwanie, że to przyniesie jakieś rezultaty, no niestety jest tylko złudzeniem. Bardzo szybko Codzienne Scrumy zamienią się w nudne statusy. No bo skoro ja robię tylko swoje rzeczy, na przykład zajmuje się rekrutacją na Poznań, a inna osoba zajmuje się rekrutacją na Warszawę, no to to są różne rekrutacje i nie ma miejsca na współpracę. Oczywiście mogłaby się pojawić sytuacja, w której występuje jakaś wymiana wiedzy i tak dalej, ale tego rodzaju korzyści można uzyskać w inny sposób, niż uruchamiając Scruma. Tak więc wierzymy, że najwięcej wartości z pracy w Scrumie występuje wtedy, kiedy ludzie w zespole współpracują, pomagają sobie, przekazują sobie fragmenty pracy. No i jakby całościowo pracują na efekt pod tytułem przyrost produktu.

Kuba: Użyłeś tego przykładu, że efekty osiągnę pracując indywidualnie i nie zależy od kolegów z zespołu, ale to to samo będzie miało miejsce, gdy moja praca zależy od innych osób i muszę współdziałać. Tylko to nie są te osoby z mojego zespołu, tylko z jakiś innych zespołów. Więc tutaj innymi słowy mówiąc wprost – Scrum to nie jest metoda zarządzania zespołem kompetencyjnym. Na przykład zespołem analityków, zespołem testerów, zespołem rekrutacji. Scrum musi być posadowiony na pewnym zespole, który faktycznie ze sobą współdziała, osiąga jakieś efekty. W tym pozytywnym sensie poszczególne osoby zależą od siebie. W pozytywnym sensie – czyli to razem uzyskamy efekt. Jeśli to nie jest spełnione, jeśli taka natura rzeczy, bo tutaj nie mówimy o niczym złym lub dobrym, to jest po prostu obiektywny fakt. On tutaj nie ma żadnych cech takich czy zabarwienia. Jeśli jest jak jest, że jesteśmy obok siebie, możemy się wymienić wiedzą, mamy podobną etykietę w stanowisku albo podobną ścieżkę zawodową. Ale ja i Ty rzadko ze sobą współpracujemy, to nie stworzymy dobrego Zespołu Scrumowego i nie bez powodu to mówię i nie bez powodu tak trochę dobitnie to ująłem, bo regularnie spotykam się z pomysłem, że pierwszy krok czy pierwszy pomysł w organizacji, to powołać Zespół Scrumowy z istniejącej komórki organizacyjnej specjalistów o podobnych kompetencjach. To jest coś innego. Tu nie uzyskamy efektów lub będą to efekty strasznie sztuczne. Może nie ma co marnować energii, może nie ma co też psuć dobrego imienia Scruma taką powiedzmy nie do końca udaną próbą zbudowania takiego zespołu.

Jacek: No zdecydowanie tak domykając tą myśl Kuba uważam, że Scum to jest sport zespołowy. No a sporty zespołowe charakteryzują się tym, że pojedynczy, nawet najlepszy zawodnik i to chyba w piłce to nawet dobrze widać w reprezentacji polskiej, no nie jest w stanie ponieść całej drużyny. No i jednak ta cała współpraca, która następuje, jest kluczowa. 

Kuba: Scrum będzie też odpowiedzią w sytuacji gdy członkowie zespołu nie mają przestrzeni czasowej na pracę w zespole. Długo o tym mówię, ale chodzi o to, że po prostu nie mam czasu, żeby być częścią Zespołu Scrumowego. To jest szczególnie niebezpieczne albo szczególnie często zdarza się w sytuacjach takich bardziej projektowych. Czyli realizuję pewien projekt, być może to jest moja jakaś praca dodatkowa do mojej zwykłej pracy, albo mam więcej niż jeden projekt i toczy się równolegle kilka inicjatyw. Istnieje gdzieś taka granica. Nie umiem nazwać dokładnej liczby albo proporcji procentu czasu, ale na pewno jest gdzieś ten moment, gdy nie ma szansy zadziałać w Scrumie. Jeśli członek zespołu po prostu nie może, czy wszyscy członkowie zespołu w miarę równomiernie nie są w stanie zaangażować się czasowo w tę pracę. 

Jacek: Ja mam takie doświadczenie akurat też spoza IT, gdzie Zespoły Scrumowe były powoływane jako coś takiego dodatkowego. Można powiedzieć taki pewien wolontariat. Nikt nikogo nie zmusza, żeby do tych inicjatyw dołączać. Osoby nakładały sobie pracę w Zespole Scrumowym na regularną pracę. I oczywiście tam było sporo entuzjazmu i energii wynikającej z próbowania nowego sposobu pracy. Natomiast im dłużej ten zespół pracował, tym coraz dobitniej było widać, że ta energia się kończy. Wiele osób na koniec, kiedy ten zespół wykonał to co organizacja zakładała, wiele osób odetchnęło z ulgą – na zasadzie w końcu to się skończyło. No bo dłużej bym tak nie wytrzymał, czy dłużej bym tak nie wytrzymała. Jakby tutaj myślę sobie tak, że z jednej strony jest to sposób na to, żeby sprawdzić w organizacji czym jest Scrum, czym jest zwinność – uruchamiając taką inicjatywę. Więc jakby tutaj są plusy takiego działania. Natomiast myślę sobie, że najlepsze efekty osiągniemy kiedy ludzie faktycznie będą dedykowani i czy może też dobitnie powiem – sto procent swojego czasu pracy będą wykorzystywać w Scrumie. I to też nie jest utopijny przypadek, bo jest wiele organizacji, gdzie po prostu jest się członkiem Zespołu Scrumowego. No natomiast takie podejście, że nie wiem, godzinę w tygodniu będę pracował w Zespole Scrumowym, no to może mieć krótkie nogi

Kuba: I dopowiedzmy sobie jedną prostą rzecz, chociażby Scrum wymaga między innymi pewnego konkretnego mechanizmu spotykania się, poświęcenia uwagi na różne rzeczy takie jak: inspekcja, adaptacja procesu, czyli Retrospektywy. W każdym Sprincie trzeba mieć czas na zaplanowanie, regularne Daily Scrumy. To też jest pewien czas jeśli ten zespół ma plus minus tyle czasu, żeby się tylko spotykać, to może się okazać, że nie ma czasu na pracę. A jeśli z powodu małej ilości czasu na pracę będziemy rezygnować z poszczególnych elementów Scruma, to to też nie będzie wtedy Scrum. Więc tutaj akurat konkretnie ta metoda ma też po prostu minimalny poziom zaangażowania czasowego, w taki powiedziałbym element obsługowy czy administracyjny, związany z pracą zespołu. No i siłą rzeczy tego nie ominiemy lub zaczynamy wtedy bardzo mocno ryzykować, że coś stracimy. I na przykład to nie będzie Scrum albo będzie dużo Scruma, tylko mało czasu na faktyczną pracę. 

Jacek: Scrum nie będzie też odpowiedzią w sytuacji, kiedy zespół musi zrobić idealną wersję produktu za pierwszym razem. Czyli mówimy tu o sytuacji, w której z różnych powodów nie ma przestrzeni na to, żeby iteracyjnie dochodzić do wersji produktu, która spełnia nasze oczekiwania. Nie ma tutaj przestrzeni na ponowne przebudowywanie pewnych koncepcji, tylko jest oczekiwanie, że zrobimy to, że tak powiem potocznie od strzała – czyli właściwie mamy tylko jedną szansę na to, żeby jakiś tam konkretny przyrost produktu wykonać. No i po prostu nie możemy wrócić, żeby przebudować. Nie jesteśmy w stanie wykorzystać tego, co się nauczyliśmy, żeby coś poprawić. No tylko po prostu musimy od A do Z zrobić. Mamy na to dziesięć Sprintów. Każdy Sprint jest dokładnie zaplanowany – w pierwszym to, w drugim to, w piątym to. Tutaj również najprawdopodobniej Scrum może być taką iluzją. Być może narzędziem, które pokazuje jakieś tam, daje trochę większe visibility na progres prac, ale to wszystko. Myślę, że tę taką transparentność można uzyskać taniej, niż uruchamiając całą maszynę scrumową.

 Kuba: Powiedziałeś to Jacek tak dosyć dyplomatycznie, bo widzimy tak naprawdę dwa możliwe przypadki. Jeden przypadek, chyba prostszy obiektywnie – to taki, że po prostu natura rzeczy nie pozwala na wielokrotne poprawianie. A do tego się odniosę może za chwilę, ale mamy też na myśli tę sytuację, w której nie za bardzo możemy sobie na to pozwolić. Co jest oględnym pojęciem, że nie wolno nam, bo jakiś argument. Na przykład nie ma budżetu, jesteśmy tak wyżyłowani, że w zasadzie, jak tylko zaczynamy rozmawiać o tym, że coś, co już zrobiliśmy, jeszcze chcemy poprawić, to takiej wiadomości się nie przyjmuje. Albo podpisaliśmy taką, a nie inną umowę z naszym partnerem biznesowym, że nie mamy żadnego pola manewru i pewnie znajdziemy jeszcze trochę argumentów o na przykład kulturze pracy, albo stylu zarządzania. Winieniu za to, że w ogóle chce się coś zmienić czy poprawić – jeśli którykolwiek z tych elementów ma miejsce. Abstrahując od tego, że akurat w tym miejscu powiem – to strasznie bez sensu, że w organizacji tak właśnie się pracuje. No ale może się okazać, że w takim otoczeniu czy w takim klimacie ten Scrum po prostu nie ma zastosowania. Natomiast powiedziałem o tej naturze rzeczy. To myślę, że to jest ciekawostka. Regularnie spotykam się z takim challenge’m mówiąc po staropolsku, że Scrumem to domu byś nie wybudował. Mam takie przed rokiem doświadczenie bardzo ciekawe, gdy pomagałem zespołowi z biura architektonicznego. Architekci i tacy prawdziwi budujący budynki, nie architekci IT. Osoby, które w zasadzie nawet nie tyle, co budynki, co całe osiedla projektowali, albo jakieś zespoły biurowców, jakieś budynki użyteczności publicznej, kawałki miasta, tak naprawdę. No i Ci architekci wykorzystywali do swojej pracy Scruma. Bardzo ciekawym doświadczeniem było to, żeby sobie zdefiniować, co w takim razie jest produktem i co podlega tej iteracji. No bo wiadomo, że nie będzie raz wylanych fundamentów przesuwało się o metr w lewo, bo ktoś w kolejnym Sprincie stwierdził, że tam mu źle światło pada na chodnik. Więc faktycznie coś, co podlegało iteracji, to projekt. Na początku ten projekt, czy pierwszy przyrost projektu, to był dosłownie jakiś taki luźny szkic i to dosłownie węgielkiem. Jakiś taki totalnie ogólny zarys i to tak stopniowo, stopniowo, bardzo fachowo przychodziło od jakiegoś zarysu, przez koncepcję, przez kolejne jakieś coraz bardziej konkretne kawałki budynku, coraz bardziej wyglądało jak budynek. Cały czas jako projekt budynku, aż w końcu ostatecznie tam każdy jeden kabel, każda jedna ścianka i każda jedna rura w całym budynku też były bardzo szczegółowo rozpisane. Nawet już w czasie trwającej budowy. Więc tutaj wracając do podstawowej idei, wychodząc trochę z tej ciekawostki – zespół architektów wielokrotnie poprawia projekt budynku. Sam budynek, jednak gdy ten projekt jest już w miarę ostateczny, w tych podstawowych kwestiach pozostaje już bez zmiany, ale to nie znaczy, że nie można pracować iteracyjnie i przyrostowo, nawet w takich kwestii jak budowlanka.

Jacek: Ja myślę, że konkluzja tego Kuba, co powiedziałeś, jest taka, że być może wpadamy w pewne pułapki wynikające z naszych wcześniejszych doświadczeń. Na zasadzie u nas w firmie tak nie można, albo tego produktu nie da się tak rozwijać. Natomiast ten przykład, który podałeś pokazuje, że być może możemy być beneficjentami podejścia zwinnego. Kiedy trochę inaczej spojrzymy na naszą pracę i dzielimy sobie obszary, które powiedzmy podlegają pewnym ograniczeniom. No i nie możemy ich przebudowywać, zmieniać modyfikować, ale nadal będziemy w stanie znaleźć obszary, gdzie te takie uczenie się i implementowanie tej nauki w trakcie rozwoju produktu może być wartościowe. 

Kuba: Przedostatnią sytuacją, w której naszym zdaniem Scrum nie jest odpowiedzią, jest sytuacja gdy planowanie przedmiotu pracy nie jest możliwe. I nie mamy na myśli takiego, powiedzmy smutnego przypadku jak w poprzednim przykładzie, tylko po prostu obiektywnie – praca, którą zajmuje się ten zespół, czy ta część firmy,  jest tak na przykład losowa, albo w takim dużym stopniu zmienna, że zespół nie jest w stanie zaplanować tygodniowego Sprintu, bo już kolejnego dnia, albo za dwa dni maks, pojawi się coś zupełnie nowego. I w tej sytuacji nawet Cel Sprintu będzie regularnie przerywany, regularnie zmieniany. To może być strasznie frustrujące dla takiego zespołu, gdy się okazuje, że non stop coś wypada, coś okazuje się być ważniejsze. No i ta taka stałość albo chociaż próba zaplanowania minimalnie nad jakimś zakresem prac, nawet na króciutki termin, po prostu nie jest zbytnio wykonalne. 

Jacek: Dla przykładu myślę, który myślę, że tutaj możemy podać, to jest na przykład sytuacja, w której mamy zespół, który obsługuje czy zapewnia bezpieczeństwo w organizacji. No i trudno zaplanować spływające incydenty związane z bezpieczeństwem. One mogą się pojawiać z różną częstotliwością, mogą być też o różnej skali, wymagać szybszego bądź wolniejszego zareagowania. No i używając Scruma, planując w poniedziałek pracę, ustalając Cel Sprintu – nie jesteśmy w stanie określić co się wydarzy. Inny przykład, to jest sytuacja kiedy na przykład mamy jakąś tam formę help desku, gdzie też nie jesteśmy w stanie przewidzieć, w którą stronę potoczą się zgłoszenia od klientów. Oczywiście tam jakaś pewna korelacja z tym co ostatnio wdrożyliśmy produkcyjne, może występować, no ale jednak myślę, że co do zasady no to klienci nam podyktują czym się będziemy zajmować. Próba ubierania tego w jakąś tam iluzję, bo to chyba tylko tak mogę nazwać – iluzję, że mamy jakiś cel z tym związany. No bo cel rozwiązać dwadzieścia ticketów, w moim rozumieniu, no jest po prostu stratą czasu 

Kuba: Lub cel w tym tygodniu też jesteśmy bezpieczni. 

Jacek: To całkiem powtarzalne. Ostatnia sytuacja, kiedy uważamy, że Scrum jest odpowiedzią, to jest sytuacja, w której firma nie jest gotowa zmieniać się w tych strefach, gdzie jest to niezbędne. Bardzo często można usłyszeć takie zdanie na temat Scuma, że to jest takie narzędzie, które powoduje, że pewne problemy stają się bardziej widoczne i faktycznie podpisałbym się pod tym sformułowaniem. I ma to sens tylko wtedy, jeśli te problemy, które wynikną w wyniku pracy zespołu, a w szczególności w wyniku tego jak zespół podda pod dyskusję, czy pod jakieś tam przemyślenia to, co się wydarzyło w trakcie Sprintu. Co blokowało? Co utrudniało? Co było niewygodne? No to z tymi rzeczami coś musimy zrobić. Na pewne rzeczy zespół ma wpływ pełny. Może to zrobić sam, natomiast wiele rzeczy może albo wymagać wsparcia organizacji, albo może być zupełnie nawet poza organizacją. Na przykład, jeśli pracujemy z klientem zewnętrznym, no to być może na pewne rzeczy pomimo prób i starań, nigdy nie będziemy mieć wpływu. Tak więc, jeżeli diagnozujemy, że widzimy albo historycznie patrzymy i wiemy, że nie ma przestrzeni na to, żeby Scrum nam podpowiadał, co należy zmienić, bo wiemy, że i tak to się nie zmieni. No to ja myślę sobie, tak bardzo empatycznie myśląc, że szkoda rozbudzać nadzieje ludzi i dawać im jakieś takie złudne poczucie, że będzie lepiej.

Kuba: I Ty tak tego nie powiedziałeś, ale ja to dorzucę do Twojej wypowiedzi. Jeśli startując Scruma zakładamy, że zmienić mają się zespoły, a firma, proces,  management, cokolwiek jeszcze, struktury pozostaną całkowicie niezmienne. I to jest warunek konieczny. To z doświadczenia powiem – to nie ma co startować. Bo tak jak mówisz, będzie zmarnowanie okazji. Nie ma szans, żeby Scrum nie pokazał, że zmienić musi się też otoczenie zespołu. Na pewno jest dużo do poprawy w środku zespołu, w produkcie. OK, ale nie wierzę, że się nie pojawią też takie wektory na zewnątrz zespołu. Można długo wymieniać, co to mogłoby być i jeśli w ciemno zakładamy, że i nic z tym nie zrobimy, to nie ma szans, że tutaj cokolwiek pomoże czy cokolwiek zastartuje. Więc jeśli planujemy nic nie zrobić z tym co Scrum pokaże, to też nie próbujemy go zrobić. Tak w ogóle, to nie jest zbytnio rekomendowana przez nas metoda zarządzania, ale to tym bardziej nie czujmy się rozczarowani, że Scrum na poziomie zespołu, ze szklanym sufitem na zmienianie czegokolwiek więcej – to nie ma szans. I coś, co ja też zawsze rekomenduję na takim etapie, bo mówiliśmy tutaj o rekomendacjach dla managementu. To jest też czas, żeby już też początkującemu zespołowi, czy zaczynając całemu zespołowi, wprost powiedzieć o tym, że dostają od nas wsparcie, że mogą przychodzić z jakimiś takimi rzeczami, które są poza ich sferą wpływu. Być może nawet wręcz dać im jakiś rodzaj weksla in blanco albo listu żelaznego. Przychodzi do mnie, liczcie na moje wsparcie. Jestem cały gotowy do tego, żeby wam pomóc. Będę ciągle też do was wracać, żeby zapytać, co jest takiego, co ja mogę zrobić, żeby się wam działo lepiej. I to może być najważniejsza część pracy menedżera w Scrumie. Zespół się samozarządza. Product Owner fajnie wyznacza tutaj priorytety i decyzje. Więc tutaj cała ta sfera zarządzania zespołem znika, ale cała gotowość managementu musi być przesunięta, na to, żeby zmieniać organizację w taki sposób, w jaki pokazuje Scrum, że gdzieś jest coś do poprawy. Podsumowując całą treść tego odcinka – kiedy Scream nie jest odpowiedzią?

Jacek: Gdy zespół nie ma jednego wspólnego celu. 

Kuba: Gdy zespół nie rozwiązuje złożonego problemu.

Jacek: Nie ma kandydata na Product Ownera. 

Kuba: Zespół nie jest w stanie samodzielnie dostarczyć działającego produktu.

Jacek: Natura pracy nie wymaga współdziałania w zespole. 

Kuba: Członkowie zespołu nie mają przestrzeni czasowej na pracę w tymże zespole. 

Jacek: Zespół musi zrobić idealną wersję produktu za pierwszym razem.

 Kuba: Planowanie przedmiotu pracy nie jest możliwe. 

Jacek: Firma nie zmienia się w tych sferach, gdzie jest niezbędna. 

Jacek: Na koniec kilka ogłoszeń, istotnych, więc zostań z nami. Pierwsze ogłoszenie dotyczy naszego Instagrama. Założyliśmy go z Kubą bardzo dawno temu i oprócz loginu na Instagramie to przelatuje tam tylko pustynny krzak i chcemy to zmienić. Tak więc zapraszamy na nasz Instagram, szukajcie nas tam pod nazwą Porządny Agile. Będziemy publikować smakowite kawałki merytoryczne z odcinków. Tak więc zachęcamy, żeby i tam nas polubić, follować, komentować i być z nami.

Kuba: Te smakowite kawałki, o których Jacek mówisz, to jest właśnie inspiracja, żeby jednak Instagram rozkręcić. Tutaj mieliśmy pewne spotkanie z pewnym guru marketingu, który rozwiał nasze złe wyobrażenia, czym jest Instagram. Jednak kłania się to, że sami obaj nie korzystamy z akurat tego medium. Jeśli Ty – Słuchaczu lub Słuchaczko akurat z Instagrama korzystasz, to zapraszamy, a jeśli nie korzystasz, korzystasz z innych mediów, to przypominamy też o naszym Twitterze, naszym Linkedinie, naszym Facebooku. Na wszystkich tych kanałach od kilku odcinków trochę zintensyfikowaliśmy nasze działania. Zamieszczamy też oprócz samej zapowiedzi odcinka, zamieszczamy też infografiki, podsumowania, skróty wideo. Wszystkie takie materiały, które mogą przybliżyć, może przypomnieć, może dać okazję do tego, żeby się jeszcze lepiej zapoznać z tym, o czym nagrywany. Więc w zależności od tego, z jakiego medium społecznościowego korzystasz, zapraszamy Cię do śledzenia, sprawdzania, komentowania, bo sporo więcej zaczyna się dziać na naszych profilach. Oprócz tego na stronie odcinka po kilku dniach od premiery będziemy teraz już regularnie zamieszczać artykuł, który będzie powtórzeniem czy takim jakby dodatkowym nowym ujęciem tych samych treści, które też nagrywamy. Jeśli masz ochotę przeczytać, nie masz czasu przesłuchać całości albo masz ochotę komuś coś podesłać kto mnie słucha podcastów – to na stronie każdego odcinka najpóźniej kilka dni po premierze będzie też pełnokrwisty, pełnoprawny, właściwie napisany artykuł, który też można przeczytać. Te treści będą te same. Czyli jeśli mówimy, kiedy Scrum nie jest odpowiedzią – to również artykuł będzie o tym mówił. Chcemy dotrzeć z tymi treściami również do osób, które niekoniecznie mogą lub chcą słuchać podcastu, czy oglądać nasze wideo na YouTubie. Więc tutaj też, zwłaszcza jeśli jesteś naszym wiernym Słuchaczem lub Słuchaczką i propagujesz nasze treści, to zapraszamy do powrotu na stronę WWW oraz do przesyłania tych treści dalej do innych osób, które mogą skorzystać na naszych treściach.

Jacek: A jeżeli preferujesz kontakt osobisty, to przypominam, że tylko do końca lipca jest jeszcze promocyjna cena na szkolenie Labirynty Scruma, które będę prowadził 9 10 września w Warszawie. Będzie to bardzo praktyczne ujęcie pracy w Scrumie. Wyjdziesz z tego szkolenia z wiedzą, na jakie pułapki i na jakie problemy zwrócić uwagę w Scrumie. No i oczywiście z pełnym wachlarzem możliwych i potencjalnych sposobów, jak sobie z tymi problemami radzić. Tak więc tylko, do końca lipca cena minus 20 procent. Zapisy na stronie labiryntyscruma.pl/szkolenie

Kuba: A wszystkie notatki do tego odcinka, zapis transkrypcji artykułu, który wspomniałem. Link do video link do innych materiałów znajdziesz na stronie porzadnyagile.pl/68

 Jacek: Po tych długich ogłoszeniach możemy powiedzieć, że to było wszystko na dzisiaj dzięki Kuba.

 Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.