#008 – Rola analityka w Agile

Rozmawiamy o roli analityka oraz miejscu analizy w podejściu zwinnym. Dyskutujemy o tym, czy jest to zanikająca kompetencja, czy może nadal konieczny element procesu wytwarzania oprogramowania. Odcinek podsumowujemy dobrymi praktykami zwinnej analizy.

O czym usłyszysz w odcinku?

  • 01:16 – Jaka może być rola analityka w Agile?
  • 02:34 – Co rozumiemy pod pojęciem „analityk”?
  • 05:57 – Jakie są argumenty za zmniejszającą się rolą analityka w Agile?
  • 10:27 – O sytuacjach, gdy w roli analityka nie zmienia się nic.
  • 13:39 – Gdzie znaleźć miejsce dla analityka?
  • 20:36 – W którą stronę zmierza rola analityka?
  • 24:41 – O monopolizowaniu analizy.
  • 39:48 – Co, jeśli analityk nie chce zmienić sposobu pracy?

Zobacz wersję wideo

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować. Jeśli są jakieś problemy, jakie napotykasz w trakcie retro, masz jakąś fajną obserwację albo dobrą praktykę, którą sugerujesz innym Scrum Masterom i Agile Coachom, daj koniecznie znać w komentarzu.

Daj nam znać co sądzisz o samym odcinku:

Transkrypcja odcinka:

Kuba: W dzisiejszym odcinku będziemy poruszać temat analizy biznesowej albo systemowej w podejściu zwinnym. Chcemy zacząć od tego, żeby odpowiedzieć na pytanie, jaka może być rola analityka w Agile. To jest na tyle kontrowersyjne i polaryzujące pytanie, że odpowiemy zarówno na możliwe głosy o tym, że ta rola istnieje i jaka ona jest, jak i na te głosy, że może zanika lub kompletnie przestaje być potrzebna.

W drugiej części odcinka porozmawiamy o tym, jak taka rola analityka czy rola analizy w podejściu zwinnym może nadal funkcjonować, jakie są dobre praktyki, jakie dobre praktyki widzimy z naszego doświadczenia czy z doświadczenia zespołów, z którymi jakoś w bezpośredni sposób współpracowaliśmy. Ale tak jak wspominałem, zaczniemy od pytania: „Jaka może być rola analityka w podejściu zwinnym?”.

Jacek: No, tutaj, myślę, że – tak, jak wspomniałeś – temat jest polaryzujący z tego względu, że myślę, że możemy tutaj rozważyć co najmniej dwie opcje, pomiędzy którymi oczywiście pojawiają się jakieś odcienie szarości. Tak więc z jednej strony – tak bardzo ogólnie rzecz ujmując – ta rola analityka może wyglądać w ten sposób, że po prostu nic się nie zmienia. Analityk tak jak pracował wcześniej – w takim modelu zwykle bliższym modelowi kaskadowemu – po prostu tą analizę wytwarza z dosyć dużym wyprzedzeniem, najczęściej wytwarza ją samodzielnie, często jest to osoba, która nie siedzi z zespołem i to jest takie jakby skrajne podejście, gdzie analiza jest pewnym półproduktem, który jest produkowany, następnie jest przekazywany do Developmentu. Z drugiej strony, taka rola analityka może być rolą, w której analityk jest częścią Zespołu Deweloperskiego, no i myślę, że w takim ujęciu można by było bardziej mówić nawet o tym, że jest osobą, która dostarcza kompetencje całemu zespołowi, a nie tylko rolą, która po prostu wypełnia swój bardzo wąski kawałek odpowiedzialności, no i – na koniec pracy – tą pracę wypycha dalej.

Kuba: Dobra, zanim wejdziemy w takie większe kontrowersje, to może zdefiniujmy też, co rozumiemy pod pojęciem „analityk”, bo – z racji swojego doświadczenia (a zanim byłem związany z Agile’em, byłem też związany z tematem analizy biznesowej, gdzie zarządzałem zespołem, a jeszcze wcześniej sam funkcjonowałem jako analityk biznesowy) – widzę, że te funkcje i te role w różnych organizacjach mogą być różnie rozumiane. To kogo mamy na myśli, mówiąc w tym odcinku o „analityku”?

Jacek: Ja mam na myśli osobę, która zbiera i przygotowuje w jakiejś formie, najczęściej spisanej, wymagania związane z konkretnym produktem – i to może być zarówno taka analiza biznesowa, jak i analiza systemowa.

Kuba: No właśnie, to są dwie najpopularniejsze, najbardziej wyraziste dwie role analityka. Może być taki analityk bardziej biznesowy, bardziej analityk wymagań czy analityk czasem funkcjonalny, że zajmuje się bardziej tą perspektywą czego biznes potrzebuje, jak to spisać, jak to przeanalizować, jak to połączyć, jak to logicznie poukładać. No, jest też taki szczebelek analizy bliżej systemu, bliżej też może Developmentu i jakiejś formy architektury, jak te wymagania, które gdzieś już są zebrane, przełożyć na język systemu, może zamodelować już jakieś procesy, przepływ jakoś przez system – w różnych organizacjach to jest bardzo różnie rozwiązane, no i też, co trzeba podkreślić, to też to, że w różnych firmach w różnym stopniu profesjonalizmu podchodzi się do tej roli. W niektórych firmach analityk to jest taki pracownik najniższego szczebla, taki junior, któremu po prostu na razie daje się do pisania to, co jest do zrobienia w projekcie i tam nie ma wielkiej filozofii, ale nie ma też za bardzo profesjonalnego podejścia. Są też firmy, w których analityka docenia się trochę mocniej, uznaje się też tą istotność tej roli – no i wtedy analityk ma profesjonalne narzędzia, jest mocno przeszkolony, certyfikowany z czy to podejść, czy z technik, być może również zgrupowany w jakiś osobny zespół, zarządzanymi kompetencjami w jakimkolwiek rodzaju analizy – być może ze standardami też organizacyjnymi.

