Grupa AF Software&Marekting

Czy Scrum zawsze równa się agility?

Każde przedsięwzięcie, którego się podejmujemy, może być postrzegane jako pojedynczy projekt. Zazwyczaj zakładamy, że jego realizacja ma przynieść określony efekt i być obarczona jak najmniejszym ryzykiem niepowodzenia. Tę uniwersalną zasadę można stosować zarówno w przypadku pieczenia ciasta, jak i prowadzenia skomplikowanych projektów z zakresu IT.

Specyfika pracy w branży IT wyróżnia się przede wszystkim dużą zmiennością, niestabilnością oraz stosunkowo niewielką przewidywalnością. Projekty o wysokim stopniu złożoności są prowadzone miesiącami, jeśli nie latami. W tak długim czasie zmieniają się potrzeby użytkowników, na rynku pojawiają się nowocześniejsze rozwiązania, a to, nad czym firma pracowała ostatnimi miesiącami, okazuje się często przestarzałe i bezużyteczne. Tworzenie produktów, które nie mają wartości, wiąże się z marnotrawstwem nie tylko pieniędzy, ale także innych niematerialnych zasobów, np. motywacji pracowników.

Complexity i odpowiedź na problem złożoności

Rozwiązaniem problemu tworzenia bezwartościowych produktów, obarczonych licznymi błędami są zwinne metodyki zarządzania (agile project management). Wyróżniają się one iteracyjnym podejściem do tworzenia produktu – zamiast działać zgodnie z wyznaczonym kilkanaście miesięcy wcześniej planem, nie bacząc na realia rynkowe i rzeczywiste potrzeby klienta, działa się w krótkich (maksymalnie miesięcznych) iteracjach, których efektem jest nie cały produkt, a jego funkcjonalny wycinek.

Dostarczając regularnie, w stosunkowo krótkich odstępach czasu, działający produkt do przetestowania, można na bieżąco kontrolować zmieniające się środowisko, budować wartość, a w przypadku błędu – usunąć go niskim kosztem. Pośród metodyk agilowych można wymienić przede wszystkim Scrum, Kanban, Lean oraz Extreme Programming. Bez wątpienia w Polsce najbardziej rozpowszechniony jest Scrum, którego zasady zostały opracowane na kilkunastu stronach Scrum Guide.

Kilkanaście stron przepisu na sukces

No właśnie – kilkanaście stron, kilka prostych zasad i mamy przepis na sukces. Ale czy na pewno? Aby odpowiedzieć na te pytanie warto cofnąć się do początków zarządzania projektami. Konieczność działania zgodnie z planem, organizacja działań wielu ludzi i tworzenie produktu w obrębie ustalonego procesu przyszły wraz z rewolucją przemysłową i otwarciem pierwszych linii produkcyjnych Forda. Produkcja taśmowa samochodów wymagała stworzenia dokładnego planu działania, który uporządkuje i zmaksymalizuje efektywność całego procesu – od momentu sięgnięcia po pierwszą część do momentu opuszczenia fabryki przez samochód. Produkcja taśmowa cechowała się dużą powtarzalnością, a zaplanowanie z góry całego działania faktycznie pomogło je zoptymalizować. Ford odniósł sukces, a model kaskadowy na wiele lat stał się jedynym słusznym sposobem wytwarzania produktów.

Nic dziwnego, że coś, co sprawdzało się przez wiele lat, weszło w świadomość zarówno przedsiębiorców, jak i zwykłych pracowników. Problemy zaczęły się wraz z rewolucją technologiczną i zmianą specyfiki wytwarzanych produktów – bardziej skomplikowanych, wrażliwych na zmiany i podlegających szybkiej dezaktualizacji. Z resztą zmieniły się nie tylko produkty, ale też ludzie je wytwarzający. Na rynek pracy weszły osoby z pokolenia Y i Z, które mają pomysł na siebie, chcą mieć realny wpływ na tworzone produkty i jak ognia unikają kontroli. Z drugiej strony wciąż duża część przedsiębiorców i osób decyzyjnych w firmach bazuje na modelu kaskadowym. I tutaj dochodzi do starcia między nowym a starym. Nowe pokolenie i nowa specyfika produktów kontra tradycyjne metody ich wytwarzania oraz obawa przed ryzykiem związanym z wprowadzaniem nowych rozwiązań.

