“Mówienie, że wszystko się da załatwić Scrumem jest objawem żabiej perspektywy”

W czasie naszej poprzedniej rozmowy, po zasadniczej części wywiadu zaintrygowałeś mnie bardzo mocną opinią o problemie postrzegania przez Scrum Masterów rzeczywistości wokół siebie z żabiej perspektywy. Scrum master postrzega całą organizację z perspektywy dobra zespołu. Nie myśli o perspektywie całości, która jest istotna dla managerów, co może spowodować konflikt. Czy możesz jakoś poszerzyć tą koncepcję?

Andy Brandt: Wizja Scruma jest taka, że jako zespół razem budujemy produkt. Tylko żeby produkt budować, trzeba go sprzedać i ten biznesowy element, perspektywa sprzedaży, jest często deweloperom obca. Scrum Masterzy często wywodzą się właśnie z developerów (szeroko rozumianych) i oni wszystko postrzegają z tej perspektywy. Często nie mają perspektywy biznesowej. I ciężko jest o to nawet ich winić, czy w jakiś sposób krytykować, bo żeby tę perspektywę uzyskać, to właściwie najlepiej byłoby jakiś biznes prowadzić. Dopiero robiąc to zaczynasz inaczej patrzeć na pewne rzeczy i je rozumieć.

Taki klasyczny temat to jest pytanie dlaczego ten “głupi” sprzedawca sprzedał coś, czego nie mamy wydevelopowanego. Spojrzenie biznesowe na to jest:odmienne – wspaniały sprzedawca! Sprzedając coś, czego nie mamy jeszcze gotowego, usunął nam najważniejsze ryzyko biznesowe: robienia czegoś, czego nikt nie kupi. Oczywiście w praktyce problem pewnie tkwi w tym, co on tam obiecał przy okazji, na przykład nierealistyczne terminy. Niemniej od strony sprzedaży, sprzedać coś, czego nie masz, to jest szczyt kunsztu, ale z punktu widzenia developmentu będzie to widziane inaczej. Fajnie byłoby z tym postrzeganiem sytuacji się spotkać gdzieś pośrodku. Żeby to spotkanie było możliwe, musimy wiedzieć, że ta druga perspektywa może nie jest taka głupia, że może ona jednak z czegoś sensownego wynika.

Ostatnio miałem z kolei refleksję w drugą stronę, że my w agile bardzo duży nacisk kładziemy na otwartość, mówienie sobie prawdy, zaufanie, szacunek. To musi działać w obie strony – od zespołu i od biznesu. Za rzadko szanujemy się wzajemnie.  Czasem funkcjonujemy w założeniu czy domniemaniu złej woli. Domniemujemy złą wolę drugiej “strony”, dopóki ona nie udowodni, że ma dobrą wolę. To troszkę utrudnia funkcjonowanie, bo zanim ktoś udowodni, że ma dobrą wolę, to mija czas.

Może nawet nie wiedzieć, że musi udowadniać tę dobrą wolę, jest pewien, że ma rację i jest rozumiany.

Albo już się czuje obrażony samym faktem, że ktoś założył inne zrozumienie intencji.

Zwracasz uwagę na to, że to jest zależność dwustronna, że zarówno biznes musi szanować zespół, jak i zespół musi wczuć się w tę stronę biznesową. W takim razie z perspektywy takiej osoby, która stwierdzi – “kurcze, faktycznie, popełniam ten błąd: zakładam, że mój zespół mam rację, a biznes się zawsze myli” – co można zrobić, żeby w sobie to zmienić?

Przede wszystkim ze sobą rozmawiać. To jest strasznie trywialna odpowiedź, ale to jest takie bardzo typowe:  budujemy dość skomplikowane konstrukcje myślowe, które wyjaśniają nam dlaczego inni robią to, co robią. Po czym rozmawiamy z tym kimś, zadajemy mu pytanie o intencje i okazują się one dość proste. Drugim pomysłem jest to, że  fajnie jest wyjaśniać sobie różne rzeczy. Niestety bardzo często odpowiedź jest “nie, bo nie” i “tak, bo tak”. A można próbować coś wytłumaczyć, jednak to wymaga wysiłku, bo jak już coś się zna bardzo dobrze, to nie każdy ma tą łatwość, żeby syntetycznie i zrozumiale owo coś wyłożyć. Wartościową praktyką pomagającą zrozumieć perspektywę biznesową jest to, żeby deweloperzy mieli szansę zobaczyć użytkowników i klientów, mieli okazję się z nimi spotkać. W jednej firmie, z którą pracowałem, mieli taką praktykę wprowadzoną, że zaczęli zabierać na wizyty serwisowe deweloperów. Członkowie zespołu po raz pierwszy zobaczyli na żywo użytkownika, zobaczyli, jak klnie na coś w produkcie. Samo zdanie sobie sprawy z tego, że moja perspektywa na to, czego potrzebuje mój klient, może nie być kompletna, jest bardzo cenne.

W temacie tej żabiej perspektywy mam ostatnio takie przemyślenie, że świat agile’owy jest na takiej fali, zachłyśnięciu się sukcesem, że wszyscy wokół chcą być zwinni, również poza IT. Dostrzegam czasem zjawisko takiego przemądrzałego scrumowca, który skoro umie sprawić, żeby praca nad produktem w zespole scrumowym była dobra, to automatycznie daje mu też prawo mieć mocne zdanie o HRach, zarządzaniu finansami, tego jak zrobić dobry proces sprzedażowy.

A to ciekawe, bo ja na takie typowe pytanie “czy w Scrumie można robić inne rzeczy, niż software” zawsze odpowiadam w ten sposób, że przywołuję historię Scruma, korzenie w “New New Product Development Game” Takeuchiego i Nonaki. Pokazuję, że to były rzeczy niezwiązane z oprogramowaniem, mówię więc, że domniemuję, iż można Scrumem robić inne rzeczy, ale zastrzegam, że nie czuję się kompetentny, bo właściwie całe swoje życie zawodowe spędziłem gdzieś w okolicy software’u i to jest to, o czym mogę coś powiedzieć. Ale czy marketing można robić agile’owo? No ja się nie podejmuję odpowiadać na takie pytanie. Nie jestem marketerem, nie wiem.

Ale muszę Ci powiedzieć, że ja patrzę na to zachłyśnięcie sukcesem odwrotnie. Ja patrzę na nie z bardzo dużym niepokojem dlatego, że moim zdaniem to jest bardzo powierzchowne i jakość tego agile’a jest bardzo niska w wielu miejscach. Bardzo często mamy do czynienia  z czymś, co my nazywamy “mechanistycznym Scrumem”, są “ceremonie” ale nie ma zrozumienia, dlaczego to jest takie, jakie jest, i po co my to robimy? To jest w ogóle bardzo typowy problem. Przychodzisz do organizacji – “tak, my chcemy mieć Scruma”. A dlaczego chcecie mieć Scruma? “Bo chcemy mieć agile”. A dlaczego chcecie mieć agile? “No bo chcemy więcej, szybciej, lepiej”. Ale konkretnie, skąd będziecie wiedzieli, że to Wam przyniesie korzyści? I tu jest cisza i to jest słabe. Ja się boję, że to zachłyśnięcie może bardzo szybko przejść w…

Kryzys?

Kryzys. Mamy to wszystko, ale nie jest lepiej… Tu są karteczki na ścianach i mamy Scrum Masterów i codziennie stoimy przez 15 minut, ale kurcze nie jest lepiej. To może to wszystko jest do bani?

Jak mówię o tym zachłyśnięciu, to mam na myśli to, że dobrze zrobiony Scrum jako taki sam się broni w danym zespole, w pojedynczym projekcie czy produkcie, co może powodować chęć rozprzestrzeniania go szerzej. Nawet nie mówię o takim scenariuszu, że jest to powierzchowne, tylko że nawet niech to będzie głębokie i porządne, ale w konkretnej firmie istnieje groźba, że na fali sukcesu zmiany podejścia do produktu łatwo wpaść w takie już poczucie wyższości, że to teraz Scrum jest uniwersalnym rozwiązaniem na wszystko.

Faktem jest, że żeby tę zwinność biznes mógł skonsumować, to również pozostałe elementy firmy muszą zacząć funkcjonować inaczej. W związku z tym IT, które się zmienia, może być takim zalążkiem głębszych przekształceń w organizacjach. Bardziej jednak wierzę w to, że nowe organizacje, które się buduje od zera, będą inne również w funkcjach takich jak finanse czy HR, właściwie we wszystkim będą inne. Inspiracją może być Holakracja, która jest takim pomysłem zrobienia wszystkiego zupełnie inaczej. I pójdźmy głębiej, pójdźmy w tę stronę, żeby nawet sama struktura organizacji i sposób zarządzania podlegał ciągłej ewolucji empirycznej. To jest dość uniwersalne nastawienie mentalne, że nie wiem wszystkiego z góry, że jest niepewność i muszę sobie z nią radzić w sposób empiryczny, czyli próbując, sprawdzając rozwiązania i wybierając te, które działają.

W Scrumie są zaszyte takie mechanizmy jak retrospektywy, ciągłe myślenie o tym, żeby się usprawniać zespołowo, czy ogólnofirmowo. Te metody są uniwersalne w wielu zespołach nie tylko rozwijających oprogramowanie. Niekoniecznie jednak na 17 stronach Scrum Guide’a znajdziemy odpowiedź na to, jak zorganizowane powinny być np. Finanse w dużej firmie i czy w ogóle inne zespoły poza IT też tak muszą pracować.

Trzeba pamiętać, że Scrum był pomyślany pod software i tyle. On siedzi w głębszych pryncypiach, takich jak właśnie empiryzm przede wszystkim, i one są bardziej uniwersalne, ale na pewno nie sama metoda. Warto zrozumieć to, że to jest bardzo fajna metoda, bardzo popularna, ale to jest tylko jeden kafelek w dużo większej układance różnych metod, które odpowiadają na to, jak zorganizować działania. I to jest gigantyczny temat. Jest mnóstwo nurtów takich jak Theory of Constraints Goldratta, Holakracja czy Socjokracja, Lean. Wszystkie te podejścia dają jakieś efekty i są dopasowane do konkretnych kontekstów. Mówienie, że to wszystko się da załatwić Scrumem, to jest kolejny objaw tej żabiej perspektywy. Rozmawiałem ostatnio właśnie z kimś, kto jest doświadczonym Scrum Masterem, i myśli o jakimś tam rozwoju zawodowym. Zapytałem go, co sądzi o ostatnich ewolucjach w praktykach kanbanowych? “O! Nic o tym nie słyszałem”. “A co powiesz o #NoEstimates? Jakie jest Twoje zdanie?” “No… nic nie wiem na ten temat”. Aha. Wow, bo mi się wydaje, że jak siedzę w jakimś temacie, to czytam, rozwijam się, staram się wiedzieć. Na przykład o #NoEstimates mam zdanie nienajlepsze, ale przynajmniej wiem, co to jest, i na moim radarze pojawiło się przemyślenie tego podejścia. Nie bardzo rozumiem, że ktoś w ogóle nie wie, co to jest, a jest Scrum Masterem. Jeśli rozmawiam z fotografem, to spodziewam się, że się zna aparatach i rozwija się w swojej profesji. Jest niebezpieczna tendencja, że jak już ktoś używa Scruma, umie go stosować, to w zasadzie już wie wszystko.

No to jest ciekawy wątek. Jak myślę o tym, czy ktoś jest dobrym, czy kiepskim Scrum Masterem to właśnie to, jak się rozwija, jest jednym z czynników różnicujących. I zakładam, że dostajesz takie pytania na przykład na PSMie o to, jak powinien się rozwijać Scrum Master, jak już zdał certyfikat…

Nie dostaję takich pytań…

Nie dostajesz takich pytań?!

To niezmiernie rzadkie jest, żeby ktoś pytał, co robić, by rozwijać się dalej.

To mi potwierdza bardzo osobiste przemyślenie o ciężkiej sytuacji w tej kwestii.

Ale to jest bardzo ludzkie. Zobacz, że w historii ludzkości, patrząc na społeczeństwo, element rozwoju był bardzo rzadką rzeczą poza dzieciństwem. Przez większość historii ludzkości jako dziecko się uczyłeś różnych rzeczy, “wyuczałeś się zawodu” (rubryczka “zawód wyuczony”) i potem żyłeś nim całe życie. Może nawet to parcie do tego, żeby się rozwijać (jeszcze jedno szkolenie, jeszcze jedna książka, jeszcze bym się dowiedział czegoś itd.), to jest objaw nienormalności. Ja sam nie mogę odpuścić, nie mam takiego przekonania, że w sumie już wiem wszystko. Tu jest książka, którą muszę przeczytać, a tu jest takie fajne szkolenie, na które bym poszedł, ale nie mam kiedy, ale w końcu pójdę. Jak “odpaliła” Holakracja, to ja w te pędy poleciałem i zrobiłem pięciodniowe szkolenie, żeby mieć jakieś pojęcie o tym. Ale myślę, że to jest nienormalne, normalni ludzie tak nie mają. Normalni ludzie mają pracę i wychodzą, zamykają drzwi i żyją swoim życiem. Z drugiej strony może dlatego tacy ludzie jak ja i inni, którzy właśnie tak mają, są potrzebni i mogą opowiadać innym różne rzeczy, a oni dzięki temu oszczędzają trochę czasu na inne rzeczy.

Idąc tym tropem oszczędzania czasu, to w takim razie co byś doradził komuś, kto ma ochotę się rozwijać, ale ma na to strasznie mało czasu.

Wbrew pozorom nie szukałbym tej rekomendacji po tematach agilowych. Myślę, że Scrum Masterzy, jeżeli myślą poważnie o tym, co robią, to na przykład powinni sobie solidnie poczytać takie tematy jak proces grupowy czy psychologia grupy. Żeby mieć pojęcie, co się dzieje z grupą, z którą pracują. Scrum Masterzy powinni mieć wiedzę także z zakresu zarządzania. Fajnie by było na przykład przeczytać sobie coś o project managemencie. My zarządzanie projektami atakujemy ostro, a fajnie byłoby wiedzieć, z czym się konkretnie nie zgadzasz i dlaczego. Myślę, że warto też się poedukować z Lean, między innymi warto przeczytać coś solidnie o kanbanie dlatego, że bardzo często jako Scrum Master, czy jako doradca, trafiam na zespoły, które powinny pracować w kanbanie, a zostały wciśnięte na siłę w Scruma przez organizację. Żeby im pomóc, musisz mieć rozeznanie też w tym obszarze. O samym Scrumie też warto czytać, jest książka Guntera Verheyena, która jest całkiem fajna, czy Romana Pichlera o product ownerstwie, która jest super rzeczą. To są rzeczy, które Scrum Master też powinien wiedzieć, skoro ma pomagać Product Ownerowi, bo przecież nie każdy PO pójdzie na szkolenie ze swojej roli w Scrumie. Podsumowując proponuję poszerzać swoją wiedzę, bo jak ktoś jest praktykującym Scrum Masterem to te rzeczy, które robi, sprawiają, że rozwija się przez praktykę, ale trzeba poszerzać swoją wiedzę poza rolę SMa. Super rzeczą jest czytanie jak najwięcej, są też tacy, którzy lubią nagrania w internecie i wykłady, to też jest fajne. Ja czasami z tego korzystam, zwłaszcza, że najczęściej te wykłady da się słuchać, jadąc na przykład samochodem. W tej chwili czytanie i słuchanie jest bardzo łatwe, bo nie musisz nosić ze sobą książki, jeśli masz Kindle’a czy apkę na telefonie. To pozwala nam czytać i wykorzystać nawet takie pięciominutówki w ciągu dnia, gdy jesteś chociażby w autobusie, zawsze możesz poczytać chociaż kawałek.

Dzięki za rozmowę.

Dzięki.

Źródło zdjęcia – Yamanaka Tamaki „frog”  na licencji CC BY-NC-ND 2.0

Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x