Scrum po ludzku: jak dziala i czy pasuje poza IT

Czym właściwie jest Scrum i skąd się wziął, skoro nie z IT?

Scrum ma korzenie znacznie starsze niż branża IT, choć dziś najczęściej kojarzy się właśnie z nią. Termin pojawił się w 1986 roku w artykule w Harvard Business Review, którego autorzy, Hirotaka Takeuchi i Ikujiro Nonaka, opisali, jak powstają nowe produkty w firmach takich jak Canon, Honda czy Xerox. Co istotne, nie były to firmy informatyczne, tylko produkujące samochody, kserokopiarki i drukarki.

Autorzy nazwali swoje podejście grą w rugby, bo cały proces przypominał im drużynę, która podaje sobie piłkę i wspólnie pokonuje dystans. Zamiast dzielić pracę na sztywne etapy przekazywane między działami, jeden wielofunkcyjny zespół prowadził projekt od początku do końca. Ta myśl stała się fundamentem tego, co dziś znamy jako Scrum.

Sam framework w obecnej formie to zasługa Kena Schwabera i Jeffa Sutherlanda, którzy w 1995 roku opisali ramy postępowania zgodnego z metodyką Scrum. Od 2009 roku zasady te są spisane w publicznym dokumencie The Scrum Guide, a jego najnowsza wersja pochodzi z listopada 2020 roku. Ważne, że to nie jest zamknięty podręcznik, tylko zestaw wytycznych, które możesz dopasować do własnej organizacji.

Scrum bywa mylony z Agile, ale to nie to samo. Agile to filozofia zarządzania projektami, a Scrum to konkretne ramy postępowania, które tę filozofię wdrażają w życie. Zasady Scrum opierają się na trzech filarach: przejrzystości, inspekcji i adaptacji. W praktyce oznacza to, że zespół regularnie pokazuje efekty pracy, sprawdza, co poszło dobrze, a co źle, i na tej podstawie zmienia sposób działania, czasem z dnia na dzień.

Jak wygląda praca w Scrumie krok po kroku na konkretnym przykładzie?

Wyobraź sobie, że prowadzisz firmę produkcyjną i dostajesz zlecenie, które wymaga pracy kilku działów. Scrum to iteracyjne i przyrostowe ramy zarządzania procesem produkcyjnym, które pozwalają ogarnąć takie zadanie. Co ważne, nie jest ograniczony tylko do tworzenia oprogramowania, choć tam stosuje się go najczęściej. Zamiast planować całość z góry, dzielisz pracę na krótkie, równe odcinki czasu, czyli sprinty. Zespoły Scrum są autonomiczne i wielofunkcyjne, co oznacza, że ludzie w nich mają wszystkie kompetencje potrzebne do wykonania zakresu pracy. Dzięki temu nie czekają na innych, tylko działają.

1. Ustalasz cel sprintu i wybierasz zadania z listy priorytetów, czyli product backlogu.
2. Zespół planuje, jak wykonać wybrane zadania, tworząc sprint backlog.
3. Przez cały czas trwania sprintu zespół pracuje nad wybranymi zadaniami.
4. Na koniec sprintu odbywa się sprint review, czyli przegląd tego, co udało się zrobić.
5. Po przeglądzie zespół zastanawia się, co poprawić w sposobie pracy na kolejny sprint.

Kluczowe role to właściciel produktu, który pilnuje listy priorytetów, oraz scrum master, który dba o to, by ramy postępowania działały. Sam proces opiera się na trzech filarach: przejrzystości, inspekcji i adaptacji. To znaczy, że wszystko jest widoczne, regularnie sprawdzane i można szybko zmienić podejście, gdy coś zaburza pracę.

Jakie role są w Scrumie i kto za co odpowiada w praktyce?

Zanim odpowiemy, kto za co odpowiada, jedno sprostowanie: Scrum nie powstał w IT. Koncepcję opublikowano w 1986 roku w Harvard Business Review, a jej autorzy, Hirotaka Takeuchi i Ikujiro Nonaka, wzorowali się na firmach produkujących samochody, kserokopiarki i drukarki. Nazwa wzięła się z rugby, bo cały proces wykonuje jeden wielofunkcyjny zespół, który "podaje piłkę" i przesuwa się do przodu jako całość.