I niezależnie od tego, jak jest analityk jest poukładany, to na pewno kontrowersja pozostaje, że analityk łatwo może się skojarzyć z takim podejściem waterfallowym, takim kaskadowym, że „analiza, projektowanie, Development, testy, wdrożenie”, no i ta analiza tu jest już pierwszym krokiem, czyli niezwykle prosto udowodnić taką filozofię, że ten analityk jest sprzeczny z podejściem zwinnym, bo tutaj tworzy dokumenty, jest jakąś fazą przed Developmentem, a w wielu miejscach „Manifest zwinnego wytwarzania oprogramowania” mówi, że ten analityk nie jest potrzebny. Jakie argumenty za taką zmniejszającą się rolą analityka byś widział?

Jacek: No, przede wszystkim bardzo mocno wierzę w to, żeby to Zespół Deweloperski był jak najbliżej problemu, który stara się rozwiązać, czyli, w zależności od firmy, to może być bliskość do produktu, to może być bliskość do Product Ownera, w ekstremalnych przypadkach to może być bliskość użytkownika, natomiast mocno wierzę w to, że żeby zespół czuł odpowiedzialność za produkt, powinien móc uczestniczyć w różnych fazach budowania tego produktu, nie tylko w tej fazie wytwórczej. No i tutaj taki analityk, który przejmuje z zespołu całą odpowiedzialność za wymagania, wręcz może powiedzieć: słuchajcie, wy się zajmijcie kodowaniem, a ja się zajmę przygotowaniem dobrej analizy, powoduje, że zespół – z mojej perspektywy – odcina się od bardzo ważnego aspektu, jakim jest próba zrozumienia produktu, próba zrozumienia procesów, próba zrozumienia problemu, próba też ugryzienia, co tak naprawdę jest do zrobienia, co jest superistotne, co jest mniej istotne, szukani jakichś płaszczyzn, gdzie możemy te wymagania przeciąć, tak więc, skracając to do jednego zdania, to zespół trochę wchodzi w role takich podwykonawców, gdzie dostają po prostu rozpisaną specyfikację, no i po prostu mają robić. No i uważam, że to niesie za sobą ciężkie implikacje, jeśli chodzi o to, jak dalej ten konkretny zespół rozwija dany produkt.

Kuba: Ta rozpisana specyfikacja, o której wspominasz, jest też mocno negowana zarówno w zasadach, że ponad rozbudowaną dokumentację preferujemy jednak działające oprogramowanie, jak i w zasadach stojących za „Manifestem”, no, jest jednak preferencja do tego, żeby komunikacja przebiegała twarzą w twarz, a nie – to akurat już wspomniane nie jest, ale można to dorozumieć z kontekstu – a nie poprzez przekazywane sobie dokumenty, z którymi nieodłącznie analityk się kojarzy. Że tutaj… Czy tą schematy czy diagramy jakieś, rozpisane dokumenty czy nawet jakieś tabele – jakkolwiek by analityk nie pracował, najczęściej efektem jego pracy są jakieś takie spisane artefakty czy narysowane produkty, które później przekazywane są kolejnym osobom i podlegają interpretacji. No i diabeł tkwi właśnie w tym, że najpierw ktoś coś pomyślał, potem to zapisał – i tu jest możliwy błąd do zrobienia – potem ktoś to czyta i może nie zrozumieć, później też nie złapać intencji i jeden nurt w takim wytwarzaniu oprogramowania idzie w to, żeby dbać o notacje, bardzo szczegółowe dokumenty robić albo gdzieś tam ciągle, ciągle polerować to, jak przekazujemy sobie za pomocą dokumentu informację. Agile w moim odczuciu jednak mówi: „Słuchajcie, a może zróbcie to razem, porozmawiajcie o tym”. I w szczególności nie mówię, że to znaczy brak dokumentacji, ale może oznaczać: „Stwórzmy tą dokumentację w trakcie gdy rozmawiamy. Stwórzmy tą dokumentację w trakcie pracy. Stwórzmy ją taką, która nam pomaga, a nie taką, która opisuje w całości wszystko”, a ku temu, niestety, z praktyki obserwuję, że miewają ciągoty niektórzy analitycy. „Na wszelki wypadek opiszę cały system, wszystkie walidacje, całe procesy, wszystkie odgałęzienia” i się zaczyna robić dokument, którego sztuką jest przeczytać, sztuką jest się w niego wgłębić. I to niezależnie czy mówimy o spisanych prozą wymaganiach biznesowych, spisanych w postaci tabelki, czy wrzucone do Enterprise Architecta jakieś wysublimowane diagramy UML, które z perspektywy metody są poprawne i trener na szkoleniu by pochwalił, że „bezbłędnie”, a jednak odbiorcy tych dokumentów mogą mieć kłopot z nich właściwą interpretacją, no i przez to niestety użyteczność ich może spadać.

Jacek: No i temat jest złożony, bo tak naprawdę to, z czym często się spotykam, to jest taka sytuacja, w której firmy decydują się na pracę w podejściu zwinnym, pojawiają się jakieś iteracje, pojawiają się nawet jakieś produkty, jakieś zespoły, które skupione są w oku tych produktów, natomiast ta zmiana dotyczy, powiedzmy, takiego czystego Developmentu, natomiast rola analityka pozostaje bez zmian, przełożony analityka nadal wymaga tego samego, co wymagał wcześniej, no więc jakby też taka w tym momencie wzbudza się we mnie empatia, na takiej zasadzie, że problem jest systemowy i to nie jest tak, że to ten analityk, jeden czy drugi, czegoś nie zrozumieli, tylko po prostu najwyraźniej zarządzaniem zmianą nie poszło tak szeroko i tak holistycznie, jak powinno, jeżeli faktycznie chcemy uzyskać jakąś faktyczną zmianę, usprawnić podejście, w jakim wytwarzamy produkty.

Kuba: Zwłaszcza to jest możliwe w tym modelu, o którym mówisz, że podejście zwinne usadowiliśmy wewnątrz większego procesu, który jednak ma charakter kaskadowy i np. Development zwinnie, a analityk jest poza tą zwinnością, poza tym „nawiasem”, no i przy założeniu chęci skrytykowania, no to w zasadzie w ciemno można powiedzieć, że w takim systemie ten analityk jest na z góry przegranej pozycji, no bo bez problemu udowodnimy, że ci, przykładowo, programiści w tym modelu zawężonym, chętnie dogadywaliby się bezpośrednio z biznesem, kompletnie z pominięciem analityka lub w niektórych organizacjach to bardziej będzie widoczne w postaci tego, że podwójnie wykonujemy pewne czynności – najpierw analityk tworzy dokumentację, w jakiejkolwiek formie, a potem de facto ta dokumentacja do niczego się nie przysłuży, bo programiści czy testerzy razem w zespole odtwarzają podobny proces, bezpośrednio wypytując interesariuszy czy Product Ownera o to, jak dokładnie powinno funkcjonować to coś, co chcemy zrobić i nie zaglądamy w dokumentację, albo konfliktujemy się bardzo mocno na tym polu, gdy analityk wkurzony, że już ma to wykonane i jest to na stronie 153 dokumentacji, odkrywa taką suchą czy smutną codzienność, że nie przeczytali i nie zrozumieli albo zapomnieli, że jest lub nie przeczytali najnowszej wersji w najnowszej zmianie. No i to wraca do tego, że niezwykle prosto krytykować rolę analityka w podejściu zwinnym i udowadniać, że ta rola kompletnie nie jest potrzebna. Faktycznie warto wziąć pod uwagę tą empatię na to, że może jest tak, że sama zmiana tutaj wewnątrz organizacji następuje jakoś inaczej i ta potrzeba funkcjonowania jednak jakaś jest.

To może, jak jest jakaś, to gdzie widzisz miejsce, jeśli gdzieś widzisz?

Jacek: Jasne. Idąc od tych przykładów, które daliśmy, jak to może zostać zrealizowane w niewłaściwy sposób, no to po drugiej stronie tej osi, no, również potrafią czekać na nas niespodzianki, czyli taka przerysowana sytuacja, w której ktoś mówi: „Pracujemy zwinnie, tutaj nie ma miejsca na analizę, nie ma miejsca na analityka”, no i okazuje się, że po prostu praca jest wykonywana tak na zasadzie: „Robimy!”. Robimy, nie analizujemy, nie patrzymy na produkt, nie dociekamy, tylko po prostu praca się dzieje w taki sposób – ja bym to trochę powiedział – nieprzemyślany, trochę na żywioł. No i niestety takie podejście zwykle kończy się tym, że to, co zespół wytwarza, najczęściej nie odpowiada na potrzeby, bardzo często teamy wpadają w pułapkę, że myślą, że jakiś proces działa w jakiś sposób, okazuje się, że na superzłożony proces spojrzeli z takiej bardzo ogólnej perspektywy, no i coś, co im się wydawało proste, okazuje się nagle czymś bardzo złożonym, skomplikowanym i czasochłonnym. Tak więc to skrajne podejście, że „Nie ma analizy w podejściu zwinnym”, no to tutaj byłbym bardzo ostrożny, no bo bardzo łatwo wpaść w pułapkę, w której nie analizujemy, ale jak nie analizujemy, no to w sumie skąd wiemy, co jest do zrobienia? Jak dociekamy do tego, co tak naprawdę powinniśmy stworzyć?

Kuba: No, też takim w miarę pewniakiem, moim zdaniem, z sąsiedniej pozycji do tego, co mówisz, będą organizacje, w których też ta dokumentacja jednak jest potrzebna. Nie dajemy się zgubić nadinterpretacji „Manifestu zwinnego wytwarzania oprogramowania” – tam nie jest napisane: „Zakaz dokumentacji”. Tam nie jest napisane, że nie wolno nic spisać, nie wolno ani spisać nic przed Developmentem, ani w trakcie, ani po. I tutaj może się okazać, że w niejednej organizacji to jest kupę roboty i to dla niejednej osoby, żeby jednak to jakoś sformułować, spisać, zapamiętać w postaci takiej lepszej niż: „No, będziemy pamiętać” albo: „W Jirze zapisaliśmy w komentarzu, jak to zrobimy”. No i wtedy się może okazać, że są tutaj aktywności analityczne do wypełnienia i w dodatku dobrze byłoby je robić kompetentnie. I siłą rzeczy lądujemy w świecie, w którym ten analityk ma sporo do pracy, a niejednokrotnie w niejednym momencie będzie wręcz potrzebował wsparcia innych członków zespołu, żeby się wyrobić z robotą.

Jacek: Inny przykład, który mi przychodzi do głowy, konsekwencji braku kogoś, kto jest w stanie dostarczyć kompetencje analityczne w zespole, jest sytuacja, w której zespół – tak, mówiąc metaforycznie – „odlatuje”. W sensie: skupiają się bardziej na aspekcie technicznym, trochę zapominają o użytkowniku, trochę zapominają o ograniczeniach. Sprinty są bardzo fajne, bo sobie testujemy nowe technologie, nowe frameworki, wszystkie te najbardziej „seksowne” pojęcia z branży, no to to my właśnie w nich moczmy swoje ręce, natomiast jeszcze weźmy sobie, że… sytuację, w której Product Owner w tym zespole jest powiedzmy trochę bardziej od tego teamu oddalony, to brak takiej osoby, która jednak ma takie spojrzenie probiznesowe, stara się zrozumieć, co jest do zrobienia, rozumie, że funkcjonuje pojęcie interesariuszy itd. No to może się okazać, że taki zespół po prostu sobie coś tam robi, ale kiedy przyjdzie momenty, gdy ktoś z managementu powie: „Sprawdzam!”, to może się okazać, że mamy piękną architekturę, wszystko świetnie zrobione technicznie, ale kompletnie nie rozwiązujemy problemów biznesowych, albo – co gorsze – ten fundament techniczny, który przygotowaliśmy, on nie będzie w stanie sprostać logice biznesowej, która powinna być dostarczona.

