Moda na Scrum. Jak nie utracić korzyści związanych ze zwinnym rozwojem produktów IT?

Scrum w trendzie zwyżkowym

W 2017 roku fundusze Venture Capital zainwestowały w Stanach Zjednoczonych ponad 70 miliardów dolarów. Ta potężna, choć niższa o niemal 50 miliardów dolarów niż w szczycie bańki internetowej kwota, w większości trafiła do rąk założycieli startupów technologicznych, które w szybkim tempie przejęły wiodącą rolę w kolejnych barażach, kosztem tradycyjnych graczy. Wystarczy spojrzeć na przykłady popularnych dziś firm oferujących transport miejski, czy możliwość krótkoterminowego wynajęcia apartamentu, by zauważyć jak szybko ich rozwiązania zyskały miliony klientów na całym świecie. Na naszym rodzimym rynku również można dostrzec ten trend. Dobrym przykładem są tutaj start-up’y oferujące płatności internetowe, które znacząco zagroziły polskiemu sektorowi bankowemu.

Jak to się dzieje, że startupy tak sprawnie działają? Wykorzystują one najnowsze dostępne technologie do budowy innowacyjnych i potencjalnie szybko skalowanych rozwiązań, które tworzą wartość dla klienta. Dla zapewnia zarówno szybkości, jak i wysokiego poziomu jakości, większość technologicznych czempionów do rozwoju swoich produktów wykorzystuje różnego rodzaju tzw. zwinne metodyki. W ostatnich latach szczególną popularnością cieszy się Scrum, który został opracowany i jest cały czas rozwijany przez Kena Schwabera oraz Jeffa Sutherlanda. Według opublikowanego w 2018 roku największego na świecie badania zwinnych metod budowy oprogramowania (State of Agile Survey) 56% ankietowanych wykorzystuje do rozwoju swoich produktów właśnie Scrum.

Dlaczego zwinne metody zarządzania tak bardzo zyskują na popularności?

Prawdopodobnie najczęściej wymienianą korzyścią ich stosowania jest skrócenie czasu pomiędzy powstaniem idei, a jej wdrożeniem w postaci działającego na rynku produktu, dostępnego dla klientów. Miejsce tradycyjnych, wielomiesięcznych faz projektowania i ustalania docelowego funkcjonowania systemu, zajmują krótkie sprinty, trwające maksymalnie cztery tygodnie, podczas których zespół ma na celu zarówno opracowanie projektu, jak i zbudowanie i przetestowanie w pełni funkcjonalnego fragmentu systemu, który może być przekazany klientowi do użytku. Dzięki temu produkt szybko zaczyna generować korzyści biznesowe, ale przede wszystkim twórcy oprogramowania, od samego początku jego rozwoju, mogą otrzymywać informację zwrotną od klienta. Pozwala to na dobór odpowiedniego kierunku budowy kolejnych funkcjonalności i ograniczenie tzw. kosztów porażki. Zwinnie rozwijany produkt, w sytuacji rynkowego niepowodzenia, przynosi znacząco niższą stratę finansową, niż w przypadku budowy z wykorzystaniem tradycyjnego procesu wytwarzania oprogramowania, którego nieodłączną częścią jest długa faza analizy i projektowania, angażująca wiele zasobów. Jak dużą wagę mogą mieć straty związane z brakiem informacji zwrotnej od użytkownika, potwierdzają analizy Jima Johnsona, które pomimo swoich ograniczeń związanych z małą próbą badawczą, pokazują, że nawet 50% funkcjonalności oprogramowania nie jest regularnie wykorzystywane. Tak więc Scrum, który w swojej istocie zapewnia dostarczanie informacji zwrotnej w krótkich odstępach czasu, znacząco redukuje ryzyko tworzenia niepotrzebnych funkcjonalności, a zatem generuje oszczędności.

Kolejnym argumentem za stosowaniem metodyk zwinnych jest zwiększenie produktywności. Dzięki koncentracji na pracy nad niewielkimi cząstkami produktu w krótkich iteracjach, zespoły developerskie mogą zrealizować całość zakresu danego sprintu, od opracowaniu projektu po udostępnienie rozwiązania klientowi końcowemu, minimalizując tym samym tzw. „pracę w toku”. Mianem „pracy w toku” określa się wszelkie produkty prac nieprzynoszące żadnej wartości dla klienta, choć będące niezbędnymi do wytworzenia produktu końcowego. Przykładowo „pracą w toku” jest projekt architektury danego rozwiązania. Zatem dzięki minimalizacji „pracy w toku”, oraz skupieniu się na dostarczeniu klientowi prawdziwej wartości, zwiększona zostaje produktywność zespołu mierzona liczbą dostarczonych funkcjonalności w danym okresie czasu.     

Doświadczenie pokazuje również, że praca w zwinnych metodykach ma pozytywny wpływ na poziom satysfakcji i zaangażowania zespołu. Osoby obdarzone prawdziwym zaufaniem kierownictwa i realną możliwością decydowania o dalszym rozwoju produktu, są bardziej zmotywowane, wspierają się wzajemnie i uczą od siebie. Pozwala to zarówno na zwiększenie retencji wśród pracowników, co jest szczególnie istotne ze względu na bardzo konkurencyjny obecnie rynek pracy, jak i na poprawianie poziomu jakości wytwarzanego oprogramowania.

Kiedy już mowa o jakości, Scrum może znacząco przyczynić do jej ciągłej poprawy. Dzieje się tak, ponieważ członkowie zespołu developerskiego współpracują ze sobą na bieżąco i mogą sprawnie przekazywać sobie uwagi zarówno w momencie tworzenia kodu na podstawie specyfikacji, jak i podczas testów. Wszyscy developerzy odpowiadają wspólnie za realizację celu sprintu i starają się współpracować tak, by spełnić założone kryteria akceptacji. Zatem minimalizowane jest ryzyko braku wzajemnego zrozumienia, które finalnie może prowadzić do rozbieżności między założeniami i w efekcie końcowym – do obniżenia jakości produktu. Ryzyko to naturalnie występuje w tradycyjnej, kaskadowej metodzie wytwarzania oprogramowania, która zakłada, że poszczególnymi fazami projektu zajmują się oddzielne zespoły analityczne, developerskie oraz testujące, które nie mają wspólnego celu. Należy również nadmienić, że Scrum, którego jednym z podstawowych filarów jest adaptacja na podstawie zdobywanego doświadczenia, poprzez ceremonię retrospekcji, zapewnia możliwości ciągłej poprawy procesu twórczego, a w konsekwencji jakości produktu.

Niewątpliwe korzyści jakie niosą ze sobą zwinne metody rozwoju systemów IT skłaniają coraz więcej organizacji do ich wykorzystania. Jednak praktyka pokazuje, że wiele z nich nie osiąga zakładanych rezultatów, a nawet doświadcza pogorszenia wyników biznesowych. Dlaczego adopcja Scrum sprawia problemy i co jest kluczem do efektywnej transformacji? 

Łatwy do zrozumienia, trudny do opanowania

W przewodniku Scrum, zaledwie dziewiętnastostronicowym dokumencie opracowanym i aktualizowanym przez pierwszych twórców tej metodyki, już na samym początku można przeczytać, że jest on łatwy do zrozumienia, ale trudny do opanowania. Ramy postępowania opisane w przewodniku są rzeczywiście klarowne, a sam wywód jest przedstawiony w logiczny sposób.

Tak właśnie przewodnik przeprowadza czytelnika przez filary Scrum, jego wartości, zdefiniowane role, ceremonie oraz artefakty. Znając korzyści, które niesie ze sobą wykorzystanie Scrum oraz przeczytawszy nawet kilka razy przewodnik można dojść do wniosku, że osiągnięcie lepszych rezultatów biznesowych leży na ulicy niczym przysłowiowy pieniądz.

Jak funkcjonuje zespół Scrum?

W takiej sytuacji wiele organizacji podejmuje decyzję o próbie zmiany podejścia do tworzenia oprogramowania. Wówczas rozpoczyna poszukiwanie właściciela produktu, który będzie odpowiadał za opisywanie funkcjonalności i ich priorytetyzację, oraz Scrum Mastera, czuwającego nad zwinnym przebiegiem procesu tworzenia oprogramowania. Po znalezieniu osób do pełnienia nowych ról zespół Scrum rozpoczyna swoją pracę nad produktem i ustala długość sprintu. Następnie Scrum Master organizuje cykliczne spotkania, na które zaprasza cały zespół. Podczas pierwszego z nich – planowania sprintu – developerzy z listy zwanej backlogiem produktu wybierają funkcjonalności, nad którymi będą pracować w najbliższej przyszłości i ustalają cel sprintu. Następnie, każdego dnia sprintu, członkowie zespołu developerskiego spotykają się na piętnaście minut, by przekazać sobie informacje na temat pracy wykonanej poprzedniego dnia oraz planu na najbliższe osiem godzin. Na koniec sprintu, podczas ceremonii przeglądu produktu, zespół prezentuje efekty swojej pracy, które powinny składać się na funkcjonujący nowy fragment systemu, tzw. przyrost. Potem na ceremonii retrospekcji developerzy ustalają, w jaki sposób mogą lepiej ze sobą współpracować. Zaraz po zakończeniu sprintu, rozpoczyna się kolejny i zespół znów planuje realizację budowy kolejnych funkcjonalności.

Wygląda to na dość prosty sposób na osiągnięcie dużych korzyści i dlatego zdarza się, że organizacje decydujące się na rozwój produktu w metodyce Scrum zatrzymują się w swoim rozumieniu tego podejścia na tak powierzchownym poziomie. W rzeczywistości sprowadza się to jedynie do zmiany etykiet na wizytówkach i organizacji paru cykliczny spotkań, a nie prowadzi do realnej zmiany organizacyjnej i poprawy wyników firmy. I chociaż sama intensyfikacja interakcji między developerami, rezygnacja z rozciągniętych w czasie kolejnych faz rozwoju oprogramowania oraz zamknięcie cyklu budowy w krótszych sprintach, mogą przynieść pewne pozytywne efekty, nie będzie to jednak prawdziwa rewolucja. Bo taką właśnie zmianą jest Scrum w stosunku do tradycyjnych metod rozwoju produktów IT. Wykorzystując analogię sportową, można powiedzieć, że wykorzystanie Scrum w budowie systemów jest niemal taką zmianą, jaką wprowadzenie stylu V do skoków narciarskich w latach dziewięćdziesiątych, które pozwoliło skoczkom osiągać znacznie lepsze wyniki, poprawiając zarazem poziom bezpieczeństwa tej dyscypliny. 

Czego nie widać?

Wydaje się, że prawdziwą ideę Scrum w jednym zdaniu odnotował jeden z jego twórców, Jeff Sutherland, który stwierdził, że tylko absolutne połączenie celu i zaufania jest czymś, co tworzy wielkość. W swojej istocie Scrum nie opiera się wyłącznie na zdefiniowanych rolach, ceremoniach i artefaktach. Ramy postępowania nakreślone przez Scrum są nową filozofią pracy nad produktem, zakładającą obdarzenie zespołu developerskiego nie tylko odpowiedzialnością, ale przede wszystkim ogromnym zaufaniem w podejmowaniu decyzji.

Znaczącą zmianą w pracy nad produktem w metodyce Scrum jest wyjście kadry zarządzającej z roli decydentów, którzy swoimi nakazami kierują działaniami analityków, programistów, czy testerów. Zwinne metodyki zakładają, że liderzy organizacji nakreślają jedynie wysokopoziomowe cele, a ich głównym zadaniem jest ich odpowiednia komunikacja do właściciela produktu, a także, wbrew pozorom, również do zespołu developerskiego oraz pozostałych osób w organizacji. Kierownictwo ma zaś zaufanie, że dzięki komunikacji celów, zespół posiadający największą wiedzę o produkcie i użytkowniku końcowym, będzie mógł samodzielnie stworzyć wysokiej jakości oprogramowanie. Z drugiej strony, członkowie zespołu muszą zapewnić jak największą transparentność swoich działań, tak aby liderzy mieli pewność, że prace idą w dobrym kierunku. Dlatego też kadra zarządzająca i inni interesariusze są zapraszani na spotkania demonstrujące poczynione dostępy, a tablice Kanban, prezentujące postępy pracy w danym sprincie, są dostępne dla wszystkich zainteresowanych w organizacji. Transparentność jest zatem bardzo ważnym czynnikiem budującym zaufanie.

Adopcja zwinnych metodyk rozwoju produktów IT wymaga również pewnych zmian w  innych funkcjach w organizacji.  Znaczne skrócenie cykli rozwoju i wydawania produktu na rynek, pociąga za sobą potrzebę nowego rodzaju współpracy z zespołami prawnymi, finansowymi, czy kadrowymi.  Konieczność dużo częstszych interakcji jest wyzwaniem dla wielu organizacji. Wprowadzając Scrum w większości przypadków zmianie powinny ulec również procesy budżetowania, czy zarządzania kadrowego w rozumieniu polityki oceniania i wynagradzania pracowników, w tym premiowania.

Aby w pełni osiągnąć korzyści płynące z metodyk zwinnych, należy również pamiętać o odpowiedniej strukturze organizacyjnej. Często zapomina się o tym, że prawdziwy zespół Scrum powinien być cross-funkcjonalny, czyli nie może składać się jedynie z programistów. Aby realizować wszystkie fazy cyklu budowy produktu, niezbędne jest również posiadanie w zespole kompetencji analitycznych, UX-owych, czy testowych, a niekiedy też zupełnie innych. Tylko prawdziwie cross-funkcjonalny zespół będzie w stanie realizować swoje prace w sposób możliwie niezależny. Wraz z dojrzewaniem zespołu w stosowaniu metodyk zwinnych, jego członkowie pozyskują nowe kompetencje, tak by zapewnić zastępowalność kolegów, w przypadku ich nieobecności. Kolejną istotną kwestią dla osiągnięcia pełni korzyści z wykorzystania Scrum jest transformacja członków zespołu z grupy indywidualności w prawdziwą drużynę z poczuciem wspólnej odpowiedzialności za rozwijany produkt. Gdy członkowie zespołu czują się odpowiedzialni jedynie za fragmenty pracy, które osobiście realizują, często doprowadzają do sytuacji, w której ich koledzy mają więcej pracy, co finalnie negatywnie odbija się na wynikach sprintu. Zespołu Scrum powinny koncentrować się na optymalizacji swojego działania z perspektywy całego zespołu, a nie jego indywidualnych członków.

By osiągnąć prawdziwe korzyści wynikające ze zastosowania zwinnych metod zarządzania, należy zobaczyć w nich to, czego nie widać gołym okiem. Najlepszą możliwą sytuacją dla organizacji jest odkrycie istoty Scrum przez jej liderów. Bez otwartego poparcia najwyższego kierownictwa, adopcja Scrum staje się znacznie trudniejsza, ponieważ zgodnie z tezą postawioną przez Craiga Larmana, znanego na świecie propagatora metodyk zwinnych, kultura organizacyjna jest wynikiem struktury organizacyjnej, którą tworzą właśnie zarządzający. Bez odpowiedniej struktury, składającej się z cross-funkcjonalnych zespołów, i wyraźnego wsparcia dla zwinnych praktyk ze strony liderów, zespół developerski nie będzie miał ani narzędzi, ani odpowiedniego poczucia zaufania, by wspólnie budować przyrost produktu.