Praca w STX-ie: 5 pytań do Scrum Mastera

Scrum, planowanie sprintów, refinementy, review, spotkania ze Scrum Master-em – Agile rządzi się swoimi definicjami. Osobie, która spotyka się z tymi zagadnieniami po raz pierwszy, mogłoby się wydawać, że to wszystko wcale nie ułatwia procesu developmentu i dostarczania kolejnych i kolejnych wersji produktu. Jak mawiają klasycy: “Nic bardziej mylnego”. 

STX Next tworzą scrumowe zespoły i każdy z nich jest przykładem indywidualnego podejścia do zarządzania projektem. Dlaczego tak? Ponieważ każdy projekt jest zupełnie inny i tak samo jak Scrum, rządzi się swoimi regułami, specyfikacją, stackiem technologicznym, branżą oraz skalą rynku, na którym działa lub zamierza się pojawić. 

Na każdej rozmowie rekrutacyjnej opowiadamy o Scrumie, zwinności oraz naszym podejściu do tych zagadnień. Zdarza się, że  kandydaci kontynuują temat i dzielą się własnymi przykładami zastosowania Scruma, a niekiedy, słysząc o Agile’u po raz pierwszy, zadają więcej pytań i starają się zrozumieć o co w tym wszystkim chodzi. 

Co roku STX-owy zespół rekrutacji prowadzi setki rozmów, co pozwoliło nam wyodrębnić kilka najbardziej popularnych pytań, jakie słyszymy od kandydatów na stanowiska programistyczne oraz testerskie. 

Czy daily oznacza, że pracuję w Scrumie? A czym dokładnie zajmuje się Scrum Master? Jak wygląda kontakt z klientem? Czy nie za dużo macie tych spotkań scrumowych? Odpowiedzi na te wszystkie pytania znajdziecie w naszym dzisiejszym wpisie, który powstał przy współpracy z częścią naszej STX-owej załogi Agile: Damiana Winczewskiego z gdańskiego oddziału, Dionizy Smury z poznańskiego oraz Pawła Jankowskiego z łódzkiego. Serdecznie zapraszamy do lektury!


Rola Scrum Mastera w STX-ie: jak wygląda? 

Dioniza Smura

Scrum Master przede wszystkim dba o to, żeby zespół pracował w Scrumie. Idzie za tym wsparcie w organizacji pracy zespołu w możliwie najbardziej wydajny sposób, który umożliwi sprawną realizację zadań, rozwój i bieżące rozwiązywanie pojawiających się problemów. 

Scrum Master słucha, obserwuje i proponuje usprawnienia, ale też dba o komunikację w zespole oraz z klientem.  Zachęca zespół, żeby nie ignorować “słonia” w pokoju. Niekiedy Scrum Master jest wsparciem dla mniej doświadczonych Product Ownerów, a innym razem jest mocnym ekspertem i zapleczem szkoleniowym dla klientów, którzy nie przywykli pracować w Scrumie. 

Damian Winczewski

Praca w roli Senior Scrum Master’a w gdańskim oddziale STX Next jest dla mnie rozwijająca i z każdym tygodniem coraz ciekawsza. 

Rola Scrum Mastera w STX-ie jest zbudowana wokół czterech obszarów: zespołu developerskiego, współpracy z PO, współpracy z klientem oraz bycia strażnikiem “zrozumienia i stosowania Scruma” w organizacji. Najważniejszym zadaniem jest wdrożenie ostatniego obszaru i połączenie go z pozostałymi – dzięki pełnemu zrozumieniu i stosowaniu Scruma przez wszystkich uczestników procesu powstają dobre produkty. Poza współpracą z zespołem oraz klientami, Scrum Masterzy w razie potrzeby wdrażają w kulturę zwinności nowych STX-owiczów 🙂 

Bardzo ważne jest też, aby pamiętać, że Scrum Master nie jest przełożonym, ani kierownikiem zespołu. Scrum Master jest na równi ze wszystkimi, a jego wsparcie polega na uczeniu, doradzaniu, zachęcaniu i wprowadzaniu coraz lepszych i usprawniających proces praktyk. 


Czas na development vs czas na wydarzenia scrumowe? Opowiedz o swoim doświadczeniu na podstawie STX-owych projektów.

Paweł Jankowski

W STX Next staramy się przestrzegać planu spotkań sugerując się wytycznymi, jakie można znaleźć w Scrum Guide, szczególnie zwracając uwagę na czas trwania każdego wydarzenia. Główną konsekwencją wynikającą ze stosowania ograniczonych czasowo spotkań jest mobilizacja całego zespołu na skupieniu się na najistotniejszych kwestiach, których dane wydarzenie dotyczy i unikania zbędnych dyskusji, które niepotrzebnie zajmują czas reszcie zespołu. 

