Zwinne zarządzanie projektami. Część III: Scrum

Wpis gościnny autorstwa Magdy Nicgorskiej, zdalnej project managerki z 8-letnim doświadczeniem w zarządzaniu projektami i zespołami.

---

W poprzednich wpisach poznaliśmy podstawy filozofii Agile oraz zastosowanie tablicy kanban. Dziś chcę Wam przybliżyć metodykę Scrum.

Scrum powstał w latach dziewięćdziesiątych ubiegłego wieku jako usprawnienie pracy zespołów deweloperskich (czyli wytwarzających oprogramowanie), ale, podobnie jak kanban, obecnie z powodzeniem jest adaptowany do innych branż. 

Scrum to przede wszystkim duża elastyczność i ukierunkowanie na usprawnienie pracy zespołu. Zapoczątkowany został w branży wytwarzania oprogramowania. Jednak z upływem czasu i zyskaniem dojrzałości zaczął być stosowany również w zarządzaniu całymi organizacjami. Dzisiaj chętnie stosuje się Scrum wszędzie tam, gdzie praca polega na wytwarzaniu lub rozwijaniu produktów oraz usług przez zespoły nie tylko deweloperskie.

Z tego wpisu dowiesz się:

1. Co to jest Scrum.
2. Role w Scrumie.
3. Artefakty.
4. Wydarzenia.
5. Scrum w pracy wirtualnej asystentki.

Co to jest Scrum

Scrum dotyczy poziomu zespołu i nie opisuje sposobu prowadzenia projektów jako takich (o Agile w projektach będę pisać w kolejnych częściach). W skład Scruma wchodzą reguły, wydarzenia, role oraz artefakty. Jest to framework ogólnodostępny oraz darmowy. Można również, z mniejszym lub większym powodzeniem, wykorzystywać jego wybrane elementy. Jednak należy pamiętać, żeby nie nazywać tego wtedy Scrumem (zwłaszcza przy fanatykach ;)).

W metodyce tej pojawiają się zamknięte iteracje czasowe zwane sprintami. Sprint jest to z góry określony przedział czasu (np. dwa lub trzy tygodnie), podczas którego zespół realizuje zamknięty podzbiór zadań z backlogu (czyli listy, która zawiera zadania do realizacji). 

Niektórzy myślą, że aby zrobić Scruma, wystarczy wprowadzić sprinty i załatwione. To jednak zbyt duże uproszczenie, ponieważ wdrożenie Scruma to nie tylko wprowadzenie iteracji w pracy zespołu. Metodyka ta wprowadza też w zespole wydarzenia, które nadają iteracjom określony przebieg, a ponadto definiuje kilka ról niezbędnych w zespole. Ciężko opisać wiedzę o całej metodyce w jednym wpisie, ale postaram się zawrzeć tu najistotniejsze informacje. Szczegółowo wszystko opisuje Scrum Guide.

Role w Scrumie – czyli jesteś kurczakiem czy świnią? 

Jak z zarządzania zespołami przeskoczyłam na farmę? Otóż to przewrotne pytanie odnosi się do mini bajki, która pokazuje różnicę między poświęceniem i zaangażowaniem w projekcie (ang. committed vs involved).

W bajce tej kurczak i świnia zastanawiali się nad założeniem restauracji i wyborem głównego dania. Kurczak zaproponował „Jajka na boczku”. Świnia, ku zdziwieniu kurczaka, odmówiła. Dlaczego? Jak łatwo się domyślić, nie była zbyt chętna na zostanie dawcą boczku. Ujmując więc historię w inne słowa: w przygotowanie jajek na boczku kurczak byłby tylko zaangażowany podczas gdy świnia musiałaby się poświęcić. 

Ta mini bajka dobrze pokazuje jak różne interesy mają różni interesariusze/udziałowcy projektu (ang. Project Steakholders). W Scrumie za świnie uznaje się Scrum Mastera, Product Ownera oraz zespół. Natomiast klient (biznes), udziałowcy, czy kadra zarządzająca to kurczaki. Sprawdźmy czym się zajmują poszczególne role w Scrumie.

Scrum Master

Najłatwiej zacząć od wyjaśnienia kim Scrum Master nie jest. Nie jest Project Managerem ani kierownikiem zespołu, zwyczajnie w Scrumie nie ma roli kierowniczej jako takiej. Zatem SM nie rozdziela zadań między członków zespołu ani nie rozlicza ich z nich w tradycyjnym tego słowa rozumieniu. Scrum Master jest to osoba, która dba o komfort pracy zespołu, prowadzi ceremonie i pilnuje, aby praca odbywała się zgodnie z założeniami samoorganizującego się zespołu. 

Product Owner

Czasem zwany po polsku Właścicielem Produktu. Product Owner jest łącznikiem między zespołem a biznesem. Wytycza kierunek rozwoju i weryfikuje czy to, co zostało zrobione. Spełnia oczekiwania i wnosi wartość dla biznesu. Product Owner odpowiada za zakres realizowanych zmian i jest odpowiedzialny za backlog produktu.

Team

Czyli zespół wytwórczy (deweloperski). Aby zrozumieć Scruma, należy pojąć ideę samoorganizującego się zespołu. Nie ma tutaj roli Kierownika Projektu czy lidera zespołu. Samoorganizujący się zespół nie oznacza również, że zespół sam wymyśla czym ma się teraz zająć. Zespół sam decyduje ile pracy jest w stanie wykonać oraz jak zadania zostaną w zespole przydzielone.

Artefakty

Backlog produktu (ang. Product Backlog)

Jest to lista wszystkich obecnie znanych wymagań dotyczących rozwoju produktu (lub usługi). Zarządzany jest i rozwijany przez Product Ownera. Najczęściej wymagane zmiany przedstawiane są jako historyjki (ang. user story). 

Backlog Sprintu (ang. Sprint Backlog)

Jest to lista zmian, które zespół będzie realizował w danym sprincie. Backlog ustalany jest przez zespół podczas planowania. Historyjki w sprincie muszą już być szczegółowe na tyle, aby zespół był w stanie nad nimi pracować.

Przyrost (ang. Increment)

Przyrost to suma wszystkich ukończonych elementów backlogu i obejmuje prace z bieżącego oraz poprzednich sprintów. Informuje o postępach pracy zespołu.

Istnieje wiele narzędzi wspomagających zarządzanie backlogiem produktu i sprintu oraz pracą zespołu Scrum. Jednak wielu praktyków zaleca fizyczne tablice na ścianach. Tablice te zazwyczaj wzorowane są na kanbanowych.

Wydarzenia (ang. Scrum Events)

Wydarzenia, zwane są też w niektórych tłumaczeniach ceremoniami.

Sprint

Bez sprintów nie byłoby Scruma. Tak jak już wspomniałam, sprinty to ograniczone czasowo iteracje. Sprinty mają z góry ustalony czas trwania (np. 2 tygodnie). Nie zaleca się sprintów dłuższych niż miesiąc.

Podczas sprintu powinien powstać taki kawałek produktu (przyrost), który będzie stanowił użyteczną wartość. Na sprint składają się:

• Planowanie (ang. Sprint Planning).
• Scrum codzienny (ang. Daily Scrum).
• Przegląd sprintu (ang. Sprint Review).
• Retrospektywa (ang. Sprint Retrospective).

Planowanie

Każdy sprint rozpoczyna się planowaniem, podczas którego zespół scrumowy ustala zakres prac na dany sprint. I tu dochodzimy do sedna zespołu samoorganizującego się. To zespół wytwórczy decyduje, ile pracy jest w stanie wykonać w czasie danego sprintu. Ocenia to na podstawie swojej wiedzy, doświadczenia oraz historii poprzednich sprintów. 

Product backlog definiowany jest przez biznes, ale to zespół decyduje ile z tego da radę wykonać w danym sprincie. Oczywiście, zespół nie wybiera sobie dowolnie historyjek do backlogu sprintu, tylko uwzględnia priorytety przekazane przez Product Ownera. 

Co istotne, raz ustalony zakres sprintu, jego cele, nie powinny ulegać zmianie w czasie jego trwania. Czyli (w idealnym świecie) nie dokładamy nowych rzeczy. Nie zmieniamy priorytetów czy nie rezygnujemy z prac, które już zostały rozpoczęte.

Planowanie sprintu ma za zadanie odpowiedzieć na pytania:

• Co może zostać dostarczone w ramach tej iteracji?
• Jak zostanie to zrobione?

Często planowanie opiera się na dyskusji, a następnie wycenianiu (np. za pomocą story points) poszczególnych historyjek z backlogu produktu. Do zakresu brana jest określona ilości pracy. Są różne techniki i narzędzia wspierające planowanie sprintu, np. planning poker.

Scrum codzienny

Jak sama nazwa wskazuje, jest to spotkanie odbywające się codziennie. Zazwyczaj na początku dnia. To moment, w którym spotyka się cały zespół i omawia bieżącą sytuację.

Stanowi on świetną formę utrzymywania komunikacji w zespole. Jest to też dobry moment na wyłapywanie potencjalnych opóźnień lub problemów. Zaleca się, aby spotkania te odbywały się na stojąco by zachować dynamiczną i jak najkrótszą formę. Każdy z uczestników powinien się wypowiedzieć. Można, ale nie trzeba, spotkania sformalizować np. do formy, w której każdy z jego uczestników ma okazję, aby odpowiedzieć na 3 pytania:

• Co udało mi się zrobić od poprzedniego spotkania?
• Co mam zamiar zrobić do następnego spotkania?
• Jakie problemy napotkałem?

Przegląd sprintu

Jest to wydarzenie czy też ceremonia zamykająca sprint. Często przyjmuje formę demo, podczas którego prezentowane są rezultaty wypracowane w danym sprincie. Na takim przeglądzie poza zespołem wytwórczym i Product Ownerem obecni są interesariusze projektu (np. przyszli uczestnicy oraz sponsorzy projektu).

Przegląd polega na omówieniu tego, co udało (lub też nie udało) się zrobić, oraz jakie napotkano problemy po drodze i jak wpływają na dalsze prace.

Retrospektywa

Jest to kolejna bardzo dobra praktyka. Spotkanie to odbywa się w gronie zespołu i ma na celu wspólną analizę tego, co poszło dobrze, co poszło „nie tak” i co możemy zrobić, żeby następnym razem poszło lepiej. Ważna uwaga: spotkanie to nie ma na celu wytykaniu błędów, tylko znalezieniu rozwiązania. Dlatego ważne jest jego umiejętne moderowanie.

Dzięki takim spotkaniom i rozwiązaniom na nim wypracowanym zespół może się ciągle rozwijać i wypracowywać optymalne dla siebie warunki pracy.

Na takim spotkaniu można np. porozmawiać o nieprzewidzianych problemach, które wyniknęły w czasie sprintu i wspólnie ustalić co w przyszłości powinniśmy robić inaczej aby temu zaradzić.

Oczywiście, jedno spotkanie nie rozwiąże wszystkich problemów, ale pozwala na ciągle ulepszanie organizacji pracy zespołu, komunikacji i środowiska pracy. Podobnie jak przy planowaniu istnieją różne sposoby na przeprowadzenie takiego spotkania i jego usprawnienie.

Każdy zespół dostosowuje rozkład dnia oraz sprintu do siebie, projektu oraz organizacji, w której pracują. Przykładowy sprint może trwać np. dwa tygodnie. Jedni będą woleli go rozpoczynać w poniedziałki, inne zespoły będą wolały końcówkę tygodnia. Spotkania codzienne najlepiej robić rano, ale nie ma reguły, która zabroni zrobić je po południu. Najważniejsze, żeby to była pora, w czasie której wszyscy członkowie zespołu są dostępni. 

Scrum w pracy wirtualnej asystentki

Czy Scrum może być przydatny w pracy wirtualnej asystentki? Jak zawsze – to zależy. :) Jeśli Twoje zadania to typowa praca administracyjna lub masz wąską specjalizację (np. social media czy kursy), prawdopodobnie Scrum nie będzie zbyt potrzebny.

Jeśli jednak prowadzisz lub w przyszłości zamierzasz prowadzić swój zespół – znajomość Scruma może Ci się przydać do organizacji jego pracy. Metodyka ta wprowadza wiele dobrych praktyk, które można wykorzystać nie tylko w zespołach deweloperskich i ich umiejętne zaadaptowanie może pomóc w rozwijaniu własnych zespołów. 

Być może trafisz na klienta, który będzie zainteresowany zmianą organizacji swojego zespołu. Dzięki wiedzy o różnych metodykach będziesz mogła przedstawić mu różne możliwości. Metodykę tę można przystosować do pracy zespołów wytwarzających przeróżne produkty lub usługi cyfrowe. Wiedza o Scrumie pozwoli Ci się odnaleźć szybciej w takim zespole.

Pojawia się też coraz więcej ogłoszeń, w których klienci poszukują Online Business Managerów lub Wirtualnych Project Managerów. Może w przyszłości będziesz chciała poszerzyć swoje usługi o zarządzanie projektami – wtedy znajomość różnych metodyk prowadzenia projektów i zespołów będzie Twoim atutem pośród rosnącej konkurencji.

Przydatne linki i źródła:

• https://www.scrumguides.org/index.html – Scrum Guide do ściągnięcia po angielsku i w ponad 30 innych językach
• https://agilemanifesto.org/  – cytowany w tekście Manifest Agile
• https://medium.com/serious-scrum/what-the-scrum-guide-doesnt-say-56ef9447b961 – bardzo ciekawy artykuł obalający kilka stereotypów dotyczących SCRUMa i sposobów jego wdrożenia w organizacji.
• https://www.youtube.com/watch?v=TRcReyRYIMg – bardzo krótki film wyjaśniający podstawy