Scrum to zwinne podejście do wytwarzania produktów i usług. Jednak produktem wcale nie musi być oprogramowanie, a Scrum przydaje się wielu zespołom – także tym niepowiązanym z IT. Co ciekawe, w wielu organizacjach Scrum jest adaptowany również do codziennej pracy działów HR. Ta metodyka może pomóc nam w procesie organizacji konferencji, zbudowaniu procesu onboardingu czy stworzeniu komunikacji marki pracodawcy.
Czym różni się od tradycyjnego podejścia do wytwarzania produktów? Scrum zakłada podział projektu na iteracje, czyli małe kawałki, podczas których stopniowo powstają kolejne elementy procesu. To podejście pozwala w każdej chwili zatrzymać się, przeprowadzić szybką ewaluację wyników i sprawdzić, czy jesteśmy na właściwym kursie, a jeżeli wymagane są zmiany, wdrożyć je bez zbędnej zwłoki.
Na początek – skąd wziął się Scrum?
Pojęcie Scrum zostało zaczerpnięte z zespołowej gry rugby, gdzie oznacza ustawienie zawodników pozwalające na bardziej efektywną współpracę. Pierwsze użycie określenia Scrum w kontekście rozwoju programowania miało miejsce w 1986 r. na łamach Harvard Business Review. Hirotaka Takeuchi i Ikujiro Nonaka w artykule „The New New Product Development Game” opisywali potencjalne korzyści z pracy w Scrumie dla zespołów i organizacji. Podkreślali, że użycie metodyk zwinnych jest katalizatorem innowacji i sposobem na budowanie organizacji uczącej się.
Opierając się na case studies kilku firm z branży technologicznej, dowodzili, że nowe podejście przyspieszy czas produkcji oprogramowania i zwiększy elastyczność biznesową. Takeuchi i Nonaka porównali Sprint scrumowy do gry w rugby: drużyna przemieszcza się po długości boiska (tak, jak zespół projektowy działający zgodnie z harmonogramem), jednocześnie podając sobie piłkę (czyli w praktyce wymieniając się odpowiedzialnościami i zadaniami).
No właśnie – praca w Scrumie oznacza wymianę kompetencji, ciągłą komunikację i nastawienie na krótkoterminowy cel obok długofalowej strategii. Jak to wygląda w praktyce?
Scrum na co dzień – role w zespole scrumowym
Choć wiele firm oferuje kursy pracy w metodykach zmiennych, podstawowe elementy Scruma dostępne są za darmo. Mowa o Scrum Guide, czyli „Przewodniku po Scrumie”, ale też licznych bibliotekach zasobów wiedzy (np. firmy Atlassian oferującej popularne wśród zespołów scrumowych rozwiązanie Jira). Tylko czy Scruma można nauczyć się z książki? Niekoniecznie.
Podstawą metodyk zwinnych jest praktyka opierająca się na budowaniu współodpowiedzialności za produkt i eliminowaniu przeszkód procesowych.
W zespołach scrumowych znajdziemy więc zarówno osoby odpowiedzialne za operacyjne wytwarzanie produktu (np. badaczy, analityków, projektantów), jak i te trzymające proces w ryzach i nadające mu kierunek: Właściciela produktu (Product Ownera) i Scrum Mastera. Właściciel produktu pilnuje celów i priorytetów projektowych, podejmuje decyzje w kluczowych momentach i odgrywa rolę klienta wewnętrznego. Scrum Master czuwa zaś nad przebiegiem pracy, facylitując spotkania, dbając o dobrą komunikację i eliminując z pracy zespołu potencjalne przeszkody.
Metoda Scrum w obszarze HR
W wielu organizacjach zwinnych obok tradycyjnych produktów technologicznych funkcjonują również produkty związane z obszarem HR, np.: proces onboardingu, doświadczenie kandydata lub pracownika. W zespole scrumowym zbudowanym wokół onboardingu Właścicielem produktu może być osoba z działu People and culture, która odpowiada za realizację tego procesu. Tymczasem rola Scrum Mastera często bywa międzyobszarowa i nie musi być przypisana do konkretnego działu.
Scrum Master może jednocześnie wspierać więcej niż jeden zespół, jednak należy pamiętać, że jego rola w procesie scrumowym jest kluczowa. Musi bacznie monitorować współpracę zespołu, uczestniczyć w jego spotkaniach i włączać się tam, gdzie potrzebna jest dodatkowa komunikacja lub facylitacja.
Praca w Scrumie – organizacja zadań
Produkt jest rozwijany w małych krokach (nazywanych często Przyrostami) w Sprintach – krótkich cyklach pracy. Każdy Sprint w Scrumie jest ograniczony czasowo i choć jego ostateczna długość zależy od zespołu, to klasyczne Sprinty trwają od tygodnia do maksymalnie miesiąca. W praktyce największy wpływ na czas Sprintu ma tempo wytwarzania poszczególnych elementów produktu.
Każdy Sprint opiera się na liście zadań, czyli sprint backlogu. Nie powstaje ona odgórnie – przy planowaniu Sprintu zespół ocenia zasoby, estymuje czas potrzebny na realizację poszczególnych działań i wybiera zadania z dużo szerszej puli backlogu produktu, którym zarządza Właściciel produktu. Na każdym etapie Przyrostu zakłada się priorytety i określa Definicję ukończenia – listę kryteriów, jakie powinien spełnić produkt na danym etapie rozwoju. Zarówno Sprinty, jak i Przyrosty w Scrumie posiadają określone cele, nad których spójnością czuwa Właściciel produktu. Zespół developerski ma dzięki temu czas na pracę operacyjną.
Jak wygląda codzienna praca w Scrumie?
Na początku każdego Sprintu zespół spotyka się, by zaplanować działania. Podczas planowania określony zostaje czas potrzebny na realizację poszczególnych zadań. Zespół decyduje też o wstępnym przydziale zadań na podstawie dostępności i kompetencjach poszczególnych developerów.
Postępy w pracy omawiane są podczas Daily Scrumów (lub Stand-Up Meetingów), czyli krótkich (ok. 15-minutowych), prowadzonych w swobodnej atmosferze spotkań, gdzie każdy developer ma za zadanie odpowiedzieć na trzy pytania:
- Co było przedmiotem mojej pracy wczoraj?
- Nad czym pracuję dzisiaj?
- Czy coś mnie blokuje?
Warto pamiętać, że celem dyskusji nie jest kontrolowanie, czy żaden z developerów aby na pewno się nie obija. Chodzi przede wszystkim o uspójnienie poziomu wiedzy i bieżącą świadomość wyzwań, z którymi mierzą się inni członkowie zespołu. Wszystkie zasady w Scrumie mają w końcu za zadanie wspierać transparentność i ułatwiać współpracę.
Inne wydarzenia w Scrumie
Zwieńczeniem Sprintu jest Demonstracja (Demo, Przegląd), czyli prezentacja wytworzonych w jego czasie usprawnień i funkcji produktowych. Czasami na spotkania demonstracyjne są zapraszani również zewnętrzni interesariusze, np. zespół sprzedaży czy marketingu. Po zakończeniu Sprintu lub dłuższego cyklu przyrostowego odbywa się Retrospekcja (Retro), czyli spotkanie podsumowująco-ewaluacyjne. Pozwala wyciągnąć wnioski z wcześniejszych działań, przekazać sobie feedback i wprowadzić niezbędne usprawnienia do kolejnego Sprintu.
Scrum – prosty czy trudny?
Jak mawiał Ken Schwaber, jeden z jego pionierów: „Scrum jest prosty, ale trudny”. Prosty, ponieważ jego zasady można z sukcesem zmieścić w krótkim artykule. Trudny, bo nie o same zasady tu chodzi, a o ludzkie postawy, które wymusza ta zwinna metodyka. Zespół scrumowy nie da sobie rady bez konkretnych planów i wytycznych. Jasna estymacja czasu wymaganego na zadania i przydzielenie konkretnych odpowiedzialności utrudnia przeciąganie projektów w nieskończoność. Codzienne spotkania i współodpowiedzialność za backlog zmuszają do dyskusji i szukania rozwiązań. Jednak inwestycja w zwinne podejście projektowe może się opłacić, zwłaszcza, jeżeli chcemy pracować w bardziej dojrzałym i elastycznym zespole.
Czy Scrum jest dla nas dobrym rozwiązaniem? Jest tylko jeden sposób, żeby się przekonać – spróbować i wprowadzić go do firmowych projektów, aby przeanalizować i ocenić jego działanie.
Źródła:
