Praca z ludźmi sama w sobie jest wyzwaniem. Wywiad z Michałem Kordasem
Scrum Master ma przede wszystkim ułatwiać pracę devów. Usuwanie przeszkód z dróg programistów jest jednak dość trudnym zadaniem, wymagającym od Scrum Mastera nie tylko umiejętności twardych, ale i miękkich. O to, jak wygląda praca z ludźmi w IT, na czym dokładnie polega i czego wymaga od samego kandydata, zapytaliśmy Michała Kordasa, Principal Business Designera w intive.
Spis treści
W jaki sposób zostałeś Scrum Masterem i Agile Coach’em? Na czym polega Twoja praca, jakie obowiązki masz w firmie na co dzień?
To dość przewrotna historia. W branży IT pracuję już kilkanaście lat, ale moja ścieżka zawodowa układała się w taki sposób, że kilkakrotnie byłem w roli Product Ownera, Project Managera, a nawet dyrektorskiej. Nigdy jednak nie miałem okazji pracować wyłącznie w roli Scrum Mastera poświęcając na to 100% swojego czasu zawodowego. Bardzo często wykonywałem obowiązki SM-a, w ramach pracy w rolach (szczególnie pracując jako PM), czasem miałem je nawet oficjalnie “zapisane”, ale zawsze musiałem dzielić swój czas pomiędzy tymi rolami i ta część SM-owa była niejako obok.
Nie rozwodząc się już nad konfliktem interesów, który może się między tymi rolami pojawiać. Z biegiem czasu docierało do mnie, że ten “dodatkowy” zakres obowiązków interesuje i cieszy mnie dużo bardziej oraz, że moje cechy i mocne strony lepiej współgrają właśnie z rolą Scrum Mastera. Stało się dla mnie jasne, że coś trzeba z tym zrobić. Tak właśnie zostałem SM-em i Agile Coachem na “full time”.
Moje obowiązki jako Scrum Mastera i Agile Coacha są raczej zgodne z “literą prawa”. Głównie pracuję z Zespołami w projektach, ale znajduję również czas dla naszej firmy. Zespoły wspieram w ich dążeniu do bycia lepszymi oraz w osiąganiu rezultatów i celów w sposób jak najbardziej efektywny. Staramy się szukać wszędzie wartości, prostoty i eliminowania strat (zarówno w produkcie jak i w sposobie pracy).
Dbam o nasze procesy wytwórcze, ale również o sam Zespół, indywidualnie o człowieka, o ich samopoczucie, o komunikację, czy relacje (również z klientami). Natomiast w organizacji, razem z koleżankami i kolegami Scrum Masterami staramy się “krzewić” zwinność (warsztaty, szkolenia, szkółki), pomagać innym rolom jeśli jest potrzeba oraz wpływać na sposób pracy i postępowania w naszej organizacji na tyle, na ile możemy. No i oczywiście pracujemy też nad swoim warsztatem (np. guildie domenowe).
Jak trafiłeś do intive?
Samo trafienie do intive było dość klasyczne. Ogłoszenie, aplikacja, dwie – trzy rozmowy (swoją drogą bardzo dobre) i zostałem intiversem 😉 Natomiast motywacją i głównym powodem tej decyzji z mojej strony była (jak już wspomniałem) możliwość poświęcenia się wyłącznie roli Scrum Mastera, nie dzieląc czasu z innymi rolami. Z perspektywy ponad 3 lat, mogę śmiało powiedzieć, że to była bardzo dobra decyzja.
Czy mógłbyś nieco opowiedzieć o tym, czym dla Ciebie jest Agile i Scrum? Jaki wpływ na pracę i całą organizację ma zastosowanie tych praktyk w intive?
Agile to dla mnie przede wszystkim sposób myślenia i postępowania, czyli tak zwany “mindset”. Taki, w którym często zastanawiamy się nad celem i sensem naszych aktywności i procesów, w którym często zadajemy sobie pytanie dlaczego? Sposób, w którym czołowe miejsce zajmuje wartość. Pracując w sposób zwinny, raczej będziemy sceptyczni wobec robienia “sztuki dla sztuki”, czy bezmyślnego powielania sztywnych ram, jeśli przeczą zdrowemu rozsądkowi.
Agile to także sposób budowania odpowiednich relacji międzyludzkich (wewnętrznych i z klientem)! Relacji opartych na zaufaniu, transparencji, odwadze i szacunku oraz bliskiej współpracy. Oczywiście nie zawsze się to wszystko udaje, czasem jest to po prostu niemożliwe, ale warto starać się działać w sposób zwinny, bo w zamian otrzymamy efektywność, satysfakcję z pracy i poczucie sensu.
A Scrum (lub Kanban, czy “systemy” skalowane) to zwinne frameworki, ramy postępowania, trochę narzędzia, którymi się posługujemy w wytwarzaniu oprogramowania. Mają swoje zasady, czy “workflow”, które pomagają nam ustrukturyzować pracę, procesy w projekcie i sensownie planować, ale pamiętajmy, że wywodzą się z nurtu zwinnego, zatem podejście do tych frameworków (i ich wykorzystanie) również nie powinno być zbyt sztywne oraz warto dostosować je do konkretnego projektu czy zespołu.
Zwinny sposób pracy i wspomniane wcześniej, płynące z niego zalety, przekładają się oczywiście także na całą organizację. Jeśli bowiem zespoły starają się pracować agile-owo, Agile jest rozumiany i stosowany również przez management firmy, to takiej organizacji jest łatwiej się rozwijać (i szybciej). Lepiej dostosowuje się do zmian w jej otoczeniu biznesowym (a tych nam nie brakuje ostatnimi czasy), prościej jest jej wykonać jakiś pivot operacyjny czy strategiczny.
Pracownicy na czele z liderami rozumieją, po co to robią i że to przyniesie wartość, pomimo potencjalnych trudności. W takich firmach po prostu lepiej się pracuje, budowane są zdrowe relacje, a ludziom chce się angażować w rozwój i “życie” firmy, gdy widzą, że ich praca i postawa to realny wkład. Natomiast, żeby nie było tak słodko 😉 trzeba uczciwie powiedzieć, że proces pod tytułem “uzwinnić organizację od stóp do głowy” to potężne i bardzo trudne wyzwanie.
Jakie są Twoje największe wyzwania, z którymi musiałeś się zmierzyć i mierzysz się nadal podczas pracy z ludźmi?
Szczerze, to praca z ludźmi sama w sobie jest wyzwaniem. Osobiście bardzo ją lubię, daje mi dużo satysfakcji oraz motywuje mnie i rozwija, ale uważam, że to wymagająca praca. Jest tak dlatego, ponieważ ludzie są różni, pochodzą z różnych środowisk, różnych pokoleń, mają inne doświadczenia, poglądy, charaktery i sposób bycia. Różnią się między sobą i od nas.
Następnie, te wszystkie różnorodności łączą się w jedną grupę, zespół projektowy i muszą (a miejmy nadzieję, że chcą) ze sobą efektywnie współpracować oraz się dogadywać. Tworzy się więc nowy układ, nowe zasady, zależności, a sam zespół przechodzi przez różne fazy rozwoju i zmiennie się w nich zachowuje. W ten sposób docieramy do tak zwanych dynamik grupowych. Warto poczytać o tym więcej, bo pozwala to lepiej zrozumieć zachodzące procesy i może być bardzo użyteczne w pracy.
Dla mnie największymi wyzwaniami w pracy z ludźmi są dwa obszary. Pierwszy to konflikty, szczególnie te “grube”, które mogą kończyć się nawet chęcią opuszczenia danej grupy przez jedną ze stron (lub obie). Próbujesz wtedy oczywiście okiełznać tą sytuację i ją wyjaśnić jak najszybciej (posługując się chociażby fazami i dynamiką konfliktu), ale czasem sprawy przybierają na tyle zły obrót, że jesteś bezsilny. Drugi trudny dla mnie obszar we współpracy z ludźmi (leżący na przeciwnym biegunie od poprzedniego), to po prostu “dobrowolne rozstania”.
Kiedy odchodzą z projektu lub firmy, do innego projektu lub organizacji, ludzie wartościowi, z którymi zdążyłeś się już mocno zżyć. Lubiliście się, świetnie się dogadywaliście, spędzaliście każdy dzień w projekcie razem, czasem nawet przez lata. To nigdy nie jest proste. Tak się składa, że ostatnio doświadczyłem właśnie tej sytuacji i zmiana projektu dotyczyła m.in. mnie. A projekt i ludzie są wspaniali. Powiem tylko, że nie łatwo usuwało się ostatniego dnia spotkania projektowe z kalendarza 😉 Dłuższą chwilę patrzyłem nieco nostalgicznie w monitor zanim to zrobiłem.
Kim jest dla Ciebie prawdziwy leader? Czym powinien się charakteryzować, jakie są jego role i jakie ma znaczenie dla całego zespołu?
Od dawien dawna krąży po sieci taki obrazek z jegomościem w roli “przywódcy”, ciągnącym ciężar razem z zespołem (lider) i dla kontrastu siędzącym na ciężarze i rozkazującym zespołowi (szef w tym rozumieniu pejoratywnym). I choć jest to wersja mocno uproszczona i trochę przerysowana, to jednak zgrabnie uchwyca istotę tej roli. Lider raczej pociąga (za sobą), podczas gdy “archaiczny” szef pcha (pogania).
Dla mnie lider jest bardziej przewodnikiem prowadzącym do celu grupę ludzi, którą to grupę z resztą współtworzy, buduje w niej relacje i ją rozwija. Idzie z zespołem ramię w ramię i swoim przykładem kreśli pewne kanony zachowań. U lidera częściej słyszymy “my” niż “ja”, bo on wie, że tu nie chodzi o niego, ale o całą grupę jako jeden organizm.
Podczas tej drogi do celu, lidera charakteryzować będzie odwaga w czynie i słowie (tu koniecznie połączona z szacunkiem), charyzma, decyzyjność (najlepiej połączona z dalekowzrocznością), świadomość i pewność w postępowaniu (nie mylić z byciem zarozumiałym) i stabilność emocjonalna. Ponieważ lider jest rolą nierozłączną z grupą, to według mnie musi też potrafić słuchać ludzi, być empatyczny wobec zespołu, motywować go, organizować oraz jednoczyć. Na koniec tej wyliczanki jego cech dodałbym, że powinien też być dobry komunikacyjnie, ale o komunikacji to sobie jeszcze porozmawiamy 😉
Co ciekawe, wiele z tych cech charakteryzuje również dobrego Scrum Mastera. Może dlatego nasza rola określana jest też mianem “servant leadera”, czyli “lidera służebnego”. Zainteresowanych odsyłam do szczegółów tego konceptu, bo jest ciekawy i wartościowy.
Czy mógłbyś opowiedzieć nam o komunikacji i facylitacji w zespole? Jaki mają wpływ na funkcjonowanie zespołu?
Jaki mają wpływ? Najkrócej mówiąc – kolosalny 🙂 W literaturze istnieje nawet taki wzór, który mówi nam o tym, jak liczebność zespołu wpływa na ilość kanałów komunikacyjnych [N = n(n-1)/2, gdzie n to liczba osób]. I tak na przykład, przy 4 osobach mamy 6 kanałów, ale przy 20 osobowym zespole mamy już 190 kanałów komunikacyjnych. Można sobie łatwo wyobrazić do jakiej rangi urasta wtedy znaczenie stwierdzenia “efektywna komunikacja”.
Dobra komunikacja i sensowna facylitacja są szczególnie ważne w dzisiejszych czasach. Przenieśliśmy się z biur do domów (przynajmniej częściowo) i zastąpiliśmy szybką i bardzo skuteczną komunikację bezpośrednią (twarzą w twarz), komunikatorami, czatami, grupami on-line, itp. To powoduje, że “ogarnięcie” komunikacji jest nie lada wyzwaniem i to właśnie często dla Scrum Mastera.
Efektywna komunikacja na pewno przyspiesza procesy i działania, eliminując nieporozumienia i chaos, które kosztują nas czas, a zatem i pieniądz. Dobra komunikacja to na pewno taka, która mówi o celu i realnych powodach. Nie wyklucza też ludzi i ułatwia stworzenie tzw. “bezpiecznej atmosfery”, a ta pozwala wszystkim zaistnieć, zaangażować się, swobodnie się określać. Prawidłowa komunikacja jest też precyzyjna i opiera się na faktach, co oczywiście nie oznacza, że wyklucza rozmowę o emocjach. Pamiętajmy też, że nad komunikacją w zespole (również swoją) możemy pracować i ją usprawniać, a nawet planować oraz dostosowywać do konkretnej grupy czy projektu.
Podobnie sprawa ma się z facylitacją. Jej istota, efekty i wpływ na zespoły są również warte uwagi i warte spróbowania tej sztuki. Przy czym facylitacja to trochę inny poziom niż komunikacja, bo tu spektrum działań jest szersze. Facylitując, de facto “zarządzasz” pracą zespołu, wykorzystując potencjał jego członków, nie zapominając o konkretnych rezultatach, które grupa musi osiągnąć oraz ograniczonym czasie. Zatem tutaj mamy bardziej holistyczne podejście i mówimy już bardziej o procesie.
W jaki sposób zarządzasz czasem pracy własnym oraz zespołu? Czy masz konkretne metody, pozwalające na priorytetyzowanie poszczególnych zadań w projekcie oraz ogólną poprawę organizacji pracy?
Czasem pracy Zespołu nie zarządzam w ogóle, albo w minimalnym stopniu. W ujęciu generalnym robi to za nas framework. Scrum dość dokładnie określa przedziały czasowe oraz wszelkie istotne wydarzenia po drodze. Pracujemy bowiem w sprintach, czyli krótkich odcinkach czasu (najczęściej dwu tygodniowych), gdzie na początku planujemy pracę, a na końcu oddajemy kolejny skończony “kawałek” produktu – i to jest nasz główny przedział czasowy, nasz rytm.
Często do tego dochodzi jeszcze release (“wypuszczenie” gotowej, nowej wersji produktu do użytkowników końcowych), który czasowo też regulowany jest raczej procesem naszym i klienta, dla którego tworzymy oprogramowanie. Framework pomaga określić nam także kilka innych wydarzeń podczas całego sprintu, ich częstotliwość i cel. Właściwie jedyna rzecz, która jest w moich rękach – jeśli chodzi o zarządzanie czasem zespołu – to kalendarz spotkań, ale nawet on ustalany jest wspólnie. I tak powinno być.
Po pierwsze jesteśmy dorośli i mamy do siebie zaufanie, więc nie będę mówił deweloperowi jak ma sobie planować pojedynczy dzień, czy kiedy ma zrobić review kodu koledze. Po drugie, jest to zgodne z ideą zwinnego zespołu, który m.in. powinien być samoorganizujący się. Oczywiście moja rola polega na wspieraniu członków grupy, zatem jeśli któryś z nich będzie potrzebował pomocy w zakresie zarządzania swoim czasem, to ja jestem do dyspozycji.
Natomiast zarządzam własnym czasem pracy, a jako że należę do osób zorganizowanych, to przykładam do tej części sporą wagę. Wykorzystuję różne metody i narzędzia, od klasycznych list “to-do”, po bardziej rozbudowane koncepty jak np. GTD (Getting Things Done, David Allen). Często miksuję różne metody, biorąc z każdej to, co sprawdza mi się najlepiej. Przykładowo, często korzystam z zasady 2 minut ze wspomnianej metody GTD (jeśli coś zajmuje umowne 2 minuty, robisz to od razu), macierzy Eisenhowera do priorytetyzacji swoich aktywności, czy metody MoSCoW lub ICE/RICE, jeśli Product
Owner potrzebuje mojego wsparcia w przypisaniu priorytetów do poszczególnych funkcji produktu. Niemal już podświadomie stosuję regułę Pareto, czy wycenę wartości swojego czasu, jeśli zastanawiam się nad sensem i wartością wykonywanych zadań. Jak trafiam na większe zadanie to przypominam sobie o metodzie salami (czyli po prostu podziale na mniejsze aktywności w sekwencji), ale też przypominam o niej Product Ownerom, przy tworzeniu tzw. user stories. A na koniec dnia stosuję prostą technikę planowania kolejnego dnia (kalendarz oraz lista pilnych zadań), bo m.in. pozwala ona “uwolnić” głowę z myślenia o pracy, po pracy 🙂
Na koniec zostawię pewne spostrzeżenie i (być może) wskazówkę. To, że zarządzasz sobą w czasie, nie oznacza zobowiązania do zrobienia 100% zaplanowanych rzeczy, bo to się często nie udaje. To raczej kwestia posiadania planu i umiejętności jego modyfikacji, gdy zmienią się okoliczności 😉
Co jest Twoim zdaniem najważniejsze podczas pracy nad konkretnym produktem/projektem? W jaki sposób Twój zespół przechodzi przez każdy etap każdego projektu, czy macie własne rozwiązania, model pracy, itp?
Generalnie to należałoby zacząć od celów biznesowych produktu czy projektu, czyli od zrozumienia co robimy, dla kogo i po co. Brzmi może trywialnie, ale o dziwo, ten element jest często traktowany po macoszemu lub pomijany. Potrzebny jest też plan działania, jak chcemy dojść do w pożądane miejsce (może to być np. roadmapa z kamieniami milowymi oraz przewidywaniami czasowymi). Dla mnie ważne jest też poznanie zakresu minimalnej, rynkowej wersji produktu (MVP).
Dopiero w drugiej kolejności dochodzi aspekt organizacyjny, czyli ułożenie odpowiedniego modelu pracy (bo proces jest odpowiedzią na potrzeby, a nie odwrotnie). Owszem, mamy własne rozwiązania, które każdorazowo wspólnie wypracowujemy, bo nie ma jednego, uniwersalnego procesu pasującego do wszystkich projektów. Opieramy się oczywiście mocno o dostępne frameworki zwinne, ale jednak musimy brać pod uwagę specyfikę produktu/projektu, naszego zespołu, czy nawet procesów po stronie klienta. Zatem finalny model pracy będzie najczęściej wypadkową tych elementów.
Naturalnie, bardzo ważnym elementem każdego projektu jest zespół, który powinien być tak skonstruowany, aby posiadać umiejętności do wykonania postawionego przed nim zadania. To podstawa, nad resztą rzeczy można pracować w trakcie.
Przechodzenie przez poszczególne etapy projektu z zespołami też jest różnorodne i zależne od kilku czynników, bo jak wspomniałem przy modelu pracy, to po prostu dynamiczny i elastyczny proces. W dużym uogólnieniu i skrócie, najczęściej zaczynamy od fazy “discovery”, czyli odkrywania produktu. Za pomocą odpowiednio przygotowanych warsztatów, staramy pozyskać się od klientów jak najwięcej informacji co i dla kogo jest do zrobienia.
Dalej musimy zamienić ten wsad w spisane wymagania dla zespołu deweloperskiego, ułożone według priorytetów oraz oszacować ich trudność i wielkość (przekładające się na czas wykonania). W końcu przechodzimy do etapu wytwórczego, który mocno opiera się na wybranym modelu zwinnym np. na Scrumie i tu już staramy się postępować możliwie według założeń frameworka.
Podobne artykuły
Z automatyki do IT: Jak odnaleźć swoje miejsce w świecie technologii?
"Dobrze działający zespół daje wyniki" – o tym, jak ważne jest budowanie zespołu rozmawiamy z ekspertami firmy Ericsson
"Jeśli brakuje Ci feedbacku, nie czekaj, poproś o niego!" – ekspertki firmy Ericsson o tym, jak ważna jest informacja zwrotna w zespole
Niekorzystanie z AI może przynieść firmie realne straty. Wywiad z Miłoszem Niczyporukiem
Jesteśmy startupem w korporacji. Wywiad o Global Network Platform
Dzielenie się wiedzą z innymi niesamowicie rozwija. Wywiad z Amelią Walter-Dzikowską
Kiedy ostatnio dobrze pracowało Ci się z kodem na frontendzie? Wywiad z Mateuszem Kłosińskim
