Scrum Team. Jak wdrożyć Scruma w swojej firmie?

Praca w Scrumie to dla osoby związanej z branżą IT chleb powszedni – planowanie, codzienne spotkania, iteracyjne działania w sprintach, itd. Wszystko to wygląda książkowo, gdy o tym opowiadamy. Czasem warto jednak swoją praktykę zestawić w porównaniu z teorią. Wyniki takiego porównania mogą być w przypadku pracy w Scrumie bardzo zróżnicowane.

Mirosław Cis. .NET developer w Sii Polska. Coraz szerzej rozwijający się w kierunkach związanych ze Scrumem oraz udoskonalaniem jego implementacji. Obecnie pracujący dla klienta z branży ubezpieczeniowej w projekcie z technologiami: ASP.NET Core, React, Redux i Typescript. Po godzinach pasjonat sportu, zwłaszcza piłki nożnej.

Zgodnie z definicją, Scrum jest frameworkiem, z wykorzystaniem którego możemy rozwiązywać złożone problemy. Jego równoległym założeniem jest produktywne i kreatywne dostarczanie produktów o możliwie najwyższej wartości. Pracując zgodnie z ramami postępowania jakie nakłada na nas Scrum, jesteśmy w stanie ciągle ulepszać nasz produkt, zespół oraz środowisko, w którym się znajdujemy.

Niewątpliwą zaletą Scruma jest jego „bycie na czasie” – cały proces jest dokładnie opisany, a także systematycznie rozwijany, co pozwala nadążać za zmieniającym się w błyskawicznym tempie rynkiem IT. We wspomnianym opisie znajdziemy informacje na temat tego, jak powinna być zorganizowana praca zespołu projektowego.

Scrum jest oparty na empirycznym sposobie kontroli procesu. Co to oznacza? Wiedza pochodzi z posiadanego doświadczenia, a decyzje podejmowane są na podstawie tego, co wiemy. W podejściu empirycznym nie potrafimy dokładnie przewidzieć wyników wykonania pracy w momencie jej podejmowania. Chcemy kontrolować uzyskane wyniki i zarazem utrzymywać wysoką jakość. Poszczególne kroki w procesie nie zawsze są powtarzalne. Aby podtrzymać zasady empirycznego podejścia do kontroli procesu w Scrumie zostały wprowadzone 3 filary: inspekcja, adaptacja i przejrzystość.

Zobacz też

Juniors Gwarantujemy własnymi pieniędzmi, że po bootcampie da się znaleźć pracę

Inspekcja

Jej założenie jest proste – w trakcie sprintu sprawdzaj swoją pracę regularnie – pozwoli to odpowiednio wcześnie wykryć ewentualne niepożądane odchylenia. Nie należy jednak czynić tego zbyt często, aby owo sprawdzanie nie stawało na przeszkodzie w realizacji celów sprintu. Inspekcje są najbardziej efektywne wtedy, gdy rzetelnie wykonują je odpowiednio wykwalifikowane do tego osoby.

Adaptacja

Jeśli podczas inspekcji zostaną dostrzeżone czynniki, które w realny sposób przekraczają akceptowalne limity i mogą spowodować brak osiągnięcia założonego celu – należy w odpowiedni sposób dostosować trwający proces. Dostosowanie powinno być wykonane tak szybko jak to możliwe.

Scrum zaleca cztery formalne wydarzenia do inspekcji i adaptacji:

• Sprint planning
• Daily scrum
• Sprint review
• Sprint retrospective

Przejrzystość

Założeniami tego filaru są jednakowe rozumienie zagadnień przez wszystkie strony oraz jednakowe rozumienie „definicji zakończonej pracy”. Spełnienie obu postulatów pozwoli nam uniknąć nieporozumień i sytuacji, w których zainteresowane strony w procesie będą dochodziły swoich racji na podstawie własnych interpretacji wymagań.

Scrum Team

Zespół Scrum składa się z Product Ownera, Development Teamu i Scrum Mastera. Zespoły Scrum są niezależne i wielofunkcyjne. Samoorganizujące się zespoły wybierają, w jaki sposób najlepiej wykonać swoją pracę – nie są przy tym kierowane przez osoby spoza zespołu. Wielofunkcyjność oznacza, że przez członków zespołu są posiadane wszystkie kompetencje potrzebne do wykonania pracy – bez uzależnienia od innych osób, które nie są częścią zespołu. Zastosowany w Scrum model zespołu ma na celu optymalizację elastyczności, kreatywności i produktywności.

Product Owner

Product Owner (właściciel produktu) jest odpowiedzialny za maksymalizację wartości produktu będącego efektem pracy zespołu deweloperskiego. Sposób osiągnięcia tego celu może różnić się dla poszczególnych organizacji, zespołów scrumowych oraz jednostek.

Jest to rola jednoosobowa. Może reprezentować zdanie wielu osób w rejestrze produktu (product backlog), jednak jakakolwiek zmiana (np. priorytetu) elementów rejestru produktu musi być zaakceptowana przez Product Ownera (w rezultacie Product Owner jest rozliczany ze swojej pracy jako pojedyncza jednostka).

Aby Product Owner pracował efektywnie jego decyzje muszą być respektowane wewnątrz organizacji, dla której pracuje. Decyzje te są widoczne w zawartości oraz kolejności elementów product backlogu.

Rejestr prowadzony przez właściciela produktu jest jedynym źródłem wymagań dla zespołu developerskiego. W zarządzaniu rejestrem produktu są zawarte:

• Jasno sprecyzowane elementy rejestru produktu
• Uporządkowanie elementów z rejestru produktu, by w jak najlepszy sposób osiągać potencjalne cele wyznaczane dla zespołu deweloperskiego
• Optymalizację wartości pracy wykonywanej przez zespół deweloperski

Ponadto product backlog powinien pokazywać faktyczną informację na temat aktualnych prac Development Teamu (oraz ich stanu). Właściciel produktu powinien dbać o to, by elementy zawarte w rejestrze produktu były zdefiniowane w sposób przejrzysty, ułatwiający pełne zrozumienie ich treści przez zespół developerski.

Oferty pracy z

Development Team

Zespół developerski składa się z profesjonalistów realizujących zadania z zakresu sprintu. Jego celem jest dostarczenie potencjalnie gotowego do wydania przyrostu skończonego produktu na koniec każdego ze sprintów. Tylko członkowie Development Teamu biorą udział w tworzeniu nowej wersji produktu (zwanej także przyrostem od angielskiego słowa increment).

Członkowie zespołów deweloperskich są dobierani przez organizację, dla której pracują. Wyselekcjonowane grupy specjalistów dostają od swych organizacji zielone światło do zarządzania swoją pracą we własnym zakresie.

Uzyskana w takim modelu pracy „synergia” ma w założeniu optymalizować ogólną efektywność i wydajność zespołu developerskiego.

Zespół developerski jest odpowiedzialny za wytworzenie ukończonego, potencjalnie gotowego do wydania produktu na zakończenie każdego sprintu. Podczas planowania prac zespół sam decyduje o ilości elementów możliwych do realizacji w danym sprincie oraz o planie na wykonanie wyselekcjonowanych zadań.

Niezależnie od kompetencji posiadanych przez poszczególnych członków Development Teamu nie powinno widać w nim wewnętrznych podziałów (wynikłych np. ze stanowiska czy też innych czynników). Podczas przeglądu prac zespół jest rozliczany jako całość bez wyszczególniania dokonań pojedynczych jednostek.

Zgodnie z założeniami Scruma rozmiar zespołu developerskiego powinien się zamknąć w przedziale od 3 do 9 osób. Zbyt duże zespoły wymagają zbyt dużej koordynacji i generują zbyt dużą złożoność dla całego procesu organizacji pracy. Zbyt małe zespoły powodują obniżenie wewnętrznych interakcji między członkami oraz są narażone na potencjalne luki w umiejętnościach niezbędnych do osiągnięcia celu sprintu.

Scrum Master

Scrum Master jest odpowiedzialny za wspieranie członków Scrum Teamu w odpowiedniej implementacji Scruma (zgodnie z definicją w Scrum Guide). Scrum Master pomaga członkom zespołu scrumowego zrozumieć teorię i praktykę Scruma uwzględniając jego zasady i wartości.

Scrum Master dba o prawidłowy przebieg i zrozumienie procesu wytwórczego zgodnie z ramami postępowania nakreślonymi przez Scrum. Jest tzw. servant-leaderem dla członków zespołu – służy im wiedzą i umiejętnościami z zakresu Scruma, jednocześnie będąc liderem w kwestii przestrzegania i stosowania jego zasad oraz wartości. Ponadto Scrum Master dba o to, aby osoby spoza Scrum Teamu nie wpływały w żaden sposób na pracę wykonywaną przez zespół (w szczególności taką, która może mieć wpływ na wydajność poszczególnych członków zespołu i w rezultacie doprowadzić do narażenia osiągnięcia celu sprintu).

Obowiązki Scrum Mastera wobec Development Teamu:

• Dzielenie się wiedzą w zakresie jego samoorganizacji oraz wielofunkcyjności
• Usuwanie przeszkód
• Ułatwienie przeprowadzania wydarzeń scrumowych, by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu
• Udzielanie rad w kwestiach współpracy środowiska okołoprojektowego z zespołem

Obowiązki Scrum Mastera wobec Product Ownera:

• Pomoc w zarządzaniu rejestrem produktu (np. przez wynajdywanie i sugerowanie efektywnych technik zarządzania)
• Wyjaśnianie potrzeby jasnego i przejrzystego product backlogu
• Dbanie o jednolite rozumienie zagadnień przez wszystkie strony procesu wytwórczego
• Ułatwienie przeprowadzania wydarzeń scrumowych by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu

Obowiązki Scrum Mastera wobec organizacji:

• Pomoc dla organizacji w kwestiach jej adaptacji do Scruma
• Planowanie sposobu implementacji Scruma w organizacji
• Zrozumienie i zarządzanie Scrumem oraz empirycznym procesem rozwoju produktu
• Zwiększanie produktywności Scrum Teamu
• Współpraca z innymi Scrum Masterami

Scrum w swoich założeniach jest lekki i łatwy do zrozumienia. Jego prawidłowa implementacja jest jednak bardzo trudna do wykonania. Jak wdrożyć pracę w Scrumie w swojej firmie?

Wyjaśniliśmy wszystkie definicje związane z pracą w scrumie. Przyszedł czas na wyjaśnienie, jak wdrożyć zespół w nowy model realizacji zadań. W jaki sposób rozdzielić zadania?

Przede wszystkim musimy mieć jasno sprecyzowane umiejętności każdego członka development teamu. Jeśli zespół (cały Scrum Team) rozrasta się na ponad dziesięć osób, warto pomyśleć nad rozdzieleniem odpowiedzialności na dwa zespoły. Należy więc w porozumieniu z Product Ownerem utworzyć dwa niezależne backlogi (ale umożliwiające jednoczesne prace dla obu zespołów nad odpowiednimi częściami końcowego rozwiązania). Zespoły powinny zostać podzielone w taki sposób, aby każdy z nich posiadał w sobie mieszankę umiejętności niezbędną do utrzymania postępu prac na podobnym poziomie (w procesie wytwarzania oprogramowania niezbędnymi elementami development teamu są np. programiści, testerzy i architekt rozwiązania), zapewnienia najwyższej jakości dostarczanego produktu.

W idealnym scenariuszu każdy development team powinien posiadać swojego Scrum Mastera, a sami Scrum Masterzy powinni regularnie odbywać spotkania zwane scrum of scrums (tego typu spotkania zalecane są w trybie codziennym aby zminimalizować ryzyko kolizji, szybciej identyfikować potencjalne problemy).

Zobacz też

growth hacks Od Juniora do Seniora: Odpowiedzi na pytania społeczności #5

Co gdy nowa osoba dołącza do naszej organizacji?

Znając kompetencje danej osoby powinniśmy być w stanie ocenić jej przydatność jako nowego członka zespołu. Nowa osoba powinna zajmować się zadaniami w obrębie swoich kompetencji oraz biorąc pod uwagę próg wejścia do projektu o odpowiednim poziomie zaawansowania. Ważnym elementem jest również moment rozpoczęcia współpracy z nowym członkiem zespołu — zaleca się by odbyło się to tuż po zakończonym sprincie. W przypadku dodania osoby do development teamu warto taką decyzję podjąć wspólnie z jego członkami. Z racji tego, że development team jest samoorganizującą się grupą, powinien we własnym zakresie zdecydować o sposobie wdrożenia nowego członka. Przed dodaniem członka zespołu w zaawansowanej fazie projektu (bliżej końca) należy zastanowić się i przeanalizować konsekwencje takiego działania. Przy projektach o wysokim progu wejścia może to ostatecznie dać efekt odwrotny do zamierzonego i opóźnić zakończenie prac.

Jakie najczęściej błędy popełniają organizacje?

1. Mieszanie roli Scrum Mastera z Project Managerem. Scrum Master zgodnie z założeniami powinien być ’servant leaderem’ dla development teamu. Ewentualne wydawanie poleceń oraz kontrola ich wykonania jest przeciwieństwem tego, jak powinna wyglądać praca zespołu w scrumie. Przeczy to samoorganizacji się zespołu, który powinien być niezależny w swoich działaniach.

2. Niegotowy backlog i niewystarczająco zaangażowany Product Owner. Do owocnej pracy w scrumie niezbędne jest połączenie sił development teamu i Product Ownera. W przypadku braku zaangażowania tego drugiego często dochodzi do sytuacji gdy product backlog jest nieprzygotowany, co przekłada się na regularne zawodzenie jeśli chodzi o realizację celów kolejnych sprintów.

3. Brak kompletnej transparentności/przejrzystości w zespole deweloperskim. Zbyt późne komunikowanie o zaistniałych przeszkodach, próba wykorzystywania Scrum Mastera (przez development team) do celów nie w jego kompetencjach (np. dostarczanie informacji od Product Ownera). Komunikacja twarzą w twarz jest kluczowa i powinna być stosowana zawsze gdy jest to możliwe.

4. Niedocenianie wartości retrospektywy. Komunikowanie z pozoru nieistotnych problemów jest szalenie ważne z punktu widzenia całego zespołu (jego efektywności, przejrzystości). Co dla jednego członka zespołu wydaje się błahostką dla innego może być pomocne. Konstruktywne dyskusje są wskazane!

Czy po zapoznaniu się z powyższymi informacjami możecie nadal z całą pewnością powiedzieć, że na co dzień pracujecie w jedynym i prawdziwym Scrumie? Podzielcie się swoimi spostrzeżeniami na ten temat, ale też problemami, z którymi borykacie się na co dzień.

Zdjęcie główne artykułu pochodzi z burst.shopify.com.