Podstawowe cele tych wszystkich spotkań to przede wszystkim zapewnienie przejrzystości działań wszystkich członków zespołu (transparency), sprawdzenia czy wszystko idzie zgodnie z planem (inspection) oraz jak najszybszego dostosowania planu w przypadku, gdy tak nie jest (adaptation).    

Damian Winczewski

Pozwól, że przytoczę trochę teorii na początek 🙂 Przeglądając Scrum Guide znajdziemy informacje o zalecanych time-boxach dotyczących poszczególnych wydarzeń scrumowych. Przeliczając to liniowo na najczęściej spotykane długości sprintów otrzymamy czasy przedstawione w poniższej tabeli. Aż 12.5% czasu w sprincie spędzane jest na spotkaniach 😮

Scrum Guide

Sprint LengthPlanningDaily Refinement*ReviewRetrospectiveSumaProcentowo**
1 week (40h)<2h<15 minmax 10%1h<45min< 5h / 40h12.5% + Refinement
2 weeks (80h)<4h<15 minmax 10%<2h<1h 30 min< 10h / 80h  12.5% + Refinement
4 weeks (160h)<8h<15 minmax 10%<4h<3h< 20h / 160h12.5% + Refinement

* w razie potrzeby
** wydłużenie czasu trwania sprintu procentowo nie zmniejsza czasu poświęconego na wydarzenia

Ale to tylko teoria, ponieważ w praktyce stosujemy jedną ważną zasadę, którą zdradza nam Scrum Guide:  “Wydarzenia mogą zakończyć się, kiedy ich cel zostanie osiągnięty”.

No dobra, a teraz do konkretu – jak to jest w STX Next? Praktyka stosowana przeze mnie w projektach prowadzonych w gdańskim oddziale wygląda nieco inaczej i już tłumaczę dlaczego. 

Pierwsze różnice są zauważalne już na początku pracy w projekcie. Spotkania scrumowe przeważnie są krótsze, ponieważ czas trwania wszystkich spotkań oraz ich efektywność jest dobrym miejscem na usprawnienia. Przyjrzyjmy się dokładnie liczbom:

Sprint LengthPlanningDaily Refinement*ReviewRetrospectiveSumaPercentage
2 weeks(80h)<2h<15 min~1h 30min~1h~1h < 7h / 80h~9% + Refinement

* w razie potrzeby, nie w każdym sprincie

Co wniosły do procesu powyższe zmiany? Aż 90% czasu zespołu na development, do 10% czasu na wydarzenia Scrumowe i aż 0% czasu na zbędne spotkania. 

Dioniza Smura

W projektach, jakie mam okazję prowadzić w poznańskim oddziale STX Next, zawsze jest czas na development oraz wszystkie wydarzenia scrumowe. Zawsze mamy dailyrefinementy, a na koniec sprintu – review dla klienta, czyli przegląd sprintu. Mamy też retrospektywy. Zazwyczaj zespoły poświęcają na spotkania scrumowe mniej czasu, niż sugeruje to Scrum Guide. Wszystko zależy od tego, jak długo zespół pracuje razem oraz jakie ma wcześniejsze doświadczenia ze Scrumem każdy z jego członków.


Czym jest daily i czy oznacza, że pracuję w Scrumie?  

Damian Winczewski

Codzienne zespołowe spotkania daily nie oznaczają, że pracujesz w Scrumie. Ramy postępowania i wdrażania Scruma zawierają o wiele więcej reguł.

Jak już jesteśmy przy temacie daily, tzw. spotkaniach „na stojąco”, to chciałbym podzielić się kilkoma dobrymi praktykami:

  • W trakcie daily odpowiadamy sobie na trzy kluczowe pytania: 
    • Co zrobiłem/am wczoraj?
    • Co zrobię dzisiaj?
    • Czy widzę jakiekolwiek przeszkody do osiągnięcia celu sprintu jako zespół? 

Najczęściej zespoły skupiają się na odpowiadaniu na dwa pierwsze pytania, a tak naprawdę to trzecie jest najważniejsze.

  • Moją ulubiona dobrą praktyką w trakcie daily jest przeglądanie tablicy od prawej (Done) do lewej (Sprint backlog). Pozwala to nam, jako zespołowi, trzymać się kultury zamykania historyjek użytkownika (ang. user stories). Przy każdej historyjce zadajemy sobie pytanie o to, co musimy zrobić, by ją ukończyć i jakie mamy w tym przeszkody. To proste podejście pozwala uzyskać  ciągły przepływ informacji i zapobiec zamykaniu wszystkiego na koniec sprintu.

