1. 1. Transparencja, czyli przejrzystość  
2. 2. Inspekcja 
3. 3. Adaptacja

Po pierwsze: transparencja, czyli przejrzystość  

Dotyczy to wszystkich elementów, procesów i postaw.  

• Backlog Produktu musi być przejrzysty i znany wszystkim członkom Zespołu.  
• Musi być dostępny dla wszystkich zainteresowanych.  
• Musi być jeden, wspólny dla nas i dla klienta.  

Bo w Scrumie podstawą jest relacja oparta na zaufaniu i dobrych intencjach. Jesteśmy szczerzy w relacji ze sobą i z klientem. Także w tych trudnych chwilach. Postęp naszych prac jest mierzalny i widoczny dla wszystkich zainteresowanych. Problemy komunikujemy jasno, ale oczekujemy też jasnych wymagań. Precyzyjnych celi i znajomości kontekstu. 

Bez wiarygodnych danych „wejściowych” nie będziemy w stanie spełnić oczekiwań. Nie będziemy też w stanie rzetelnie ocenić procesu, którego częścią jesteśmy.  

Transparentność oznacza też, że wszyscy członkowie zespołu muszą porozumiewać się wspólnym językiem. Terminologia nie może pozostawiać miejsca na domysły.  Ważne jest także, aby na różnych poziomach procesu istniała wspólna płaszczyzna komunikacji. 

Jednym ze zdarzeń w Scrumie, gdzie transparentność ma najwyższe znaczenie, jest Retrospektywa Sprintu. To właśnie podczas tego spotkania powinniśmy powiedzieć sobie wszystko.

Za każdym razem, kiedy z różnych powodów milczymy o problemach, odbieramy Zespołowi szansę, by się rozwijać. 

Transparentność jest wartością, nad którą trzeba pracować na każdym poziomie organizacji. Od relacji w Zespole, z Managementem, jak również z klientem. 

Jednym z podstawowych aspektów budowania kultury przejrzystości jest otwartość na porażkę. Próby i błędy są naturalnym elementem procesu uczenia. Dopiero wtedy mamy szansę działać w oparciu o to jak jest, a nie o to, jak nam się wydaje, że jest. Lub jeszcze gorzej, jak byśmy chcieli, żeby było. 

Po drugie: inspekcja 

W swoich założeniach Scrum opiera się na obserwacji. Na każdym poziomie i na każdym kroku zastanawiamy się, jak działamy. Taka refleksja powinna dotyczyć wszystkich i towarzyszyć nam każdego dnia. 

Regularnie mierzymy prędkość i efektywność. Weryfikujemy, czy Backlog jest czytelny. Weryfikujemy Przyrost produktu (Increment) i jego zgodność z wymaganiami. Czy Sprint przebiega w równym tempie i nie ma przeszkód na horyzoncie, które mogą zablokować realizację celu. Zastanawiamy się nad tym, co nam pomaga, a co przeszkadza. 

Szukamy wąskich gardeł w procesie. Pamiętamy, że łańcuch jest tak słaby, jak najsłabsze jego ogniwo. Tak samo z procesami. Tylko usprawnienie najsłabszego elementu, usunięcie realnej przeszkody, ma szanse przynieść wymierne korzyści.  

Niezwykle ważne jest to, że inspekcja jest życzliwa. Nie ma na celu wytykania słabości, ale identyfikację obszarów do wzmocnienia. Pozwala szybko wykryć niezgodność wymagań. Inspekcja nie jest w Scrumie rozumiana jako narzędzie kontroli czy represji. Jest narzędziem umożliwiającym zmianę. A tylko poprzez zmianę możliwy jest rozwój.  

I po trzecie: adaptacja 

Adaptacja to wszystkie działania usprawniające proces. Od zmiany formuły stand-upu, przez pracę nad Backlogiem po nowe narzędzia deweloperskie. Adaptacja jest kluczem do rozwoju. 

Dla mnie adaptacja to umiejętność szybkiej diagnozy i wprowadzenia zmian, które są podyktowane zmieniającymi się warunkami projektowymi lub wynikają z przeprowadzonej inspekcji. 

Są dwa podstawowe błędy w implementacji Scruma. Adaptacja bez przeprowadzenia rzetelnej inspekcji lub, co w moim odczuciu gorsze, przystępowanie do inspekcji, po której nie następuje adaptacja. 

W pierwszym przypadku zmiany mogą być chaotyczne i nie odpowiadać realnym potrzebom. W drugim pozostaje poczucie zmarnowanej szansy na rozwój.   

Podsumowanie 

Scrum działa nie dlatego, że ma trzy role, pięć zdarzeń i trzy artefakty, ale dlatego, że jest oparty na empiryzmie, którego wyrażeniem są trzy powyższe filary. Oznacza to proces oparty na faktach, doświadczeniu i dowodach, w którym postęp opiera się na obserwacjach rzeczywistości, a nie na fikcyjnych planach. 

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.