Mamy scruma, co dalej?

Czy zatem Scrum Guide i jego jasne zasady są przepisem na sukces? Nie, nie są. Bo stosowane bez zrozumienia nie wnoszą wartości, a jedynie są pożeraczem czasu (te wszystkie spotkania, a na co to komu?). Co więcej, tak naprawdę nie potrzeba Scrum Guida i scruma, aby być agile.

Zwinność to indywidualne nastawienie każdego z nas, działanie empiryczne i kierowanie się określonymi wartościami oraz szukanie możliwości do udoskonalenia, a także traktowanie ewentualnych porażek jako lekcji na przyszłość. Te lekcje niejednokrotnie są bolesne i kosztowne, jednak owocują zyskaniem nowej wiedzy, która usprawnia całą organizację i eliminuje powtórzenie podobnych błędów w przyszłości. Zarówno scrum, jak i inne metodyki (Kanban, Lean, XP itd.) opierają się na kilku głównych trzonach: iteracyjności, przyrostowości, przepływie informacji i komunikacji. Odrzucając jakikolwiek framework i próbując tworzyć produkt w sposób zwinny, prędzej czy później i tak wpisalibyśmy się w ramy postępowania któregoś z nich.

Scrum, wszędzie scrum – ale dlaczego?

Czy scrum jest tak spopularyzowany, bo wszędzie pasuje i jest uniwersalny? Odpowiedź również brzmi: NIE. Jest łatwy do wprowadzenia, jednak jego stosowanie nie zawsze ma sens. Na jednym z wydarzeń związanych ze zwinnym zarządzaniem produktami padło następujące pytanie:

„Team, który pracuje nad produktem, ma bardzo rozproszone kompetencje i zadania, a praca żadnego z członków zespołu deweloperskiego nie jest uzależniona od pracy innego. Komunikacja w moim zespole jest zerowa, a do brania udziału w Daily Scrumach trochę ich zmuszam. Odpowiadają na te trzy pytania zawarte w Scrum Guidzie, ale jednych to nie interesuje, a inni nie rozumieją ich sensu. Co mam zrobić, żeby zespół widział wartość w Daily?”.

Odpowiedziano pytaniem na pytanie: „Jaką Ty widzisz wartość w tych spotkaniach?”. Okazało się, że produkt, nad którym trwały prace, nie wymagał współpracy poszczególnych członków zespołu ze sobą, nie było konieczności mikroplanowania każdego dnia, bo poszczególne funkcjonalności nie nachodziły na siebie. Optymalnym rozwiązaniem w tym przypadku była zmiana specyfiki daily scruma i wprowadzenie bardziej rozbudowanej tablicy kanbanowej.

Czy stosowanie scruma zapewnia firmie agility?

Czy stosowanie się do zasad zawartych w Scrum Guide, jest receptą na bycie agile? Nie jest, bo nie każdy produkt czy projekt tego wymaga. Stosowanie dla samego stosowania nie sprawia, że w efekcie końcowym pojawia się wartość, którą chcieliśmy osiągnąć. Inną kwestią jest sama świadomość pracowników i przedsiębiorców – jako kraj postkomunistyczny nie pod każdym względem jesteśmy gotowi na to, aby przyjąć zachodnie wzorce. To, co sprawdza się w krajach z inną kulturą organizacyjną, niekoniecznie będzie pasowało na naszym podwórku.

Wprowadzając agilowe metodyki zarządzania projektami w firmie, warto przede wszystkim obserwować środowisko, potrzeby danej organizacji oraz podejście i nastawienie pracowników – ich dojrzałość i gotowość do wyjścia z waterfallowej strefy komfortu na rzecz odpowiedzialności i pracy zespołowej. Kierowanie się rozumem, wyczuciem i określonymi wartościami (nawet na drodze błędów) prawdopodobnie przyniesie lepsze efekty niż niejednokrotnie sztuczne stosowanie zasad zawartych w podręcznikach. Innymi słowy: be more agile in being agile.