Toole i narzędzia, z których Ty i Twój zespół korzystacie na co dzień.  

Dioniza Smura

W moich projektach najczęściej przewijały się takie narzędzia jak Jira, Google Docs, Trello, Miro oraz draw.io

Damian Winczewski

O używanych narzędziach decyduje zespół wraz z klientem. Nie mamy tutaj narzuconych odgórnych standardów i wierzymy w to, że wybrane  w taki sposób narzędzia, dają lepsze efekty. 

Moja praca w roli Scrum Mastera mocno opiera się na statystykach i wykresach, dlatego w pierwszej kolejności wraz z zespołem korzystam z tego, co generuje nam Jira. Z kolei Jirę wykorzystujemy do zarządzania zadaniami (mówiąc szczerze jest to najbardziej popularne narzędzie tego typu). W kolejnych sprintach zwykle tworzę dodatkowe wizualizacje w Arkuszach Google, które pozwalają na szybkie udostępnianie i komentowanie 🙂

Na retrospektywach często korzystamy z fizycznych post-itów i scenariuszy dobranych do aktualnej sytuacji z m.in. retromat.org/en/. W momencie, gdy współpracuję z rozproszonym zespołem,  korzystam z funretro.io.


Kontakt z klientem po stronie Scrum Mastera czy zespołu?  Opowiedz o swoim doświadczeniu na podstawie STX-owych projektów. 

Dioniza Smura 

Scrum Master wspiera zespół w kontaktach z klientem. W większości przypadków SM pracuje z klientem nad rozwiązaniem bieżących problemów, które blokują pracę zespołu deweloperskiego, m.in. nieprzygotowany backlog, brak dostępów, niedziałające środowiska testowe, brak informacji czy niedostępność osób kontaktowych po stronie klienta.  

Niekiedy Scrum Master wspiera klienta w zakresie szkoleń scrumowych, ułożeniu procesów oraz wdrażania Scruma w swojej organizacji.

Damian Winczewski

Udział Scrum Mastera w komunikacji z klientem jest kluczowy, bowiem wspomaga budowanie relacji pomiędzy klientem, a zespołem w taki sposób, aby konkretne elementy produktu były dostarczane w umówionym czasie i w umówionym zakresie wymagań. 

Zbierane informacje z obu stron (od klienta oraz zespołu) dają mi wiedzę o tym, jak wspomóc zespół w kształtowaniu procesu wytwarzania i dostarczania produktu, by klient oraz potencjalny docelowy użytkownik z każdym sprintem otrzymywał wartościowy biznesowy przyrost do produktu. 

Przeczytaj również

Najciekawsze w Praca w STX Next

Nasz przepis na skuteczne wdrożenie Junior Developerów – STX Next Crash Course

Wejście do nowej organizacji, pierwsza praca czy zmiana pracy w momencie, gdy nie ma się jeszcze dużego doświadczenia, może być bardzo stresujące. Wszyscy doskonale pamiętamy swoje pierwsze zawodowe kroki, dlatego w STX Next bardzo mocno stawiamy na wysokiej jakości proces wdrożenia. W tym celu właśnie powstał STX Next Crash Course dla Junior Developerów, co jest […]

Praca Solutions Architecta oczami Produktowca

Jarek Feith pracuje z nami od kilku miesięcy jako Product Solutions Consultant. Swoim wieloletnim doświadczeniem produktowym wspiera Solutions Architectów – programistycznych ekspertów do zadań specjalnych. Jak wygląda ta współpraca oczami Jarka? O tym możecie przeczytać poniżej: Standardowa ścieżka kariery dla senior developera to najczęściej przejście na poziom zarządzania działem, zespołem – generalnie praca bardziej z […]

REST API w Pythonie: Flask czy FastAPI?

Tworzenie aplikacji internetowych, a w tym REST API, to chleb powszedni backend developerów. Dlatego praca z frameworkiem webowym powinna być szybka i prosta. Microframeworki to bardzo dobry start dla małych projektów, MVP czy nawet dużych aplikacji, które potrzebują REST API – a do nich zaliczają się m.in.: Flask i FastAPI. Flask jest jedną z najpopularniejszych […]

Czytaj więcej

Kontakt

Masz pytania?