W tej drużynie są trzy jasno podzielone role. Product Owner, czyli właściciel produktu, decyduje, co zespół robi w pierwszej kolejności. Prowadzi listę zadań, tak zwany product backlog, i pilnuje, żeby praca szła na rzeczy, które dają klientowi realną wartość. To osoba, która zna rynek i potrafi powiedzieć "nie" pomysłom bez pokrycia.

Drugą rolą jest Scrum Master. Nie jest szefem ani kierownikiem projektu, tylko opiekunem procesu. Dba o to, żeby zespół trzymał się zasad, usuwa przeszkody w pracy i pilnuje, żeby spotkania nie zamieniły się w jałowe dyskusje. W praktyce to ktoś, kto pilnuje rytmu: sprintów, czyli krótkich iteracji, i codziennych ustaleń.

Trzecią rolą jest zespół, czyli osoby, które faktycznie wykonują pracę. Są autonomiczne i same decydują, jak zrealizować zadania ze sprint backlogu. Wystarczy, że właściciel produktu powie "co" ma powstać, a zespół sam ustala "jak" to zrobić. Tak zbudowany podział sprawia, że każdy wie, za co odpowiada, a całość opiera się na przejrzystości i częstej inspekcji postępów, co pozwala szybko wyłapać błędy, zanim urosną do dużych problemów.

Kiedy Scrum ma sens poza IT, a kiedy lepiej go nie stosować?

Scrum wywodzi się z branż, które nie miały nic wspólnego z IT. Hirotaka Takeuchi i Ikujiro Nonaka opisali w Harvard Business Review, jak zespoły w Canon, Honda czy Xerox pracują nad nowym produktem. Zamiast dzielić pracę na sztywne etapy i przekazywać ją dalej, cała grupa szła do przodu razem, podając sobie zadania jak piłkę w rugby. Stąd zresztą nazwa: scrum to po angielsku młyn, czyli sposób wznowienia gry w tym sporcie.

Ta obserwacja stała się podstawą frameworku, który w 1995 roku Jeff Sutherland i Ken Schwaber opisali jako ramy postępowania dla zespołów. Dziś Scrum wygląda tak: ustalasz krótki sprint, zwykle dwa do czterech tygodni, i w tym czasie zespół robi konkretną partię pracy. Na początku planujecie, co wejdzie do sprintu, na końcu robicie przegląd efektów i sprawdzacie, co można poprawić. Całość opiera się na trzech filarach: przejrzystości, czyli wszyscy widzą, co się dzieje, inspekcji, czyli regularnym sprawdzaniu postępów, i adaptacji, czyli zmianie podejścia, gdy coś zaburza proces.

Gdzie to ma sens poza IT? Wszędzie tam, gdzie praca jest iteracyjna i przyrostowa, a zespół ma wpływ na to, jak ją wykona. Biuro rachunkowe może w jednym sprincie wdrożyć nowy obieg dokumentów dla klientów, firma produkcyjna przetestować zmianę na jednej linii, zanim wdroży ją wszędzie. Kluczowa jest autonomia: zespół sam decyduje, jak osiągnie cel, i ma do tego wszystkie potrzebne kompetencje. Jeśli decyzje i tak podejmuje szef poza zespołem, a praca jest powtarzalna i przewidywalna, Scrum doda tylko narzuconych rytuałów.

Nie stosuj go tam, gdzie nie ma czego ulepszać po każdej iteracji. Dział księgowości zamykający miesiąc według sztywnego kalendarza nie zyska na sprintach, bo nie może zmienić terminów ani zakresu pracy. Podobnie produkcja, która działa jak taśma i nie ma wpływu na kolejność zadań. Tam lepiej sprawdzą się prostsze metody: kanban do wizualizacji pracy czy lean do eliminowania strat. Scrum wymaga gotowości do eksperymentowania i uczciwej rozmowy o błędach, a to często trudniejsze niż sama zmiana organizacji pracy.

Jakie są trzy największe pułapki przy wdrażaniu Scruma poza IT?

Najczęstszy błąd to potraktowanie Scruma jako sztywnego regulaminu, a nie ram postępowania. Scrum, zgodnie ze Scrum Guide, to iteracyjne i przyrostowe ramy zarządzania procesem produkcyjnym, które mogą być stosowane poza tworzeniem oprogramowania. Gdy zespół w biurze rachunkowym czy firmie produkcyjnej zaczyna traktować sprinty i ceremonie jak biurokratyczny obowiązek, ginie cała elastyczność, o którą w tym chodzi.

