Przejdź do:

1. 1. Czym się zajmuje Project Manager? 
2. 2. Zakres obowiązków Project Managera w projekcie  
3. 3. Z kim Project Manager ściśle współpracuje w projekcie? 
4. 4. Chcę zostać Project Managerem – jakie studia powinienem skończyć?  
5. 5. Jak zatem zdobywać kompetencje IT Project Managera? 
6. 6. Praca Project Managera – plusy i minusy  
7. 7. Jakie kompetencje powinien mieć kierownik projektu?
8. 8. Na jakie zarobki może liczyć Project Manager? 
9. 9. Gdybym mogła cofnąć czas, czy nadal zostałabym Project Managerem? 

Data pierwszej publikacji: 01.12.2020
Ostatnia aktualizacja: 06.09.2023

Czym się zajmuje Project Manager? 

IT Project Manager to rola, na którą często trafimy w projektach rozwoju oprogramowania. Wiele osób, zwłaszcza na początku przygody w branży IT, może się jednak zastanawiać: czym dokładnie zajmuje się kierownik projektu? Jakie kompetencje powinien posiadać i jak nim zostać? Czy znajomość języka angielskiego jest wymagana na tym stanowisku? Wreszcie: ile zarabia Project Manager?

Zatem czym zajmuje się PM? W zasadzie…. To zależy! Dlaczego? Większość z was zapewne zadaje sobie kuriozalne pytanie:

„Co w takim razie oznacza projekt?” 

Bo przecież, logicznie rzecz biorąc, to w zasadzie projektem może być np. budowa domu, przeprowadzanie kampanii marketingowej, wydanie nowego modelu iPhone’a, jak również przeprowadzka czy też wyjazd na wakacje! Każde z nich posiada konkretny cel, początek i koniec, a aktywności w ramach przedsięwzięcia są ze sobą powiązane w złożony sposób.  

Manager odpowiada za zorganizowanie i przeprowadzenie wszystkich potrzebnych aktywności celem osiągnięcia zamierzonego rezultatu. Zatem to, kim faktycznie będzie Project Manager, zależy od miejsca i sytuacji. 

Natomiast w kontekście pracy zawodowej będzie zależało to od danego przedsiębiorstwa, jego branży, domeny, rozmiaru czy też konkretnych specjalizacji, a nawet oczekiwań pracodawcy względem osoby zajmującej stanowisko Project Managera. Oczywiście w teorii znajdziemy wiele spójnych definicji takiego stanowiska, natomiast w rzeczywistości, jak wiadomo – może (nie musi!) być nieco inaczej.  

Zakres obowiązków Project Managera w projekcie  

Myślę, że odpowiedzialność jest najlepszą definicją tej roli. Dodatkowo zawsze uważałam, że PM-owanie jest pełnieniem roli mikroprzedsiębiorcy. Notabene każdy projekt jest przedsięwzięciem, a praca Project Managera to odpowiedzialność za to przedsięwzięcie od początku do końca. 

Poszczególne aktywności w ramach projektu co do zasady są zaplanowane, natomiast w większości przypadków w trakcie realizacji pojawiają się sprawy, które przewidywaliśmy, że mogą się wydarzyć (ryzyka), oraz takie, które nikomu wcześniej do głowy by nie przyszły. Od sytuacji gospodarczych po konflikty personalne. 

Lista zdarzeń Project Managera często jest naprawdę nieskończona, natomiast my, jako PM-owie, niezależnie od wszystkiego musimy się z tym zmierzyć, tak aby dowieźć cel. Oczywiście mamy ku temu zaplecze zasobów, narzędzi i to nie jest tak, że zostajesz ze wszystkim sam. Project Manager może liczyć na wsparcie innych, jednak zdecydowana większość zależy od ciebie. No, i jeszcze… Oprócz działki samego zarządzania projektami jest również spora część administracji do wykonania i rzeczy, które trzeba nadzorować: rozliczenia, raportowanie, dokumentacja itd. – najczęściej należy to do obowiązków managera projektu i osoba na tym stanowisku powinna posiadać umiejętności z różnych obszarów. Chyba że ma na tyle komfortową sytuację, że w zespole jest do tego dedykowana inna osoba.

Z kim Project Manager ściśle współpracuje w projekcie? 

Przede wszystkim z zespołem powołanym do realizacji projektu oraz zespołem klienta. Wszystko zależy od organizacji, czy też struktury tych zespołów. Im mniejszy zespół, tym współpraca jest ściślejsza. 

Chcę zostać Project Managerem – jakie studia powinienem skończyć?  

Mogę się mylić, ale wydaje mi się, że wybór zawodu wynika raczej z naszych doświadczeń, możliwości, które nas spotkały i indywidualnych predyspozycji, aniżeli zwykłego postawienia sobie celu w stylu: „W przyszłości zostanę lekarzem”. 

Zapewne każdemu z nas w najmłodszych latach szkolnych przedstawiano zadanie: „Napisz wypracowanie o tym, kim zostaniesz w przyszłości?”. No i umówmy się… Skąd dziecko może wiedzieć, kim zostanie w przyszłości? Im wyższy etap edukacji, tym bardziej zawężamy obszar zainteresowań, natomiast określenie zawodu może nastąpić na bardzo rozmaite sposoby.  

Jedni idą na studia, wiedząc, czym chcą się w życiu zajmować. Inni dowiedzą się tego na studiach, a jeszcze inni – dojdą do takich wniosków po latach zawodowej pracy, wybierając np. kierunkowe studia podyplomowe. Nie ma reguły, bo każdy ma swój indywidualny czas. 

Jak zatem zdobywać kompetencje IT Project Managera? 

Ważne, aby na etapie studiów (i nie tylko) stwarzać sobie jak najwięcej możliwości rozwoju oraz testować samego siebie. Dlatego też osobiście zachęcam do aktywności poza studiami – koła zainteresowań, organizacje pozastudenckie, fundacje itp. Tam możemy doświadczać różnych ról, rozwijać umiejętności i realnie się przekonać, w jakich zawodach i zajęciach najlepiej się odnajdujemy, a które będą nas najzwyczajniej męczyć.  

Dzięki nim dowiemy się na przykład, czy zarządzanie ludźmi sprawia nam przyjemność i przychodzi lekko, czy raczej wolimy otrzymać konkretne zadanie i być odpowiedzialni za jego wykonanie.  

