Przejdź do treści

Co łączy SCRUM i trzy świnki?

Czy Scrum może mieć coś wspólnego ze świnkami? Zaraz się o tym przekonacie… A czy może mieć cokolwiek wspólnego z facylitacją?

Czym w ogóle jest ten Scrum, o którym wszyscy teraz mówią? Na to pytanie odpowie nam Kamil – Scrum Master w firmie Deployed.

Zacznijmy od początku. Wszystko zaczęło się od branży IT, a właściwie niedoskonałości w dostarczanym oprogramowaniu. Brało się ono z ograniczeń wykorzystywanych od lat procesów i sposobów zarządzania, które najzwyczajniej w świecie przestały wystarczać. Klasyczne metody zakładały, że już przed rozpoczęciem pracy wszystko, czego potrzebujemy jest nam znane. Możemy przewidzieć potencjalne zagrożenia oraz odpowiednio się na nie przygotować. Ale świat jest zdecydowanie bardziej złożony, otaczają nas niewiadome i potencjalne ryzyka, o których możemy nawet nie wiedzieć. Predykcyjny model rozwoju przestaje mieć w naszym przypadku sens.

Prawie 20 lat temu, bo w 2001 roku, w stanie Utah spotkało się 17 specjalistów z branży IT, którzy zmęczeni ciągłym korzystaniem z metodyk kaskadowych zaproponowali coś konkurencyjnego. Spisali oni zasady nazywane Manifestem Zwinnego Tworzenia Oprogramowania – https://agilemanifesto.org/ . Ta rewolucyjna koncepcja zmieniła oblicze rozwoju oprogramowania. Zaczęto stawiać na bezpośredni kontakt z ludźmi, rozmowy, klienta, informację zwrotną z rynku i wykorzystanie jej w celu szybkiej rozbudowy produktu. Coś, co na początku było stosowany tylko przez osoby szalone szybko rozrosło się do czegoś, co teraz śmiało możemy nazwać kulturą Agile. Zaczęły powstawać nowe narzędzia pomagające dostosować pracę zespołów do ciągle zmieniających się potrzeb rynku. Metodyki zwinne zaczęto wykorzystywać w innych branżach niż programowanie, np. produkcja sprzętu AGD, czy marketing.

Jednym z wiodących narzędzi zaliczanych do kategorii tych „zwinnych” jest wspomniany Scrum. Swoją popularność zawdzięcza nie tylko swojej prostocie, ale też świetnej literaturze, która bardzo dogłębnie opisuje w jaki sposób wdrożyć go w firmie. Jednakże łatwo tutaj wpaść w pułapkę – szachy też mają proste zasady, a jednak na świecie jest tylko garstka Grand Masterów. Poprawne zastosowanie Scruma oznacza, że momentalnie na powierzchnię wypłyną wszystkie problemy i dysfunkcje. W takiej sytuacji nie można zrzucić winy na narzędzie, ale należy działać. Scrum niczego za nas nie rozwiąże, sami musimy poprawić proces naszej firmie.

W klasycznym modelu organizacja posiada wiele zespołów o wąskich specjalizacjach: analityków biznesowych, projektantów, architektów, testerów, programistów, czy nawet osoby tworzące specyfikację. Scrum zaciera bariery między tymi rolami i wszystkim daje jeden cel – dostarczenie działającego produktu. Nazywa się ich Zespołem Deweloperskim (rozwijającym produkt). Oprócz nich potrzebny będzie ktoś, mający wizję projektu. Osoba, będąca w stanie ustawić odpowiednie priorytety dla wykonywanych zadań – to nasz Właściciel Produktu (Product Owner). Ostatnim elementem układanki jest Scrum Master – osoba pilnująca przestrzegania procesu wewnątrz organizacji. Jednakże jego rola nie ogranicza się tylko do tego. Często przedstawia się go jako Lidera Służebnego, takiego Mistrza Jedi, który stara się usuwać przeszkody znajdujące się na drodze do sukcesu Zespołu Deweloperskiego, wspiera Właściciela Produktu, edukuje wszystkich w zakresie metodyk zwinnych (i nie tylko) no i pełni rolę facylitatora zawsze wtedy, kiedy jest to konieczne.

Nakłonienie grupy ludzi (zwłaszcza programistów) do otwarcia się nie zawsze jest łatwe. Właściwie to prawie nigdy nie jest, ale Scrum to coś więcej niż role i spotkania. Wprowadza on nowy sposób myślenia opierający się się na pięciu wartościach: zaangażowanie, skupienie, otwartość, odwaga i szacunek. Scrum Master musi obudzić w sobie wewnętrznego trenera i nauczyciela, aby wytłumaczyć ludziom jak ważne jest odważne mówienie o problemach, skupienie się na celu, otwarcie na wiadomość zwrotną, wzajemny szacunek oraz zobowiązanie się do osiągnięcia wspólnego celu.

Jednym z moich ulubionych wydarzeń w Scrumie jest Retrospektywa Sprintu. To spotkanie odbywające się cyklicznie na koniec 2-4 tygodniowego okresu, w którym zespół wytworzył działający fragment produktu. Zebrani omawiają przebieg pracy, relacje międzyludzkie, procesy, narzędzia. Starają się znaleźć elementy, które działają dobrze, takie, które można poprawić oraz jeżeli to możliwe to szukają możliwości na poprawę sposobu pracy. Dobre przygotowanie oraz facylitacją Scrum Mastera są tutaj kluczowe.

Typowa Retrospektywa Sprintu będzie wyglądała tak:

  • zespół zbierze się w 1 sali,
  • SM zaznaczy na tablicy 3 kolumny (działa, nie działa, może działać lepiej),
  • każda osoba przygotuje karteczki z propozycjami,
  • odbędzie się głosowanie,
  • grupa omówi ewentualne kolejne kroki.

Utrzymanie odpowiedniego poziomu zaangażowania zespołu nie jest łatwe już na pierwszym spotkaniu, nie mówiąc już o piątym, czy dwudziestym. Trenerzy Agile oraz Scrum Masterzy na całym świecie nieustannie szukają sposobów na urozmaicenie Retrospektywy. Nie ogranicza się to tylko do zadawania innych pytań, czy rzucania haseł:

  • Like, Doesn’t Like, Would Like (LLL),
  • Add, Keep, Remove,
  • Start, Stop, Continue,
  • Keep, Add, Less, More.

Niektórzy wykazują się niesamowitą pomysłowością i wymyślają historyjki, które angażują uczestników spotkania. Do moich ulubionych należy ta o Trzech Małych Świnkach. Na pewno każdy w dzieciństwie słyszał tę starą angielską bajkę o tym, jak to trzy małe, biedne świnki wyruszyły w świat w poszukiwaniu szczęścia. Na pewnym etapie każda z nich zbudowała sobie domek, a zaczynając od pierwszej – słomiany, druga – drewniany i trzecia – z cegły. Przechadzający się zły wilk bez większego trudu zniszczył pierwsze 2 domki i pożarł biedne świnki, jednakże trzeci budynek okazał się nie do sforsowania. Nawiązanie do naszego produktu jest bardzo proste:

  • słoma – wszystko, co jest wykonane źle w projekcie i za niedługo się zawali,
  • drewno – rzeczy, które na razie działają, ale nie znamy dnia ani godziny,
  • cegła – solidne fragmenty naszego projektu, docelowo wszystko powinno być naszą cegłą.

Takich historyjek i porównań, które mają zaangażować uczestników spotkania jest więcej. Popularne jest porównanie projektu do rozpędzonego samochodu ciągnącego za sobą spadochron. Zespół musi odnaleźć elementy „silnika” i „spadochronu” w projekcie. Mamy też motyw łodzi płynącej wzdłuż wybrzeża, gdzie wiatr to coś, co pcha nas do przodu, fale nieustannie nam przeszkadzają, wystające skały to potencjalne zagrożenie a naszym celem jest bezpieczny ląd. Pomocne może być posiłkowanie się ilustracjami, rekwizytami i wszystkim, co może rozpalić wyobraźnię osób obecnych w sali. Zachęcam do nieustannego eksperymentowania i wymyślania własnych historyjek. Możecie podzielić się nimi w komentarzach 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *