7

W dzisiejszym wpisie odpowiadam na pytanie Kasi – project managera, który pracuje w organizacji pozarządowej.

Przypominam, że dla autorów najciekawszych pytań i pomysłów, które pojawiają się na moim blogu lub w podcastcie, czekają fajne nagrody. Nie inaczej będzie tym razem 😉 Kasia dostaje książkę Davida Allena „Getting Things Done”, ufundowaną przez Wydawnictwo Helion.

A oto pytanie:

Chciałam zapytać, czy metodę SCRUM da się zastosować w organizacji pozarządowej, która ma wielorakie pola działań?

Pracujemy zespołowo nad projektem, który przykładowo obejmuje stworzenie portalu internetowego, organizację dużego wydarzenia, wydanie publikacji, organizację szkoleń (wszystko połączone jednym tematem). Czyli celem projektu nie jest konkretny produkt tylko np. zmiana świadomości albo edukacja społeczeństwa. I prowadzą do tego celu oczywiście różne „produkty”.

Nie mamy jednak, tak jak w firmach, kontaktu z „klientami”, tylko sami weryfikujemy jakość naszych działań, a pod koniec projektu rozliczamy się z grantodawcą.

Jestem początkującym project managerem i zastanawiam się nad ulepszeniem pracy zespołu. Nie wiem, czy droga agile jest odpowiednia dla tego typu pracy?

Kasia

Moja odpowiedź na to pytanie jest bardzo krótka: tak, Scruma da się wdrożyć w organizacji pozarządowej 😉

Sam pomagałem kilku organizacjom pozarządowym przy wdrażaniu Scruma w ich projektach i, muszę przyznać, że nie różni się to tak bardzo od tego, z czym spotykam się w firmach IT. Wyzwania, wbrew pozorom, są bardzo podobne.

Dlaczego Scruma można stosować w projektach pozarządowych?

Bo Scrum jest metodą organizacji pracy zespołu, który pracuje nad rozwojem danego produktu. I nie ma znaczenia, czy produktem tym jest kampania marketingowa, czy organizacja jakiegoś wydarzenia. W projektach IT produktem jest określone oprogramowanie (aplikacja, system itp.). Ale przecież nie zawsze tak mysi być. To, co wytwarzacie bardzo mocno zależy od domeny, w której pracujecie. Inne produkty dostarczane w Dziale HR, inne w Marketingu, a jeszcze inne w jednostkach edukacyjnych. Scrum jako metoda nie ogranicza się do określonego typu produktów. Chociaż, wciąż najbardziej popularna jest w branży IT.

Dlaczego Scrum może pomóc Twojemu zespołowi w pracy? – 5 powodów

W swoim mailu zastanawiasz się, czy Scrum może jakoś pomóc Twojemu zespołowi w organizacji codziennej pracy w projekcie. Jak najbardziej tak. Poniżej zebrałem pięć, moim zdaniem, najważniejszych powodów, dla których warto rozważyć stosowanie Scruma w projektach nie-technicznych.

• Spójna metoda organizacji pracy. Masz gotowy model działania dla zespołu projektowego. Nie musisz nic wymyślać. Jest na tyle prosty, że możesz zacząć z niego korzystać od zaraz.
• Przejrzystość. Dzięki stosowaniu Scruma zyskacie ogromną przejrzystość pracy w projekcie. Przejrzystość na poziomie planowania, komunikowania się i codziennych działań.
• Produktywność. Scrum, to świetne narzędzie zwiększania produktywności zespołu. Dzielenie pracy na krótkie interwały, porządkowanie zadań, regularne przeglądy, dekompozycja wymagań, praca z listą najbliższych zadań do realizacji – to wszystko elementy bardzo dobrze zorganizowanego systemu produktywności. Wiele z nich znajdziesz na przykład w metodzie GTD Davida Allena.
• Zespołowość. Scrum, dzięki bardzo prostym mechanizmom, buduje zespół. Cementuje więzi. W tradycyjnych podejściu, różnie z tą pracą zespołową jest. Ludzie nie zawsze realizują wspólne cele. Bardzo często pracują w grupach, a nie w zespołach. W Scrumie jest inaczej. Scrum bardzo mocno stawia na zespół.
• Elastyczność. Dzięki Scrumowi możecie szybko reagować na zmieniające się wymagania rynku. Jest to metoda, która adresuje najbardziej palące wyzwania większości współczesnych projektów.

Wdrażanie Scruma w organizacjach pozarządowych – 8 najważniejszych lekcji

Jeżeli zdecydujesz się na wdrożenie Scruma w swojej organizacji, poniżej zebrałem 8 najważniejszych lekcji, które wyniosłem z pracy w organizacjach pozarządowych przy wdrażaniu Scruma. Mam nadzieję, że skorzystasz.

1. Zdefiniuj wspólny słownik. Trudność ze stosowaniem Scruma w innych organizacjach, niż IT, polega na tym, że wszystkie przykłady i wyjaśnienia, siłą rzeczy, odnoszą się do projektów informatycznych. Dlatego, na początek, dobrym ćwiczeniem, które sugerowałbym wam zrobić jest zbudowanie wspólnego słownika pojęć, stosowanych w Scrumie. Na przykład, co to jest Backlog Produktu albo Backlog Sprintu. Czym jest historyjka użytkownika? Co należy rozumieć przez kryteria ukończenia pracy w sprincie? I tak dalej… Wszystkie ezoteryczne słówka, których całe mnóstwo jest w Scrumie powinny być jasne dla wszystkich członków zespołu w projekcie.
2. Określ, co jest waszym produktem? To bardzo ważne, żeby wiedzieć, jaki produkt dostarczacie w projekcie. Produktem może być, jak zresztą sama zauważyłaś, na przykład stworzenie portalu internetowego lub organizacja określonego cyklu szkoleń. Wszystko to są bardzo konkretne produkty, które w ramach projektu musicie dostarczyć.
3. Stosuj historyjki użytkownika. Historyjki to bardzo fajne narzędzie, które ułatwi wam zbieranie wymagań produktu. Ale nie tylko. Dzięki historyjkom oraz epikom (duże historyjki) i tematom (zbiór powiązanych historyjek) będzie wam łatwiej wprowadzić pewien porządek w myśleniu i w pracy nad rozwojem produktu. Weźmy na przykład, wspomnianą przez Ciebie, „organizację szkoleń”. Czy organizacja szkoleń jest produktem, który dostarczacie w waszym projekcie? A może jest pod-produktem? Podejrzewam, że szkolenia są częścią większej całości – na przykład jakiegoś epika (dużej historyjki użytkownika), na realizację którego, oprócz samych szkoleń, może się również składać organizacja konferencji tematycznej w regionie, przeprowadzenie warsztatów, publikacja artykułów w ogólnopolskiej prasie, wpisów na blogu itp. Stosowanie historyjek użytkownika, epików i tematów pomoże wam lepiej „ogarnąć” Backlog Produktu.
4. Ustal, kto będzie pełnił rolę Właściciela Produktu. Napisałaś, że w trakcie realizacji projektu nie kontaktujecie się z „klientami”. To nic. Rola Właściciela Produktu bardzo mocno systematyzuje prace, związane z rozwojem produktu. I mimo, że nie macie typowych „klientów” w waszym projekcie, mocno zachęcam was do tego, żeby w waszym zespole został wytypowany ktoś, kto będzie odpowiedzialny za zarządzanie Backlogiem Produktu. Ktoś, kto będzie miał od waszej organizacji pełną autoryzację, żeby decydować o kolejności realizacji wymagań, definiować je i planować kolejne etapy realizacji projektu.
5. Zbuduj interdyscyplinarny zespół. Chodzi o zbudowanie takiego zespołu, który, w każdej kolejnej iteracji pracy (sprincie) będzie w stanie dostarczyć „działający” produkt. Zauważ, że słowo „działający” celowo wziąłem w cudzysłów, bo rozumienie „działania” w waszym przypadku będzie nieco inne, niż w projektach IT. Ważne w tym wszystkim jest to, że interdyscyplinarność zespołu w Scrumie to kwestia różnorodnych kompetencji. Innymi słowy, jeżeli jednym z waszych produktów będzie organizacja szkolenia, to w waszym zespole powinien pojawić się na przykład ktoś, kto będzie pełnił rolę koordynatora szkoleń, trenera, projektanta szkoleń.
6. Pracuj w krótkich cyklach wytwórczych. To, co normalnie zaplanowalibyście na dwanaście miesięcy w projekcie, dzielicie na krótsze cykle wytwórcze. Długość jednego cyklu nie powinna być dłuższa niż trzy miesiące. Ja taki okres obiegowo nazywam kadencją pracy. Każda kadencjaskłada się z kilku sprintów, a więc jeszcze krótszych odcinków pracy (2-4 tygodnie). Jeżeli przyjmiemy, że długość każdego sprintu wynosi dwa tygodnie, w trzymiesięcznej kadencji zrobimy sześć sprintów.
7. Zdefiniuj kryteria ukończenia pracy (ang. definition of done). Lista kryteriów ukończenia pracy z pewnością będzie odbiegać od tej, którą zwyczajowo można spotkać w projektach IT. Ale, znowu – to nie ma tutaj żadnego znaczenia. Ważne jest, żeby z punktu widzenia waszego projektu, bardzo precyzyjnie określić, co to znaczy, że produkt, który rozwijacie jest zrobiony. To będzie stanowiło dla was podstawę „odbioru” pracy w sprincie.
8. Trzymaj się reguł gry. To jest chyba najważniejszy punkt. W tych projektach pozarządowych, w których miałem okazję uczestniczyć największym problemem nie było to, że musieliśmy „przetłumaczyć” Scruma na język projektów nieinformatycznych. To „tłumaczenie”, wbrew pozorom, wcale nie było aż takie trudne. Największym wyzwaniem okazała się rzecz, wydawać by się mogło, zupełnie błaha – dyscyplina. Po tym, jak już mieliśmy wypracowany wspólny słownik i powstał model działania – brakowało konsekwencji i zaangażowania do realizacji przyjętej strategii. To się, po części wiązało z tym, że brakowało dobrych Scrum Masterów, którzy byliby „strażnikami” procesu i coachami zespołu. Jak było pod górkę, ludzie jakoś automatycznie wracali do starego trybu pracy.

Czy faktycznie są aż tak duże różnice?

Stosowanie Scruma w organizacjach pozarządowych, wbrew pozorom, nie różni się aż tak bardzo od stosowania tej metody w projektach informatycznych. Podstawowe wyzwanie sprowadza się do „przetłumaczenia” rzeczywistości IT na język projektów organizacji pozarządowych. Ale to, nie jest aż takie trudne.

Polecam zorganizowanie cyklu warsztatów, podczas których, z jednej strony, ludzie poznają podstawowe założenia i reguły pracy w Scrumie. Z drugiej, spróbują zbudować wspólny słownik i model działania w tej nowej, zwinnej rzeczywistości. 8 lekcji, o których wcześniej wspomniałem, to dobry materiał na agendę.

Trzymam kciuki i mocno Wam kibicuję! Myślę zresztą, że nie tylko ja. Prawda? 😉