Dodatkowo podczas wolontariatów mamy okazję poznać swoje umiejętności w zakresie organizacji czasu pracy, przekuć pozyskaną teorię na rzeczywistość. To nierzadko jest bardzo trudne do osiągnięcia w programie studiów. Ponadto tego typu aktywności są szalenie doceniane, niektórzy pracodawcy wymagają takich doświadczeń. Etap przygotowań do zawodu Project Managera nieraz może przynieść konkretne oferty pracy, pozwolić dotrzeć bezpośrednio do pracodawców i otrzymać propozycję pierwszej pracy.  

Dlatego też uważam, że choć studia są jak najbardziej ważne, to w ich trakcie warto zaktywizować się nieco szerzej i poświęcić trochę czasu, zaangażowania i energii na często nieodpłatne obowiązki. To one zazwyczaj procentują w przyszłości, klarują i racjonalizują decyzje dotyczące naszego rozwoju oraz dają nową perspektywę. 

Praca Project Managera – plusy i minusy  

Wszystko zależy od preferencji danej osoby oraz tego, co ją motywuje – takie stwierdzenie w zasadzie można odnieść do każdego stanowiska. Warunki pracy, zakres odpowiedzialności, typy projektów, jakie przekaże nam pracodawca, mają ogromny wpływ na dane stanowisko. Jestem daleka od generalizowania, dlatego też nie chcę jasno definiować, co jest plusem, a co minusem takiego stanowiska, ponieważ każdy może dany aspekt skategoryzować zupełnie inaczej. 

Jakie kompetencje powinien mieć kierownik projektu?  

• kompetencje miękkie – Project Manager powinien się wyróżniać umiejętnościami interpersonalnymi, praca na tym stanowisku to przede wszystkim praca z ludźmi.  
• znajomość metodyk zarządzania projektami – na pewno na swojej drodze spotkasz różne podejścia i metodyki pracy, takie jak np. PRINCE2, frameworki Agile czy Waterfall. 

• znajomość narzędzi – Jira, Trello, Asana to przykładowe narzędzia wykorzystywane w pracy projektowej. 
• certyfikaty – jeżeli jesteś na początku drogi, z pewnością zastanawiasz się, jaki certyfikat jest najlepszy. Na pewno warto zainteresować się certyfikatami IPMA oraz na bieżąco przeglądać ofertę szkoleń w zakresie zarządzania projektami. 
• znajomość języków obcych – jeżeli rozważasz karierę w międzynarodowym środowisku, znajomość języka angielskiego będzie przydatna. W branży IT często realizujemy projekty dla zagranicznych klientów.  

Na jakie zarobki może liczyć Project Manager?

Project Management to szerokie pojęcie i trudno jednoznacznie odpowiedzieć na to pytanie. Pensja zależy od takich czynników jak: 

• Lata stażu 
• Kompetencje 
• Rodzaj umowy (B2B lub umowa o pracę) 
• Branża 
• Wielkość firmy 
• Województwo 

Myśląc o przebranżowieniu i rozpoczęciu kariery jako PM, warto wziąć pod uwagę, że tak jak pewnie w każdym obszarze, Junior Project Manager nie otrzyma na start takiej stawki, jak dobry Project Manager otrzaskany w projektach. To, ile Project Manager zarabia, zależy od naprawdę wielu czynników. W ostatnich latach wiele osób decyduje się na pierwsze kroki w sektorze IT ze względu na możliwości rozwoju kariery i stabilność zatrudnienia. Jeżeli interesują cię bardziej konkretne stawki, w internecie nie brakuje porównywark, np. Money.pl  

Gdybym mogła cofnąć czas, czy nadal zostałabym Project Managerem? 

Zdecydowanie! Uważam, że PM to atrakcyjne stanowisko dla osób, które noszą w sobie „ducha przedsiębiorczości”, które są proaktywne i zawsze garnęły się do organizacji wszelkiego rodzaju przedsięwzięć. Jeśli więc nie boisz się zmian, a wręcz lubisz, kiedy dookoła dużo się dzieje, to jest to pierwszy pozytywny etap samoweryfikacji w kierunku zostania Project Managerem. Powodzenia!  

Przejdź do:

1. 1. Czym jest Pair Programming
2. 2. Korzyści programowania w parach
3. 3. Programowanie w parach – techniki
4. 4. Czy to faktycznie działa?
5. 5. Pair Programming online
6. 6. Podsumowanie

Czym jest Pair Programming

Pair Programming ewoluował przez dekady, zyskał jednak na popularności dzięki metodologii Extreme Programming (XP), która została sformalizowana przez Kenta Becka w książce „Extreme Programming Explained: Embrace Change”. Istnieje kilka technik programowania w parach, a każda
z nich charakteryzuje się innymi założeniami. Uogólniając, całość polega na współpracy dwóch programistów, współdzielących jedną stację roboczą, którzy razem pracują nad rozwiązaniem danego problemu programistycznego. Programista aktualnie piszący kod to tzw. driver, drugi to navigator, zwany również obserwatorem – on także aktywnie uczestniczy w procesie twórczym, jednak skupia się bardziej na ogólnym kierunku oraz na ciągłej weryfikacji kodu napisanego przez „kierowcę”.

Korzyści programowania w parach

Z moich obserwacji wynika, że programiści pracujący w parach wzajemnie wywierają na siebie pewnego rodzaju presję. Zdają sobie oni sprawę, jak cenny jest czas ich partnerów, przez co chcą go maksymalnie wydajnie wykorzystać. W zależności od zastosowanej techniki (opowiem o nich w dalszej części artykułu) korzyści programowania w parach mogą być następujące:

• lepsza jakość kodu, przy czym istotne jest, aby osoba pisząca aktualnie kod formułowała swoje myśli na głos – często pozwala to rozwiązać dany problem, nawet bez znacznej ingerencji drugiej strony,
• łatwiejsze dzielenie się wiedzą domenową między członkami zespołu,
• szybszy rozwój mniej doświadczonych programistów dzięki parowaniu ich z tymi bardziej doświadczonymi,
• potencjalnie większa odporność na zewnętrzne zakłócenia – jedna osoba z pary zawsze może pozostawać skupiona na zadaniu, podczas gdy druga może np. uczestniczyć w zewnętrznej dyskusji z pozostałymi członkami zespołu.

Należy jednak pamiętać, że programowanie w parach jest trudne, bywa wyczerpujące, wymaga samodyscypliny i pokory, a także umiejętności udzielania i dawania feedbacku. Często już sama świadomość, że ktoś przez część dnia będzie nam zaglądał przez ramię i oceniał to, co robimy, może zdezorganizować wewnętrzny spokój. No bo kto nie lubi czasem założyć słuchawek, odciąć się od otoczenia i zanurzyć w jakimś ciekawym problemie?

Programowanie w parach – techniki

Dobre praktyki

Zanim opiszę poszczególne techniki programowania w parach, rzecz najistotniejsza, niezależna od stosowanej techniki: chodzi o robienie przerw oraz oraz nieprzeznaczanie na programowanie w parach zbyt dużo czasu w ciągu dnia – celem jest tu utrzymanie wydajności. Zaczynając od krótkich sesji (1-2 godz.), z czasem można zwiększać liczbę godzin poświęconych na Pair Programming, jednak według mnie dobrze jest nigdy nie przekraczać 5-6 godz. Jak wspomniałem wcześniej, do wyboru mamy kilka technik, każda z nich ma swoje wady i zalety. Daną technikę należy dobierać do konkretnej sytuacji. Proces programowania w parach będzie wyglądał inaczej, jeżeli planujemy przekazać wiedzę lub przeprowadzić onboarding nowej osoby w zespole, a inaczej, jeżeli chcemy zaimplementować jakąś skomplikowaną funkcjonalność. Poniżej opiszę te, z którymi ja się spotkałem i które – według mnie – powinny znaleźć się w arsenale każdego szanującego się programisty.

Backseat navigator

Prawdopodobnie najpopularniejsza metoda, stosowana zazwyczaj instynktownie. Jest wykorzystywana w sytuacji, gdy rozwiązując jakiś problem, doszliśmy do ściany. Bywa, że tak bardzo skupiamy się na znalezieniu rozwiązania, że nie widzimy alternatywnych możliwości, dochodzimy do ślepej uliczki i koniec. W takim wypadku prosimy innego programistę o wsparcie – taka osoba będzie zdolna spojrzeć na naszą zagwozdkę z innej perspektywy. Z drugiej strony, wariant ten jest idealny dla mniej doświadczonych programistów pod kątem nauki nowych umiejętności. Mamy wtedy do czynienia z relacją nowicjusz – ekspert. Jedna strona pisze kod (nowicjusz), druga natomiast pełni rolę wsparcia / mentora (ekspert).

Driver-navigator

Klasyczny Pair Programming, zderzenie dwóch różnych perspektyw na kod. „Kierowca” (ang. driver) zajmuje się pisaniem kodu, skupia się na detalach implementacyjnych, nawigator (ang. navigator) natomiast myśli o rozwiązaniu bardziej ogólnie, jest partnerem do dyskusji, decyduje o kierunku, wychwytuje braki w implementacji oraz przypadkach testowych (real-time code review). Według mnie technika ta jest idealna do rozwiązywania złożonych problemów, gdzie mnogość reguł biznesowych znacząco wydłużyłaby samodzielne próby rozwiązania problemu.

Ping-pong

Bywa, że od początku znamy kierunek, w którym powinniśmy pójść, a dany problem nie jest dla nas wyzwaniem. Takie arcynudne zadania również wymagają od nas profesjonalnego podejścia. Jeżeli TDD (Test-Driven Development) nie jest nam obce, to ta technika sprawdzi się idealnie. Całość polega na naprzemiennym pisaniu testów oraz implementacji. Ping – pierwszy programista pisze nieprzechodzący test, pong – drugi programista pisze implementację, sprawiając, że test zaczyna przechodzić. Po tym następuje faza refaktoryzacji i cały proces rozpoczyna się od nowa.

Czy to faktycznie działa?

Teoria teorią, ale czy Pair Programming faktycznie jest tak wyjątkowy i zawsze da nam oczekiwane efekty?

Jak zwykle, to zależy. Osobiście miałem okazję stosować głównie dwie pierwsze techniki, niestety – rzadziej, niż bym chciał. Spowodowane jest to faktem, że w świecie IT mamy wokół siebie wielu ludzi, często świetnych specjalistów, jednak różnica charakterów jest czynnikiem, który znacząco ogranicza powodzenie wspólnego programowania.

Trzeba pamiętać, że przynoszący rezultaty Pair Programming to przede wszystkim budowanie relacji
z członkami zespołu oraz przełamywanie wszelkich barier komunikacyjnych. Poniżej przedstawię kilka wniosków z mojej przygody z Pair Programming, które według mnie poprawiają efektywność całego procesu:

• dobrze jest określić cel sesji, który będzie można zweryfikować po jej zakończeniu,
• innym ważnym aspektem jest ustalenie przerw oraz częstotliwość zmian,
• jeżeli rozwiązujemy jakiś skomplikowany problem, pierwsza w rolę nawigatora niech wcieli się osoba z większą wiedzą domenową. W przypadku zadania typowo technicznego, niech to będzie osoba z większym doświadczeniem / umiejętnościami,
• będąc w roli drivera, komunikujmy na głos wszystko, co robimy – niejednokrotnie samo mówienie na głos o danym problemie pozwoliło mi znaleźć rozwiązanie.

Te rzeczy sprawdziły się u mnie, jednak zdecydowanie jestem daleki od twierdzenia, że takie podejście jest idealne. Moja sugestia jest taka, aby po prostu zacząć, wyciągać wnioski i próbować usprawniać cały proces tak, aby czuć się komfortowo i czerpać z tego satysfakcję.

Pair Programming online

Pytanie, które pojawia się często w kontekście zdalnego programowanie w parach, brzmi: czy to w ogóle ma sens?

Odpowiedź brzmi: zdecydowanie tak. O ile nasz zespół nie pracuje w sposób asynchroniczny, to według mnie zdalny Pair Programming nie różni się w zasadzie niczym od tego standardowego, przeprowadzanego w biurze. Co więcej, w dzisiejszych czasach, kiedy wszyscy przenieśliśmy się z biur do domów, może nieść za sobą ogrom korzyści, wymusza bowiem kontakt z innymi członkami zespołu, który z reguły jest bardziej naturalny w środowisku biurowym – rozmawiamy w pokoju, na korytarzu czy w kuchni. Jeżeli chodzi o narzędzia, istnieje ich wiele i tak naprawdę to, które wybierzemy, zależy od osobistych preferencji. Jednym wystarczy Google Meet, Skype czy jakiekolwiek inne narzędzie z opcją udostępniania ekranu, inni natomiast, chcąc ze zdalnego programowania w parach wyciągnąć jak najwięcej, skorzystają w tym celu z dedykowanego narzędzia. W zależności od preferowanego edytora kodu będą to Floobits, Saros, Live Share czy Teamhub.

Podsumowanie

Niestety, pomimo tego, że większość osób zajmujących się zawodowo programowaniem słyszała o programowaniu w parach, to ciągle można zauważyć, że jest ono traktowane po macoszemu. Moim zdaniem wynika to poniekąd z faktu, że korzyści z jego stosowania nie zawsze są widoczne od razu. Jest to umiejętność, która wymaga systematycznego stosowania, dlatego warto regularnie poświęcać jej część czasu przeznaczonego na kodowanie. Po zakończonej sesji wskazane jest spisać to, co poszło dobrze, a co nie zadziałało, dać sobie nawzajem feedback, tak aby kolejne sesje były lepsze od poprzednich.

Przejdź do:

1. 1. Metodyki zwinne i klasyczne
2. 2. Metodyki zwinne – Scrum
3. 3. Metodyki zwinne – rodzaje
4. 4. Metodyki zwinne zarządzania projektami – którą wybrać?
5. 5. Podsumowanie

Metodyki zwinne i klasyczne

Podejście klasyczne, tzw. kaskadowe, wiąże się m.in. z planowaniem, etapowością, wymaga dokumentacji i monitorowania postępów oraz stosowania odpowiednich technik w zakresie zarządzania ryzykiem czy budżetem. Przykładami podejść klasycznych w zarządzaniu projektami są PRINCE2 czy PMBOK.

Zwinne podejście było obecne w codziennym życiu od bardzo dawna, przykładowo wykorzystywano je w masowej produkcji samochodów na początku XX wieku czy w obszarze zapewniania jakości. Dopiero na początku XXI wieku zostało oficjalnie opisane przez Jeffa Sutherlanda i Kena Schwabera w dokumencie pod nazwą „Scrum Guide”. Metodyki zwinne skupiają się na elastycznym podejściu i iteracyjnej realizacji projektu, zakładając, że nie wszystko można przewidzieć i zaplanować, a ważniejsze jest reagowanie na zmiany niż trzymanie się z góry ustalonego planu.

Według ostatniego badania „State of Agile 2020” Scrum i jego warianty są najchętniej wykorzystywaną metodyką zwinną w organizacjach (według 58% respondentów). Czym więc jest Scrum?

Zobacz również: Agile Coach vs Scrum Master – kogo potrzebuje mój zespół?

Metodyki zwinne – Scrum

Scrum to m.in.:

• elastyczne i proaktywne podejście do zarządzania projektami,
• podział projektu na samoorganizujące się niezależne zespoły,
• podejście, w którym zespoły posiadają wszystkie kompetencje do ukończenia zadań,
• iteracyjny sposób pracy oparty na 3 filarach, jakimi są inspekcja, adaptacja i przejrzystość.

Poniższa ilustracja przedstawia role i proces w Scrumie:

Metodyki zwinne – rodzaje

Jak to się odnosi do pozostałych podejść zwinnych, tj. SAFe, LeSS, Nexus? Po co korzystać z innego podejścia? Jakie są ich przeznaczenia, podobieństwa i różnice?

Przeznaczenie:

• Scrum
  • Nazwa pochodzi z gry w rugby, oznacza formację zawodników, tzw. młyn.
  • Proste, krótkie projekty, jeden lub kilka produktów, mała liczba osób (kilkanaście, kilkadziesiąt osób), brak lub mała liczba zależności pomiędzy zespołami.
• SAFe:
  • Angielska nazwa: Scaled Agile Framework, czyli skalowany Scrum.
  • Złożone projekty lub programy przeznaczone do realizacji na wiele lat, rozbudowany produkt, bardzo duża liczba osób (kilkaset lub nawet ponad tysiąc osób), liczne powiązania pomiędzy zespołami (techniczne i merytoryczne aspekty).
• LeSS:
  • Angielska nazwa: Large Scale Scrum, czyli skalowany Scrum w dużej skali.
  • Projekty, w których można zastosować jeden Backlog Produktu dla wszystkich zespołów, małe zespoły, jeden Product Owner dedykowany dla wszystkich zespołów. Główny cel to uproszczenie procesów, ról i wydarzeń.
• Nexus:
  • Z języka angielskiego nazwa oznacza „Ogniwo”.
  • Projekty, w których istnieje potrzeba integracji oraz zminimalizowania liczby zależności pomiędzy zaangażowanymi osobami. Nexus skupia się na skalowaniu zespołów w taki sposób, by usprawniać procesy i komunikację, np. poprzez przypisywanie mniejszej liczby osób do pracy nad danym zadaniem. Podobnie jak LeSS, to podejście ogranicza się do jednego Backlogu i wspólnego Product Ownera. Framework ma dodatkowo „Integration Team”, który pomaga zsynchronizować prace wszystkich zespołów i wprowadzać usprawnienia.

Sposób pracy (różnice):

• Scrum:
  • Samodzielna praca w małych zespołach.
  • Zespoły mają własne spotkania, w tym planowanie i własne Review.
  • Wdrożenie produktu na produkcję odbywa się niezależnie.
• SAFe:
  • Wprowadza podział projektu na Agile Release Trains (ART), które zawierają w sobie kilka zespołów pracujących nad podobnymi funkcjonalnościami, np. tworzenie produktu, płatności, integracja, księgowanie.
  • Zawiera poziomy zarządcze:
    • Portfolio Level – najwyższy poziom, zawiera zasady, praktyki, role potrzebne do zarządzania projektem. W tym miejsce jest definiowana strategia.
    • Value Streams – definiuje serie kroków w organizacji, które są wykorzystywane do zbudowania rozwiązań dostarczających ciągle wartość dla klienta. Definiuje również i realizuje cele z Portfolio Level.
    • Program Backlog – uporządkowana według priorytetów lista biznesowych funkcjonalności, które zostały zanalizowana i przeznaczone do stworzenia przez wszystkie zespoły w projekcie.
    • Team Backlog – część zadań z listy biznesowych funkcjonalności, które pochodzą z Program Backlog i są przeznaczone do realizacji przez pojedynczy zespół.
  • Review odbywa się wspólnie z innymi zespołami w ramach tego samego ART.
• LeSS:
  • Jeden wspólny Backlog Produktu dla wszystkich zespołów.
  • Jeden Product Owner dla wszystkich zespołów.
  • Wspólne DoD (Definition of Done).
• Nexus:
  • Jeden wspólny Backlog Produktu dla wszystkich zespołów.
  • Jeden Product Owner dla wszystkich zespołów.
  • Wspólne DoD (Definition of Done).
  • Wprowadza “Integration Team” koordynujący i usprawniający pracę.

Role, wydarzenia, dobre praktyki

• Scrum
  • Role: Zespół składa się z Produkt Ownera, Scrum Mastera i Zespołu Developerskiego.
  • Wydarzenia (wspólne również dla pozostałych frameworków): Sprint, Planowanie Sprintu, Daily Scrum, Review, Retrospekcja.
  • Dobre praktyki: zespoły spotykają się wspólnie, żeby omówić przyszłe i nowe funkcjonalności (Refinement) oraz żeby porozmawiać na temat zeszłych Sprintów i w celu wybrania elementów do poprawy z codziennej pracy (Retrospektywa).
• SAFe:
  • Role: Product Owner, Product Management, Solution Management, Portfolio Management; organizacyjne: Scrum Master, Release Train Engineer, Solution Train Engineer; techniczne: Development Team, System Architect, Solution Architect, Enterprise Architect.
  • Wydarzenia: Program Increment Planning – wspólne spotkanie wszystkich zespołów (zazwyczaj 2-3-dniowe) w celu zaplanowania pracy na kolejne wydanie. Scrum of Scrums – spotkanie dla reprezentantów zespołów w ramach każdego ART w celu synchronizacji pracy i przekazania informacji o zależnościach i błędach. Dodatkowy Sprint „Innowacja i Planowanie” przeznaczone na rozwój osobisty, szkolenia i planowanie kolejnego wydania.
  • SAFe podkreśla znaczenie głównych funkcjonalności (jako MVP) i wprowadza dodatkowy zakres z niższym priorytetem na dostarczenie jako „cele poboczne”.

• LeSS:
  • Role: te same co w Scrumie.
  • Wydarzenia: te same co w Scrumie, przy czym Planowanie Sprintu dzieli się na dwie części – w pierwszej spotykają się Product Owner i reprezentanci zespołów, a w drugiej części wszyscy członkowie zespołu. W celu przekazywania informacji o postępie prac jeden członek zespołu może opcjonalnie uczestniczyć w Daily Scrum w innym zespole.
• Nexus:
  • Role i wydarzenia są bardzo zbliżone do podejścia LeSS. Planowanie Sprintu polega na wybraniu ze wspólnego Backlogu przez każdy zespół zadań do pracy w porozumieniu z pozostałymi zespołami. Framework wprowadza Scrum of Scrums (podobnie jak SAFe) oraz Integration Daily, żeby zidentyfikować przeszkody i rozwiązać konflikty.
  • Dodatkowo wprowadzony zostaje „Integration Team”, który składa się z Product Ownera, Scrum Mastera i jednego lub więcej reprezentantów każdego zespołu. Celem jest koordynacja pracy i procesów wszystkich zaangażowanych zespołów.

Metodyki zwinne zarządzania projektami – którą wybrać?

Powyższe informacje opisują szczegóły zwinnych podejść: Scrum, SAFe, LeSS i Nexus. Który będzie najlepszy dla Twojego projektu? To zależy! Celowo nie wskazuję dominacji żadnego frameworku nad innymi. Przy wyborze sposobu pracy we własnej organizacji należy kierować się przede wszystkim cechami organizacji, celem i planami na przyszłość. Decydując się na daną metodykę zwinną, warto wziąć pod uwagę takie kryteria jak:

• liczba osób,
• złożoność produktów,
• częstotliwość wydań,
• czas trwania projektu.

Podsumowanie

Czasem lepiej usprawnić procesy w już istniejącym rozwiązaniu, niż całkowicie zmieniać framework czy też wracać do podejścia „Waterfall”. Obecnie istnieje wiele możliwości kombinacji i połączeń, a organizacje mogą dodawać lub usuwać pojedyncze elementy (role lub wydarzenia), aby usprawnić bieżącą pracę. Takie podejście jest całkowicie elastyczne – nie oznacza odrzucenia założeń Scruma, ale wykorzystanie jego potencjału odpowiednio do potrzeb. Przed podjęciem decyzji o zmianie warto wykonać dokładną analizę i porozmawiać z osobami, które już wykorzystują dane podejście. Umożliwi to pełny przegląd obecnej sytuacji i określeniu celu, który chcemy osiągnąć poprzez zmianę.

Przejdź do:

1. 1. Retrospektywa w Scrumie – co to takiego?
2. 2. Co obejmuje retrospektywa?
3. 3. Retrospektywa – zanim zaczniesz
4. 4. Porządna retrospektywa – dobre praktyki
5. 5. Kto uczestniczy w retrospektywie?
6. 6. Retrospektywa – unikaj tych błędów
7. 7. Podsumowanie

Retrospektywa w Scrumie – co to takiego?

Zacznijmy od wyjaśnienia słowa „retrospektywa”. Według słownika języka polskiego (SJPD) jest to „spojrzenie wstecz, w przeszłość, fakty z przeszłości”.

Odwołując się do Scrum Guide’a, retrospektywa to ciągły proces udoskonalenia, a nie pojedyncze spotkanie organizowane w trakcie jednego Sprintu. W praktyce oznacza to, że za każdym razem, gdy zauważymy nieproduktywne podejście do pracy czy zidentyfikujemy nietrafione decyzje, możemy przerwać ten stan rzeczy od razu. Nie musimy zatem czekać na formalne spotkanie kończące Sprint. Okazją do zauważenia dysfunkcji w zespole czy organizacji są spotkania takie jak np. Codzienny Scrum (eng. Daily Scrum) czy bieżące indywidualne rozmowy z członkami zespołu.

Dowiedz się, jak Scrum Master może wesprzeć realizację Twojego projektu IT! Przeczytaj artykuł: Rola Scrum Mastera w procesie wytwarzania oprogramowania

Co obejmuje retrospektywa?

Jak widać, retrospektywa nie musi dotyczyć słownikowych „faktów z przeszłości”. Zakres oczekiwań wobec popularnego „retro” także jest szeroki. W trakcie retrospektywy można poruszyć wszelkie zagadnienia dotyczące:

• Sposobu prowadzenia spotkań
• Czasu spotkań, dni/godzin ich rozpoczęcia
• Dostępności osób z zespołu projektowego (tj. Product Owner, Scrum Master, developerzy)
• Współpracy z innymi interesariuszami zaangażowanymi w rozwój produktu
• Narzędzi pracy (można poruszyć takie kwestie jak: brak narzędzi, brak dostępu, sugestie skorzystania z nowych narzędzi)
• Wypracowania dobrych praktyk, własnych wewnętrznych zasad
• Integracji zespołu
• Podziękowania za wspólną pracę

Retrospektywa – zanim zaczniesz

Co powinno zostać zrealizowane przed retrospektywą w zespole? Poniższe punkty to głównie zadania Scrum Mastera, jednak każdy członek zespołu jest odpowiedzialny za całokształt retrospektywy.

Zarezerwuj czas

Ustal ściśle określony czas na spotkanie i trzymaj się go

Przygotuj agendę

Zespół Developerski powinien podchodzić do retrospektywy z wyszczególnieniem kilku sytuacji dotyczących zakończonego Sprintu lub okresu dłuższego niż jeden ostatni Sprint. Pomocne będzie wypunktowanie kilku sytuacji, do których dana osoba chciałaby się odnieść.

Przygotuj przestrzeń do wyrażenia opinii

• Na miejscu: jeżeli zespół ma możliwość spotkać się w tym samym miejscu, w przeprowadzeniu retrospektywy pomocne będą: interaktywne tablice scrumowe (Scrum Board) lub fizyczne tablice, kartki i markery.
• Zdalna retrospektywa: w czasach pandemii Zespoły Developerskie coraz częściej korzystają z narzędzi, które umożliwiają efektywną pracę. W spotkaniu online pomocne będą Whiteboard w aplikacji Skype / Teams. Istnieje też wiele dedykowanych narzędzi, takich jak: Miro, Funretro, TeamRetro, Sprint Boards czy Retrium.

Porządna retrospektywa – dobre praktyki

• Rozpocznij spotkanie od rozluźnienia atmosfery. Bez względu na to, czy pracujecie na miejscu, czy retrospektywa odbywa się online, dobrą praktyką jest poruszenie na początek tematu niezwiązanego z pracą. Postaw na neutralne tematy: np. sport, plany wakacyjne, urządzanie mieszkania. Czasem warto rozważyć zorganizowanie krótkiej gry.
• Realizuj punkty z agendy, zwracając uwagę na to, aby każdy członek zespołu mógł się wypowiedzieć. Upewnij się, że do poszczególnych zadań zostały przypisane osoby odpowiedzialne za ich realizację w wyznaczonym terminie. Opcjonalnie można daną akcję zaraportować np. w Jirze i w ten sposób śledzić jej postęp, dodawać komentarze i uzupełniać o nowe szczegóły.
• Zaplanuj czas na podsumowanie. Podsumowanie spotkania to ważny element dobrej retrospektywy. Podziękuj innym za wspólną pracę w zakończonym Sprincie.
• Wciel ustalenia w życie. Po spotkaniu w zespole nie pozostaje nic innego, jak wcielić ustalenia z retrospektywy w życie i trzymać rękę na pulsie, monitorując realizację wyznaczonych punktów.

Kto uczestniczy w retrospektywie?

Scrum Master i Product Owner uczestniczą w spotkaniu na tych samych zasadach co pozostałe osoby z zespołu. Scrum Master pełni szczególną rolę, ponieważ zazwyczaj prowadzi retrospektywę. Natomiast ważne jest, aby zespół uczył się samodzielności i podczas tej sesji był zaangażowany i w sposób otwarty, bez skrępowania, dzielił się spostrzeżeniami po ostatnim Sprincie i sugerował swoje pomysły.

Nawet jeśli tylko jedna osoba ma jakiś problem, staje się on problemem całego zespołu. Dlatego tak ważne jest, aby wspólnie przemyśleć sposoby wyeliminowania trudności i poprawy sytuacji. Cały zespół powinien pomóc ustalić priorytet zgłoszonych punktów poprzez głosowanie i wybór najważniejszych zagadnień.

Retrospektywa – unikaj tych błędów

Jako Scrum Master zwracam uwagę na to, aby retrospektywa była prowadzona w ciekawy i angażujący sposób. Jednak zdarza się, że retrospektywa może nie przynosić oczekiwanych efektów. Jaka jest przyczyna takiego stanu rzeczy? Najczęstsze błędy spotykane przy retrospektywie to:

• Brak czasu na retrospektywę – a ten często skutkuje… brakiem stosowania retrospektywy w zespole/organizacji. W natłoku zadań może pojawić się pokusa przełożenia czy odwołania retrospektywy. Warto jednak pamiętać, że czas na nią poświęcony zaowocuje większą efektywnością w realizacji zadań i lepszą przejrzystością w organizacji.
• Monotonny format – aby retrospektywa nie była uważana przez uczestników za „zło koniecznie”, warto zadbać o ciekawy, angażujący format, np. włączenie kamer, żeby zespół mógł się zobaczyć, przeprowadzenie Quizu, ankiety na początku spotkania, głosowanie na najlepsze zadanie oraz kilka minut poświęcone na podziękowania za wspólną pracę.
• Brak wizualizacji danych – obraz jest wart tysiąca słów – odpowiednia wizualizacja pomoże zaangażować uczestników, np. raport ze Sprintu z informacją o ilości zakończonych/niezakończonych zadań, średnia ilość punktów z ostatnich Sprintów czy ilość pozostałego zakresu do zrealizowania.
• Niezaangażowany zespół, cisza na spotkaniach – członkowie Zespołu Developerskiego pracują na wspólny sukces, dlatego ich zaangażowanie i aktywne uczestnictwo jest niezbędne.
• Spotkanie zdominowane przez jedną osobę – zdarza się, że jedna osoba jest szczególnie aktywna, podczas gdy inni członkowie zespołu nie mają szansy się wypowiedzieć. Rolą Scrum Mastera jest upewnić się, że każdy ma szansę aktywnie uczestniczyć w spotkaniu.

Gdzie można wykorzystać retrospektywę?

• Rozwój oprogramowania – branża tworząca oprogramowanie komputerowe z powodzeniem korzysta z metodyk zwinnych, takich jak Scrum. Retrospektywa pomaga pokonywać przeszkody i usprawniać współpracę w zespole, a tym samym wpływa na jego efektywność.
• Edukacja – zarządzanie zmianą, jakie umożliwia retrospektywa, to także dobra opcja dla szkół. Retrospektywa może być stosowana na poziomie klas, dając nauczycielom możliwość sprawdzenia przerobionego materiału.
• Produkcja – retrospektywa może z powodzeniem być wykorzystywana w branży automotive. Przykładem jest marka Toyota, która swój system produkcyjny (Toyota Production System) oparła o metodę ciągłego udoskonalania, dając początek metodykom zwinnym, z których dziś korzystają branże i marki na całym świecie.
• Gospodarstwo domowe – Scrum, w tym retrospektywę, można wykorzystać do uporządkowania codziennych obowiązków oraz wprowadzania usprawnień.

Podsumowanie

Dzięki retrospektywie zespół poznaje siebie lepiej, próbuje nowych rozwiązań, często uczy się na swoich błędach. Retrospektywa pobudza kreatywność, która pozwala rozwiązać wiele problemów wewnątrz zespołu. Warto pamiętać, że wdrożenie niektórych zmian może wymagać więcej czasu niż jeden Sprint i dlatego trzeba być cierpliwym w oczekiwaniu na rezultaty. Ważne, aby zespół był świadomy siły połączonych możliwości i zgłaszał napotkane przeszkody na bieżąco.

Przejdź do:

1. 1. Scrum Master zaczyna od pytań
2. 2. Niezależne spojrzenie na pracę Zespołu Developerskiego
3. 3. Scrum Master rozmawia z członkami zespołu
4. 4. Budowanie zaufania
5. 5. Scrum Master a organizacja pracy
6. 6. Scrum Master motywuje zespół
7. 7. Scrum Master jako wsparcie dla organizacji
8. 8. Rozwój osobisty Scrum Mastera
9. 9. Podsumowanie

Według raportu „State of Scrum Master 2019 r.” 35% badanych organizacji jest na etapie wczesnej adopcji modelu zwinnego. To pokazuje, że zapotrzebowanie na Scrum Masterów w najbliższej przyszłości może wzrosnąć – nie bez powodu zresztą zawód ten od lat znajduje się na listach najbardziej obiecujących profesji w świecie IT. Bycie Agile to nie tylko kwestia umiejętności miękkich. Zwinne wytwarzanie oprogramowania powoli staje się standardem. Wiele mówi się o roli Scrum Mastera w procesie wytwarzania oprogramowania. Często to osoba, która nie zajmuje się programowaniem ani testowaniem. Jaki jest więc wkład Scrum Mastera w proces rozwoju aplikacji i funkcjonalności?

Czytaj także: Outsourcing usług IT wspiera realizację projektów

Scrum Master zaczyna od pytań

• Dlaczego chcemy pracować nad tą funkcjonalnością?
• Na czym polega dana zmiana?
• Czy konkretne zagadnienie jest potrzebne?
• Jakie osoby (umiejętności) są potrzebne do realizacji zadania? Czy wiemy, jak przetestować daną funkcjonalność?
• Czy ktoś potrzebuje wsparcia?
• Czy ktoś może pomóc tej osobie w wykonaniu zadania?
• Czy pojawiły się jakieś przeszkody, które blokują zespół w bieżącej pracy?

To tylko przykłady pytań, jakie może zadawać Scrum Master. Powinien on dostosować się on do sytuacji i poruszyć kwestie, które najbardziej pomogą w danym momencie. Rolą Scrum Mastera jest wsparcie zespołu w procesie wytwarzania oprogramowania. Pozwala to określić, co należy zrobić, aby przybliżyć zespół do realizacji celu Sprintu.

Poprzez zadawanie odpowiednich pytań Scrum Master sprawdza, w jakim stopniu zespół rozumie temat. Dzięki temu pomaga mu uświadomić sobie aspekty, które są potrzebne podczas analizy, tworzenia kodu czy testowania. Scrum Master nie powinien jednak sugerować gotowych rozwiązań, bo propozycje nie muszą być zawsze właściwe w danym momencie. Powinien pobudzić zespół, tak aby wszyscy wspólnie znaleźli najlepsze podejście. Zamiast wydawania poleceń Scrum Master dba więc o to, aby padły właściwe pytania, które stworzą potrzebne rozwiązania. Scrum Master nie zna odpowiedzi na wszystkie pytania (np. dotyczące zakresu funkcjonalności, kwestii technicznych lub organizacyjnych), jednak powinien znaleźć właściwą osobę, która będzie w stanie pomóc i wyjaśnić nurtujący temat.

Niezależne spojrzenie na pracę Zespołu Developerskiego

Scrum Master nie jest bezpośrednio zaangażowany w pracę wytwórczą, co pozwala mu zyskać niezależny obraz sytuacji wewnątrz zespołu. Będąc „z boku”, obserwuje prace i sposób komunikacji osób w zespole. Dzięki temu Scrum Master:

• Zna odczucia Zespołu Developerskiego na temat sposobu komunikacji i czasu poświęconego na pracę z innymi zespołami, a to pozwala na pracę nad efektywnością wytwarzania oprogramowania.
• Potrafi określić, czy kontaktów zewnętrznych jest za dużo czy może odwrotnie: jest potrzeba organizacji spotkań ze specjalistą lub członkiem z innego zespołu.
• Potrafi określić optymalną długość spotkań. Podejście do spotkań omawia z zespołem: „Czy nie są za długie?” „Czy nie jest ich za dużo?” „Czy wszyscy muszą uczestniczyć w danym spotkaniu?”

Scrum Master rozmawia z członkami zespołu

Scrum Master rozmawia nie tylko z menadżerem projektu, Product Ownerem czy innymi Scrum Masterami. Przede wszystkim regularnie rozmawia z członkami Zespołu Developerskiego. Bez oceny, bez krytyki. Szczera rozmowa, którą inicjuje Scrum Master, pozwala obu stronom poznać wzajemne odczucia na temat pracy, a szczególnie ważna jest rozmowa indywidualna. Idealną sytuacją jest, jeśli Scrum Master posiada umiejętność prowadzenia otwartej rozmowy, bez specjalnej otoczki i planowania w tym celu spotkań.

Ważne, aby za rozmową stała konkretna potrzeba. Zdarza się przecież, że ktoś w zespole ma trudny dzień z przyczyn prywatnych lub zadania w pracy nie idą pomyślnie. Scrum Master jest jak uważny obserwator, który zwraca uwagę na takie właśnie momenty. Jego rolą i pożądaną sytuacją jest stworzenie atmosfery, w której członkowie zespołu sami zwracają się do niego prośbą o przyjacielską rozmowę lub na ogólnym spotkaniu zgłaszają ważny temat bez poczucia skrępowania.

Budowanie zaufania

Budowanie relacji i zaufania jest bardzo ważne. Według badań, na które powołuje się ICAN Institute, styl zarządzania i kultura organizacyjna firmy 41% ankietowanych osób wskazuje jako ważny aspekt, podczas gdy warunki finansowe – 34%. Budowanie kultury organizacyjnej to praca nad komunikacją, budowanie dobrej atmosfery opartej na wzajemnym zaufaniu. Zespoły, które pracują w modelu samozarządzania, wiedzą, jak ważne jest mieć kogoś, kto wysłucha, ale też  pomoże podjąć dalsze kroki do realizacji. Tym kimś jest właśnie Scrum Master, który stara się, by każda osoba z jego otoczenia otrzymała właściwe wsparcie, nawet jeśli on sam nie zna odpowiedzi na dane pytanie.

Scrum Master a organizacja pracy

Według Edwardsa Deminga, który badał zarządzanie jakością i wpływ kontroli kierownictwa na zespół wydajność danej osoby jedynie w 5-15% zależy od samego pracownika. Az 85-95%  sukcesu zależy od organizacji pracy. Scrum Master zapewnia wsparcie organizacyjne podczas pracy wytwórczej, które odbywa się w krótkich iteracjach (Sprintach). Taki model pracy buduje ducha zespołu. Członkowie Zespołu Developerskiego coraz lepiej poznają się wzajemnie, ale też  coraz lepiej poznają tworzony przez siebie produkt.

Rola Scrum Mastera:

• Rozpoczynając od etapu analizy i tworzenia „User stories” przez zespół (pojedynczych zadań opisanych z perspektywy użytkownika końcowego, które po zrealizowaniu przyniosą zdefiniowane wartości), dba o zachowanie podstawowych elementów, z których zadania powinny się składać.
• Upewnia się, że zadania zawierają szczegóły, które umożliwią zespołowi zrozumienie nowego tematu i dba o wyjaśnienie otwartych jeszcze kwestii.
• Ma wkład w przypisywanie zadań do odpowiednich osób. Podczas opracowywania nowych funkcjonalności, które zespół będzie mógł zawrzeć w Sprincie, Scrum Master zadaje pytania i odnosi się do zakończonych Sprintów (jeżeli takie już się odbyły). Pozwala to znaleźć osoby, które najlepiej pod kątem merytorycznym, technicznym oraz doświadczenia pasują do danego zagadnienia.
• Dba o koordynację zadań. Scrum Master upewnia się, że każde nowe zadanie będzie miało osobę, która będzie dbała o koordynację prac w danym zagadnieniu.
• Monitoruje bieżący postęp prac. Za Sprint jest odpowiedzialny cały zespół, ważne jest jednak, aby Scrum Master znał postęp prac i dbał o to, aby zadania płynnie przechodziły ścieżkę od analizy, przez tworzenie funkcjonalności po testy.

Scrum Master powinien zwracać uwagę na powyższe elementy, tak aby praca nad zadaniami nie zatrzymała się z powodu błędu, braku przypisanej osoby czy otwartej zależności i dzięki temu mogła zmierzać ku końcowi.

Scrum Master motywuje zespół

Scrum Master nie jest Team Managerem, ale w codziennej pracy nie powinien zapominać o regularnym docenianiu członków Zespołu Developerskiego. Zespół dobrze wykonał pracę? Developer poświęcił dodatkowy czas na wsparcie kolegi czy koleżanki w wykonaniu trudnego zadania? Scrum Master docenia takie zachowanie i w ten sposób zachęca zespół do wzajemnej pomocy i efektywnej pracy nad realizacją zadań w Sprincie. Jeżeli pochwały będą prawdziwe i zasadne, pracownicy będą mu ufać. Szczere pochwały motywują do jeszcze lepszej pracy i poprawiają atmosferę w zespole. Dodatkowo po prostu miło jest zakończyć dzień po usłyszeniu podziękowań za swoją pracę.

Scrum Master jako wsparcie dla organizacji

Praca Scrum Mastera nie kończy się na współpracy z developerami czy Product Ownerem. Współpracuje on aktywnie także z osobami spoza własnego zespołu. Warto wymieniać doświadczenia w szerokim gronie, zgłaszać napotkane problemy, uczyć się nie tylko na własnych błędach.

Przykład: Scrum Master zauważa, że proces przepływu informacji w organizacji nie funkcjonuje poprawnie. Zespół Developerski nie uzyskuje informacji niezbędnych do ukończenia zadań. Scrum Master powinien zgłosić ten problem osobom z poziomu organizacji, tak aby wspólnie zastanowić się, jaki model komunikacji będzie optymalny.

Scrum Master nie tylko dzieli się własnymi pomysłami, ale też korzysta z wiedzy i doświadczenia innych. Przykładowo, jeżeli jakiś zespół wypracował metodę, która sprawia, że proces wytwarzania oprogramowania działa sprawnie, pozwala wyeliminować błędy,  a tym samym zmniejsza czas realizacji –  warto przekazać te informacje dalej, do innych osób i zespołów.

Rozwój osobisty Scrum Mastera

Scrum Master nie spoczywa na laurach! Aby być wsparciem dla zespołu, powinien ciągle się rozwijać, poznawać techniczne aspekty pracy, a także bacznie obserwować zachowania ludzi, z którymi pracuje. Scrum Master ciągle poznaje swój zespół i organizację, budując zaufanie. Rozwój osobisty to nie tylko certyfikacje i szkolenia, ale też umiejętność wyciągania wniosków z własnych niewłaściwych decyzji czy spóźnionych reakcji. Dzięki regularnym spotkaniom w zespole i projekcie jest w stanie stwierdzić, co nie działa, zrozumieć potrzebę członków zespołu, przekazać wskazówki i zaproponować działania, które w przyszłości zminimalizują lub wyeliminują trudności.

Przeczytaj także:

• Metodyki zwinne. Scrum a inne podejścia: SAFe, LeSS, Nexus
• Jak zbudować zgrany zespół? Umiejętności miękkie i typy osobowości a praca w Scrumie

Podsumowanie

Rola Scrum Mastera jest ważna w procesie wytwarzania oprogramowania. Jednak aby jego wysiłek przynosił skutek, Scrum Master powinien ciągle pracować z zespołem i osobami w projekcie nad usprawnieniem prac i rozwojem indywidualnym każdej osoby. Dobry Scum Master nie tylko zadaje odpowiednie pytania, ale też wyciąga wnioski i wprowadza wraz z zespołem akcje, które umożliwią wyeliminowanie napotkanych problemów w przyszłości. Także poprzez osobisty rozwój wnosi wkład w proces wytwarzania oprogramowania, a tym samym – wartość dla zespołu i organizacji.