Druga pułapka to pomylenie ról. W Scrumie nie ma szefa, który rozdaje zadania. Jest za to product owner, czyli właściciel produktu, który pilnuje, żeby zespół robił to, co naprawdę ważne. Gdy właściciel produktu nie istnieje albo jest nim każdy, zespół scrumowy zaczyna pracować nad wszystkim naraz, a sprint zamienia się w chaos. Bez jasnego wskazania, kto decyduje o priorytetach, nawet najlepszy zespół nie wykorzysta potencjału metodyki.

Trzecia pułapka pojawia się, gdy zespół udaje, że wszystko rozumie, zamiast korzystać z tego, co Scrum daje w zamian za dyscyplinę. Chodzi o trzy filary: przejrzystość, inspekcję i adaptację. W praktyce oznaczają one, że zespół regularnie pokazuje, co powstało, sprawdza, czy idzie w dobrym kierunku, i z dnia na dzień potrafi zmienić sposób pracy. Jeśli sprint review jest tylko formalnym spotkaniem, a wnioski lądują w szufladzie, to zamiast metodyki scrum dostajesz kolejną naradę.

Żeby nie wpaść w te pułapki, warto trzymać się kilku zasad:

• Ustal, kto jest właścicielem produktu i ma ostatnie słowo w sprawie priorytetów.
• Traktuj sprint jako eksperyment, a nie termin, który musi się udać za wszelką cenę.
• Po każdym sprincie pytaj zespół, co można poprawić, i wdrażaj te zmiany od razu.
• Nie dodawaj nowych zadań w trakcie sprintu, nawet jeśli wydają się pilne.
• Pamiętaj, że Scrum to framework, a nie gotowy przepis. Dopasuj go do swojej firmy, ale nie wyrzucaj filarów, na których stoi.

Scrum wywodzi się z branż, które nie miały nic wspólnego z IT. Koncepcja powstała na podstawie studiów przypadków firm produkujących samochody, kserokopiarki i drukarki, a jej autorzy nazywali to podejściem holistycznym, bo cały proces wykonywał jeden wielofunkcyjny zespół. Jeśli producent samochodów potrafił to wykorzystać, Twoja firma też może. Klucz to zrozumieć, że Scrum nie jest celem, tylko narzędziem do szybszego uczenia się i lepszego planowania.

Od czego zacząć wdrażanie Scruma w swoim zespole?

Zacznij od jednego, konkretnego projektu, a nie od przebudowy całej firmy. Scrum, jak wyjaśniają jego twórcy, Jeff Sutherland i Ken Schwaber, to ramy postępowania, które powstały po to, by zespoły mogły uczyć się na własnych doświadczeniach. Wybierz zadanie, które ma jasny cel i da się je podzielić na mniejsze części. Może to być przygotowanie nowej oferty dla klientów albo wdrożenie nowego sposobu obsługi zamówień. Nie ruszaj wszystkiego naraz.

1. Ustal, kto w twoim zespole będzie pełnił rolę właściciela produktu, czyli osoby, która decyduje, co jest najważniejsze do zrobienia i w jakiej kolejności.
2. Wybierz czas trwania sprintu, na przykład dwa tygodnie, i trzymaj się go przez pierwsze miesiące, żeby zobaczyć, jak działa rytm pracy.
3. Na początku każdego sprintu zaplanujcie wspólnie, co dokładnie zrobicie w jego trakcie, i zapiszcie to w widocznym miejscu, na przykład na tablicy.
4. Po zakończeniu sprintu pokażcie efekty swojej pracy i poproście o opinię osoby spoza zespołu, na przykład klienta albo szefa działu sprzedaży.
5. Na koniec porozmawiajcie o tym, co poszło dobrze, a co warto poprawić, i wprowadźcie jedną, konkretną zmianę na kolejny sprint.

Kluczowa jest rola scrum mastera, czyli osoby, która pilnuje, żeby zespół trzymał się ustalonych zasad i nie zgubił celu. To nie jest szef, tylko przewodnik, który pomaga rozwiązywać problemy i usuwa przeszkody, na przykład w postaci niejasnych wymagań. Zespół scrumowy powinien być autonomiczny i samodzielnie decydować, jak wykonać powierzone zadania, bo to on ma wszystkie kompetencje potrzebne do ich realizacji. Taki układ sprawdza się nie tylko w IT, ale też w marketingu czy firmie produkcyjnej, bo zasady pracy są uniwersalne.