Kuba: Jak jesteśmy w tym temacie przydatności analityka czy wypełniania roli analityka w zespole, ja bym też dołożył ten aspekt takiej zmiany w czasie – o tym już zasygnalizowałeś, że zmiana jest systemowa – to ja bym dołożył też ten aspekt tego, że niejednokrotnie w zespołach spotykam to, że ty mówisz o postawie czy takiej pro-biznesowej czy „pamiętaniu o użytkowniku”. Ja bym też dołożył to, że bardzo często analitycy są osobami na tyle doświadczonymi w danej organizacji, że pamiętają mnóstwo projektów, znają produkt na wylot, znają tę właśnie złożoność procesów, o której wspominałeś na samym początku tej części – że tutaj my radośnie sobie kodujemy, a się nagle okazuje, że ten analityk pamiętał, że dwa lata temu robiliśmy projekt RODO, a w zeszłym roku robiliśmy split payment i tutaj są jednak niuanse, o których lepiej byłoby zapamiętać, bo się możemy nad tym ciężko wyłożyć. Analityk często też będzie miał trochę inne kontakty wewnątrzfirmowe – w tym sensie, że być może dobre wejścia w dziale prawnym, dobre wejścia w jakimś zespole compliance – w zależności od tego, czym się zajmujemy w naszej organizacji – to może się okazać, że tak, jak deweloperzy między sobą, między zespołami, prawdopodobnie całkiem nieźle się dogadają, to analityk może być takim naszym wewnętrznym fajnym kontaktem do niektórych innych zespołów, innych zespołów wytwórczych, w których też jest jakiś inny analityk albo takich innych zespołów, które formułują pewne wymagania i to te wymagania, których akurat pominąć w żaden sposób nie możemy – jak jakieś właśnie wymogi prawne, jakieś wymogi takie biznesowe krytyczne dla nas biznesowo. No i tutaj fajnie jest, jeśli analityk jakkolwiek pełni swoją rolę, jeśli chodzi o wykonywaną pracę to też wnosi do zespołu po prostu swoje doświadczenie, swoją historię poprzednich projektów i pewną pulę kontaktów, która może być wykorzystana w kolejnych Sprintach czy przy przygotowaniu kolejnych przyrostów.

Jacek: Czyli powiedzieliśmy sobie dotychczas o takich sytuacjach, jakby, czego byśmy nie chcieli, jakiego podejścia analitycznego i jak funkcjonującej roli analityka nie chcielibyśmy w podejściu zwinnym. Z drugiej strony powiedzieliśmy o aspektach, które wskazują na to, że to nie jest do końca tak, że zespoły kompletnie nie robią analizy, nie ma dokumentacji – wszystko to, co powiedziałeś z tymi nawiązaniami do „Manifestu Agile”. Brzmi mi to tak, jakby ta rola analityka w pewien sposób zmieniała się i chciałbym cię zapytać, w którą stronę – z twojej perspektywy – to zmierza?

Kuba: Ja na to mam taką krótką odpowiedź, że potrzebne są kompetencje i potrzebne są aktywności analityczne w podejściu zwinnym. One są potrzebne i one mogą, ale nie muszą, być zrealizowane przez osobną osobę – to pewnie źle brzmi – ale przez wyspecjalizowanego członka zespołu. Choć w wielu organizacjach to będzie najlepsze, co można zrobić, żeby mieć tą kompetencje w zespole, poprzez specjalistę, który wypełnia te zadania. Czyli, rozszerzając ten wątek, potrzebne są kompetencje analityczne wewnątrz zespołu i te kompetencje może wnosić do zespołu analityk. A jak ich nie ma, to to może być wręcz problem i trzeba zadbać o to tak systemowo, żeby te kompetencje zostały rozwinięte. I z drugiej tej perspektywy – zespół nie może zapomnieć, że wykonuje aktywności analityczne, ale te aktywności analityczne podlegają zmianie. Ich charakter przede wszystkim, horyzont czasowy, z jednej strony intensywność, z drugiej strony czasochłonność – mogą się mocno przebudować, bo jednak przechodzimy w tryb pracy iteracyjnej i ta analiza będzie wykonywana mniejszymi porcjami. Ja zakładam też, że całym zespołem, w których taki kompetentny analityk – czy to z etatu czy po prostu ktoś z zespołu, kto te kompetencje ma trochę lepsze – można powiedzieć, że tak trochę niesie cały zespół, mentoruje cały zespół w tym, żeby wykonywać te działania lepiej, żeby zadawać sobie niektóre pytania, żeby zapisywać niektóre rzeczy, które są dla nas kluczowe.

Czyli potrzebne są kompetencje i potrzebne są aktywności, niekoniecznie potrzebny jest zawodowy dedykowany do tego członek zespołu, jeśli w danym kontekście w danej sytuacji nie ma takiej potrzeby.

Jacek: Ja myślę że cała sztuka tutaj, to jest bardzo delikatny temat. Cała sztuka polega na tym, jak konkretny analityk będzie się zachowywał w konkretnym zespole. I tu znów trochę wracamy do tej rozmowy o tym podejściu systemowym, bo z jednej strony wyobrażam sobie sytuację i sięgam pamięcią, myślę że doświadczyłem takich rzadko ale jednak takich momentów, gdzie analityk wchodzi do zespołu pracującego zwinnie, bardzo świadomy, że ta rola ulega zmianie i staje się trochę takim mentorem, trochę osobą, która zadaje trafne pytania. Trochę osobą, która wchodzi w rolę adwokata diabła, jeśli chodzi o jakąś tam pewność zespołu co do pewnych rozwiązań. To wskazuje na taką pewnego rodzaju dojrzałości i też odwagę, na zasadzie: „Oddaję swoje kompetencje, swoją wiedzę zespołowi, nie boję się tego, że ten zespół będzie potrafił taką analizę za jakiś czas przeprowadzić, być może beze mnie”, bo uważam, że tak jak z każdą rolą, tak i tutaj, jeżeli ktoś potrafi pracować w ten sposób, w sposób taki mentorski, z taką trochę szerszą perspektywą, to myślę że dla takiej osoby zawsze w zespole znajdzie się miejsce. Tak więc, gdybym miał wskazywać kierunek jak ta rola mogłaby ewoluować w podejściu zwinnym, to bym powiedział, że to jest bardziej taka osoba, która w świadomy sposób dzieli się dobrymi praktykami i uczy zespoły, które często po prostu nie mają żadnych podstaw, jeśli chodzi o analizę, tego, jak powinny to robić. Przy czym, z mojej perspektywy bardzo ważne jest to, żeby ta osoba nie robiła tego za zespół. W sensie, to uważam za taką pułapkę, no bo to powoduje, że nie zmienia się nic. W sensie, dalej jedna osoba odpowiada za analizę, no a z mojej perspektywy nie do tego stanu dążymy.

Kuba: Tak. Bardzo niebezpieczne jest takie monopolizowanie tej analizy lub stawianie się pomiędzy czy to interesariuszami, czy tymi, którzy formułują wymagania. I tutaj analityk może być świetnym moderatorem, tak to nazwę, w tym sensie, że niejeden Scrum Master mógłby fajnie skorzystać z umiejętności analityka, jeśli chodzi o taką organizację warsztatu. Czy to będzie Refinement, czy to będzie jakaś praca w pierwszych dniach Sprintu nad jakimś tam doprecyzowaniem, formułowaniem tego w największych szczegółach, co jest do zrobienia. Może się okazać, że to jest świetny czas, żeby osoba z kompetencjami analitycznym się wykazała, żeby poprowadziła trochę zespół na zasadzie wyłaniającego się przywództwa, a nie na zasadzie: „Słuchajcie ja tutaj na wizytówkę mam analityk, więc ja wam teraz będę mówić, co macie robić” albo: „Czekajcie aż ja skończę i dopiero wtedy będziecie mogli podjąć ode mnie dokumenty”. Więc tutaj łatwo, może tak trochę przez ekstrema pokazać, czego nie robić. Pewnie to będzie o wiele bardziej wysublimowane i bardziej delikatne, jak to robić i myślę, że to jest taka praca dla analityka w budowaniu swojej odwagi w tym, żeby zaprosić do swoich aktywności wszystkich członków zespołu, wyjaśniać im, na czym to polega, pokazywać dobre wzorce swojej pracy i tak trochę uczyć pozostałych, jak można to wykonać. Dla Product Ownera to też żeby zostawić miejsce dla takiej osoby, bo tam czasami wtedy jest punkt styku między analitykiem a Product Ownerem i taka trochę też dyskusja, że te rolę na siebie na tyle zachodzą, że analityk może być odbierany jako ktoś, kto wchodzi w kompetencje Product Ownera, bo zadaje pytania, może tak nawet właśnie w ramach swojego warsztatu analitycznego, trochę kwestionuje pewne informacje, które Product Owner przynosi. No i tu odwaga wymagana będzie po obu stronach, żeby analityk i później pewnie cały zespół umiał zadawać pytania takie kwestionujące, żeby złapać istotę rzeczy, być może dopracować się czegoś jeszcze lepszego. No a właściciel produktu, żeby czasem nie pomyślał, że jesteśmy tutaj anty-zespół, przeciwko Product Ownerowi, pod wodzą analityka, który zadaje trudne pytania, na które nie zawsze jest odpowiedź. No i z tej trzeciej perspektywy Scrum Master – tutaj też fajnie, żeby sobie tą rolę wzajemnie poukładać. Analityk może, jeśli ma ten warsztat, warsztat zarówno moderacyjny, facylitacyjny, zadawania pytań, drążenia, wgłębiania się w pewne rzeczy, jak i pewnego układania wniosków w postaci czy to jakiejś wizualizacji, czy wspólnego budowania pewnych schematów, notowania pewnych ustaleń – to może się okazać, że tutaj ten analityk weźmie mikrofon czy bardziej wizualnie, weźmie marker do ręki i po prostu zacznie pisać i się też może okazać że ten Scrum Master. Jeśli sobie tego nie dogadamy, jeśli sobie tego zespołowo nie ustalimy, to znowu może sobie zacząć budować poczucie zagrożenia „A nie, no to tak dobrze poprowadzone przez analityka spotkanie, że tutaj dla mnie już nic nie ma więcej do zrobienia”.

Więc – jak w wielu innych miejscach w Scrumie – to jest świetny temat na Retrospektywę, na pogadanie sobie, na podejmowanie małych kroków w stronę usprawnienia tej relacji. Być może to jest akurat na tyle delikatny temat, tak jak to zarysowałem, żeby też troszkę popracować sobie jeden na jeden. Pogadać sobie, Scrum Masters z analitykiem, analityk z właścicielem produktu. Być może też analityk wewnątrz zespołu wytwórczego, jak my się tutaj wzajemnie rozumiemy, co jest przydatne w tym, co my robimy, co nam pomaga, a co niekoniecznie jest przydatne i trochę przeszkadza albo nie jest potrzebne w ogóle. Świetny temat na pogłębioną Retrospektywę – najlepiej od razu zaznaczmy – bez tezy, że właśnie ta niebezpieczna teza jak trochę prowokowaliśmy na samym początku odcinka, że: „No, tutaj analityk jest niepotrzebny”, albo nie widzimy tej roli, albo krytykowanie analityka przez perspektywę oczekiwań, które względem tego analityka ma po prostu układ, który jak już funkcjonuje od jakiegoś czasu w firmie.

Jacek: Wspomniałeś o tym, że analityk może… a raczej, jego narzędziem jest wizualizacja na przykład. Ja myślę, że, idąc dalej, nie wiem, takie techniki, jak powiedzmy story mapping czy impact mapping, to są na pewno takie dwie pierwsze z brzegu, które mi przychodzą do głowy techniki. Że spodziewałbym się po takim, nazwijmy to, zwinnym analityku, że będzie w stanie ich używać i ta wartość, która moim zdaniem płynie też z roli analityka w takiej uzwinnionej formie, to jest takie kwestionowanie zasadności, dlaczego pewne rzeczy robimy, też poszukiwanie celu, dlaczego pewne rzeczy robimy. Czyli tak powiedziałbym, takie wyjście na taki prawdziwie biznesowy poziom, a nie tylko takie słuchanie, co mówią stakeholderzy i takie bardzo literalnie traktowanie słowa „wymagania”. Skoro ktoś mi przekazuje wymagania, no to ja te wymagania traktuję, że to ja je muszę zrobić, bo ktoś wymaga. Uważam, że to słowo jest takie bardzo niebezpieczne, ale też bardzo często widzę, że te wymagania są traktowane, że po prostu robimy, bo ktoś kazał. Natomiast widzę tutaj niesamowitą przestrzeń, w szczególności tak jak mówiłeś, często to są osoby takie bardziej o dłuższym stażu pracy, często z racji swojej pozycji mogły mieć kontakt z top managementem firmy, więc stąd też wydaje mi się że mogą mieć w sobie więcej odwagi, żeby pewne rzeczy zakwestionować, żeby o pewne rzeczy zapytać w taki sposób, żeby to nie było odebrane jako takie jakieś bezczelne pytanie. Tak więc paradoksalnie myślę, że tak – bo rozmawialiśmy o tym takim skrajnym analityka, który produkuje papier i nic z tego nie wynika – z drugiej strony patrząc, osoba o takich kompetencjach, myślę, że może być takim strażnikiem wartości i tego żebyśmy faktycznie szukali tego, dlaczego pewne rzeczy robimy, ale też myśląc o tym, jak to robimy, żeby myśleć w taki sposób bardzo iteracyjny: zróbmy superprostą wersję rozwiązania, wdróżmy ją, przetestujemy, zwalidujmy i dopiero potem idźmy dalej.

Kuba: To, co mówisz, właśnie te superproste wersje, to jest coś, co może być pułapką albo pewną trudnością dla niejednego analityka, zwłaszcza takich osób, które wcześniej doświadczały pracy w sposób tradycyjny, gdzie po prostu spisywaliśmy cały zakres, próbowaliśmy przewidzieć wszystkie potrzebne niuanse corner case’y, na wszelki wypadek lepiej trochę więcej, no bo każde cofnięcie się w fazach gdy w Developmencie albo, nie daj Boże, w testach albo po wdrożeniu, odkrywamy, że analiza czegoś nie przewidziała, no to to był błąd. 

Akurat w podejściu zwinnym, o ile nadal uważam, że dobrą wizję pewnej całości też dobrze mieć i broń Boże nie sugeruję, żeby lecieć bez absolutnie żadnego planu i bez żadnej wizji, tak akurat fajnie, jeśli analityk umie w sobie opanować tą potrzebę i umie też cały zespół poprowadzić z tą perspektywą, że: „Słuchajcie, to teraz wybierzmy sobie tą esencję, to jądro, to, co jest najważniejsze w tym, co biznes potrzebuje, co najbardziej boli użytkowników albo co będzie naszą największą przewagą” – w zależności od tego, jaki produkt realizujemy i na jakim etapie życia ten produkt jest. Ale wybierzmy to coś, co jest najważniejsze. To jest rola Product Ownera, żeby takie priorytetyzacje nadawać, ale akurat analityk może ze swoją kompetencją analizy, literalnie to traktując, czyli rozebrania elementów na części pierwsze oraz bym dołożył też umiejętność syntezy czyli dobrania spośród całej dostępnej informacji tego, co jest ważne – i można to zrobić – tą syntezę można zrobić poprzez jakąś wizualizację, jakieś poukładanie – czy to będzie jakiś rysunek czy rozłożenie Backlogu w jakiś ciekawy, cwany i taki unikalny dla naszego produktu sposób i w efekcie ten analityk może przemoderować cały zespół właśnie przez story mapping, czy jakieś rozłożenie czegoś na jakiejś macierzy i wzajemna pomoc taka cało-zespołowa praca nad tym, żeby wybrać to, co jest tym MVP, tym czymś, co chcemy przetestować, może sformułowanie hipotezy i rozpoczęcie tej pracy w tę stronę. I tutaj Product Owner, który ma analityka, który jest partnerem w takiej sytuacji i że właśnie pomaga przemoderować zespół od tej strony, ma świetne wsparcie. Scrum Master ma świetne wsparcie. Ta osoba też w tej roli będzie się czuła bardzo spełniona, jeśli będzie miała poczucie, że bardzo pomaga całemu zespołowi uzyskać dobre efekty. I to jest też jedna z obietnic podejścia zwinnego, że wykonujemy wartościowe produkty często wcześniej – to nie jest praca, że o wiele więcej kodu wykonujemy, tylko to co wykonujemy, ma po prostu o wiele wyższą wartość. I tutaj wracając do tej tej koncepcji, fajnie jeśli analityk przepracowane ma w sobie, że nie musimy mieć całego zakresu, całego rozpoznania – mamy to rozpoznanie na poziomie wystarczająco dobrym, wystarczająco takim… szybko zrealizowanym ogólnym i przechodzimy do realizacji bo podejście zwinne zachęca nas do tego, żeby tutaj trochę eksplorować poprzez kolejne prototypy, kolejne eksperymenty, kolejne mniejsze wersje, dostarczać rozwiązanie do użytkowników, do klientów, do odbiorców, do interesariuszy i na bazie feedbacku rozbudowywać rozwiązanie jeszcze lepsze, a nie coś, co czasami niektóre zespoły zwinne mogą mieć, czyli takie: „Okej, pracujemy zwinnie, ale tak naprawdę wiemy dobrze, jaki zakres mamy zrealizować”. I to niestety jest złudzenie. To jest takie oszukiwanie się, ale w tym oszukiwania się niestety pomaga, że możemy nie mieć takich kompetencji. Nikt nie zadaje nam trudnych pytań i też firma trochę na razie nie umie tego wykorzystać, więc interesariusze nas nie zachęcam do myślenia w ten sposób, management nas nie będzie inspirował. Może Scrum Master na razie też nie mają wystarczająco dużo odwagi, żeby to proponować albo w ogóle na razie tego nie dostrzegają. Więc tutaj analityk może być też osobą, która przeprowadzi cały zespół przez taką perspektywę, zdekomponujmy ten gigantyczny zakres, który nam się wydaje, że jest przed nami na mniejsze fragmenty, dobierzmy w przekonujący nas samych oraz interesariuszy  sposób te mniejsze kawałki i zaryzykujmy wdrażanie tych mniejszych kawałków, wprowadzanie ich na rynek, wprowadzanie czy oddawanie ich do użytku naszym klientom. I skupmy się na tym żeby konsekwentnie usprawniać to, co robimy, wyciągać wnioski polepszyć to, a nie dać się zapędzić w złudzenie kompletnego, dobrego pełnego wyczerpującego zakresu, bo są limity tego i te limity akurat tworzą dosyć mocne historie, które później są dowodem na to, że potrzebne jest podejście zwinne, bo waterfall nie działa, bo robimy gigantyczne, wielomiliardowe projekty trwające wiele lat, bo ktoś gdzieś na początku sobie stwierdził: „My już wiemy co chcemy. Doskonale jesteśmy w stanie spisać cały zakres, tylko, że on jest duży, ale wystarczająco dużo, ciężko nad tym pracujemy i na pewno wszystko przewidzimy, spiszemy, zapiszemy.

Jacek: No dobrze, powiedzieliśmy dosyć dużo też o takich udanych historiach, o tym, jak mogłaby wyglądać analiza i jej wykonywanie w podejściu zwinnym. Natomiast co w sytuacji, kiedy mamy analityka w firmie czy w zespole, firma wchodzi na ścieżkę usprawniania, uzwinniania sposobu pracy, natomiast analityk pozostaje nadal osobą, która bardzo mocno wierzy w papierową dokumentację, w rozpisanie wszystkiego na bardzo długo w przód. Jak, twoim zdaniem, jak taka osoba odnajduje się w tak zwinnym środowisku?

Kuba: No, to odnajduje się lub się nie odnajduje. Na tak zadane pytanie można odpowiedzieć zero-jedynkowo. Może się odnaleźć w tym sensie, że jeśli ma wsparcie w tym żeby absolutnie nic nie zmieniać, to będzie twardo się trzymać swoich pozycji – w niejednej firmie pewnie tak to wygląda, że Agile Agilem, a analiza analizą, „My tu mamy swoje diagramy, swoje schematy, swoje dokumenty i nie podskoczycie nam” – i to jest konfrontacyjne, to jest często czasem takie trochę wręcz obstrukcja do toczącego się jakiegoś nurtu uzwinniania organizacji. Niektóre branże, a sam też w takich pracowałem, mogą mieć wzmocnienie takich postaw poprzez jednak oczekiwanie zdokumentowania, wykazania się przed audytem, bo może się okazać, że zostają takie wyspy braku zmiany i wtedy mamy problem, ale zaraz podrążymy.

A ja wierzę też, że niejedna osoba potrzebuje po prostu czasu, czyli na początku się będzie czuła zagubiona, zdziwiona. Będzie tu trochę takiego teatru na zewnątrz, a w środku burza i pewnie wewnątrz zespołu zrobiłbym sporo, żeby się wzajemnie dograć, porozmawiać może jeden na jeden niekoniecznie „grillować” taką osobę czy atakować ją publicznie na Retrospektywie, bo może się to akurat tutaj okazać nieskutecznym. Więc ja myślę, że tutaj dla osoby, która daje jakiś opór, no to to jest rola dla Scrum Mastera, akurat ewidentny przykład na wypełnienie tej funkcji Scrum Mastera w postaci edukowania, wyjaśniania, no, trochę przepilotowania przez to jak by to mogło wyglądać. I czasami ten Scrum Master możliwe, że musi odrobić trochę swoje własne zadanie domowe, zrozumieć, na czym praca analityka polega, zrozumieć po co te niektóre działania są wykonywane i być może poszukać wzorców, jak mogłoby to wyglądać inaczej – wzorców w innych zespołach, bo często analityk wiąże się z dużymi organizacjami wewnątrz których jest wiele zespołów i może się okazać, że dosłownie za rogiem albo na innym piętrze ten temat współpracy analityka z zespołem już został trochę rozwiązany inaczej i wcale nie trzeba szukać gotowych rozwiązań na rynku czy gdzieś tam najlepszych wzorców w innych firmach, bo być może już na innym piętrze sobie ten temat po i zarówno analityk sam tego innego zespołu, jak Scrum Master z innego zespołu czy deweloperzy, mogą spokojnie po prostu opowiedzieć, jak sobie oni to poukładali i rozwiązuje się temat poprzez przykłady z tego samego środowiska, z dosyć podobnej domeny czy dziedziny.

Jacek: Ja myślę, że jak ktoś nie wyobraża sobie zmiany sposobu, w jaki pracuje, to myślę, że warto to też powiedzieć głośno, nadal dostępnym w puli rozwiązaniem jest po prostu zmiana pracodawcy. Na rynku jest bardzo dużo firm, gdzie po prostu model pracy analityka funkcjonuje w formie niezmienionej od wielu lat i myślę, że po prostu są firmy, które naprawdę będą szczęśliwe, gdy dołączy do nich osoba, która po prostu chce te dokumenty produkować i schodzić bardzo nisko poziomowo, w sensie realizować fazę analizy. Jest masa firm, które które nadal w ten sposób pracują i po prostu te firmy potrzebują takich kompetencji i tak, jak mówiłeś, wyobrażam sobie że taka rozmowa Scrum Mastera z analitykiem może być ciężka. Z moich obserwacji też widzę, że często Scrum Masterzy unikają takiej konfrontacji. I tu znów wraca to, że to analitycy często są osobami doświadczonymi. Tak więc, ta dyskusja, to nie jest takie, że przyjdzie Scrum Master, pomacha „Manifestem Agile” czy jakimś innym „Scrum Guide’em” i nagle w  analityku zadzieje się przemiana, więc uważam, że to jest trudna dyskusja. Faktycznie myślę tutaj, należy mieć przygotowane silne argumenty. Natomiast, z drugiej strony, mam przed oczami historie pozornie pięknego Scruma, trwa Refinement, wszyscy czekają w milczeniu, wchodzi analityk, uruchamia Jirę i mówi: „Teraz was zapoznam z wymaganiami” i przewija trzy ekrany.

Kuba: Ściany tekstu.

Jacek: Niesamowicie precyzyjnie rozpisanych rzeczy, z sali nie ma pytań, praca wykonana, tylko jakiś taki smutek w zespole, że chyba nie o takie podejście zwinne walczyli. Tak więc myślę, że tak jak – to, co teraz powiem, to dotyczy w sumie każdej roli. Zmiana sposobu pracy w firmie wiąże się z tym, że ludzie też zmieniają swoje podejście, swoją postawę i to dotyczy programistów, to dotyczy testerów, UX-owców, w jakiejkolwiek innej roli, która funkcjonuje i tak samo dotyczy analityka.

Kuba: I może być tak, że jeśli ten systemowy problem jest nierozwiązywany, w sensie, poszczególny pojedynczy analityk w toczącej się jakiejś zmianie czy w firmie, która już funkcjonuje w jakiś sposób zwinny, ale jest to niedoskonałe, że ten temat wraca. Pytanie jaka może być rola analityka w zwinnym podejściu wraca – no, jeśli ono wraca, to znaczy, że temat jest… jakiś jest. No i teraz wtedy wraca też to, co zaczęliśmy przy definicji – jeśli w ramach organizacji funkcjonuje cały zespół, ma swojego kierownika i oni mają swoje standardy, i oni absolutnie o krok nie ruszyli ze swoich pozycji albo ewidentnie nie nadążają za zmianą, no to może być też temat dla liderów całej zmiany czy liderów podejścia zwinnego w organizacji. No i jeśli poszczególne pojedyncze Retrospektywy, poszczególne wysiłki pojedynczych Scrum Masterów nie przynoszą żadnej zmiany, to możliwe, że jest powód, jest pretekst do tego żeby się skrzyknąć i sformułować pewne oczekiwanie względem roli analityka, a jeśli jest ta rola częścią struktury organizacyjnej, to również sformułowanie pewnych oczekiwań względem tej struktury organizacyjnej, być może uruchomienie jakichś takich czynności usprawnieniowych, porozmawianie, czy ci analitycy mają kompetencje, czy są otwarci na zmiany, czy rozumieją, po co ta zmiana w ogóle następuje, z czego ona wynika, zaprosić ich do współpracy, ale być może również włączyć jakichś liderów całej organizacji, żeby im uzmysłowić, jeśli problem konsekwentnie jest nierozwiązywalny i porozmawiać o tym, jak te zmiany przeprowadzić, żeby ta współpraca przebiegała lepiej, żeby ci analitycy weszli w te fajne role, o których już dużo w tym odcinku powiedzieliśmy, a nie trzymali się swojej niezmienionej postawy, takiej żywcem ze szkolenia z podstaw analizy, z tego świata jednak takiego… kaskadowego, bo takie postawy podejściu zwinnemu, delikatnie nazwijmy to, nie służą, a wprost mówiąc, są niedopasowane i będą blokować i będą przeszkadzać i w bardzo mocny sposób będą się konfliktować z pewną grupą struktur organizacyjnych czy kompetencji innego typu, które będą blokowane przez wykonywane czynności analityczne, w taki sposób klasyczny, niezmieniony i niekompatybilny z innymi miejscami w organizacji.

Jacek: Gdybyś miał podsumować, Kuba, w paru zdaniach naszą rozmowę?

Kuba: Tak. W Agile uważam, że potrzebne są kompetencje analityczne, potrzebne są aktywności analityczne, ale niekoniecznie są niezbędne silosy kompetencyjne, czyli być może analityk będzie konkretnym etatem w zespole, a być może w niektórych zespołach te kompetencje po prostu będą musieli wykazywać inni członkowie zespołu. Jeśli jest w zespole konkretny analityk, to jeśli jest to konkretna osoba, to ja ze swojego doświadczenia mogę powiedzieć – o tym dzisiaj za dużo nie mówiliśmy – że taka osoba, przez konkretne przykłady to mówię, może się bardzo mocno rozwinąć, może zaczerpnąć inspiracji też z sąsiednich ról, mocno wejść w rolę mentora, mocno wejść w rolę takiego w tej dziedzinie przywódcy całego zespołu, też osoby, która bardzo daje do myślenia całemu zespołowi, a nie tylko stricte trzyma się swojej roli – wychodzi poza swoją rolę i pomaga innym być może samemu przy okazji też się rozwijając – czy to w UX-ie, czy to w Developmencie, czy to w testowaniu. Na pewno to spektrum kompetencji również u analityka się rozwija w czasie, gdy wchodzi głębiej w rolę członka zespołu zwinnego. 

Natomiast powiedzmy sobie też wprost, że jeśli analityk pracuje po staremu, a firma przechodzi jakąś zmianę, kolejne zespoły wchodzą głębiej w podejście zwinne, odkrywają kolejne pokłady tego, jak można pracować jeszcze fajniej, jeszcze lepiej, jeszcze lepiej jakościowo, jeszcze wyższą wartość dostarczać, jeszcze częściej, to może się okazać że analityk będzie zagrożony i powinien się czuć zagrożony, jeśli nie ma najmniejszej ochoty zmienić kompletnie swojego nastawienia, bo tak, jak już wspomniałem, będzie to niekompatybilne z tym, jakie są trendy w zespole i prawdopodobnie w całej organizacji.

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

Kuba:  Dzięki, Jacek.

Jacek: I do usłyszenia…

Kuba i Jacek: …wkrótce!


2 Replies to “#008 – Rola analityka w Agile”

  1. Celina

    Bardzo dziękuję za dotknięcie tematu analizy!
    Ten temat powinien być poruszany częściej. Zwłaszcza w tak kompleksowy i obiektywny sposób!
    Super! Szczególnie dzięki za pomysł na postać analityka, który staje się mentorem, zadającym pytania, kwestionującym, budzącym wątpliwości. Kimś, kto nie traktuje analizy jak mocy tajemnej i niezagarniającym jej w całości dla siebie 🙂
    Co mnie dziwi, to kontrowersje narosłe wokół analizy w agilowym świecie. Jakoś przyzwyczailiśmy się do tego, jak zmieniło się podejście do testowania i nikt nie zastanawia się, czy aktywności związane z testami są aby jeszcze potrzebne. Więc dlaczego ten właśnie element procesu budzi tyle emocji? Dla mnie, istnieje analogia… Analiza jest potrzebna, kompetencje analityczne są potrzebne, myślenie biznesowe, odkrywanie potrzeb, ciągła weryfikacja zasadności biznesowej, pamięć o użytkowniku. Rola analityka zmienia się – tak jak sugerujecie, podobnie jak rola QA, programisty,… jak każdej osoby zaangażowanej w proces zwinnego wytwarzania.
    Co zaobserwowałam, to że nie zawsze jest tak, że to analityk jest tym ogniwem w zespole, który ma problem z dostosowaniem się do nowych realiów. Bardzo często jest tak, że zespół wciąż czeka na „gotowe” „szczegółowe” rozwiązanie i to analityk boryka się z oczekiwaniami i pretensjami. Myślę, że to trudna praca, by na nowo poustawiać role, relacje i wzajemne oczekiwania. Praca, którą musi wykonać cały zespół. No i jeszcze jedna myśl, te relacje trzeba dogrywać nieustannie.

  2. Kuba

    Celina, Cieszę się, że odcinek był dla Ciebie inspirujący. Masz sporo racji w swoim komentarzu o tym, że zdarza się, że pewnych zachowań od analityka oczekuje sam zespół. To jest wielki temat dla Scrum Mastera i otwartej rozmowy całym zespołem o całości procesu, np. na dedykowanej temu tematowi Retrospektywie. I tak jak podkreślasz – taka relacja będzie ewoluowała w długim okresie, jedną rozmową czy jednym zarządzeniem tematu się nie rozwiąże.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial