Cieszące się w środowisku IT ogromną popularnością zwinne metodyki pracy (Agile) umożliwiają m.in. opracowywanie dokładnie takich produktów, jakich oczekują odbiorcy, a co więcej – bez przekraczania założonego budżetu czy harmonogramu. Zwinność wymaga jednak konsekwencji oraz – co znacznie trudniejsze – zmiany mentalności. Jak przekonać do zwinności osoby sceptyczne wobec wprowadzania daleko idących zmian?
Każdy, kto kiedykolwiek próbował wyjaśnić sens zwinnych metodyk pracy laikowi w tej dziedzinie, najpewniej szybko napotkał na niezrozumienie. Zadania na pewno nie ułatwia mnogość agile’owych ram postępowania (frameworks), które tutaj dla ułatwienia będziemy nazywać metodykami. Najlepiej znane to m.in. Scrum, Kanban, DSDM, FDD czy Lean Software Development. Z czasem zaczęły powstawać ich mutacje, np. Scrumban będący połączeniem dwóch pierwszych. Ponieważ na temat każdej z tych metodyk powstała już obszerna literatura i niemożliwe jest opisanie wszystkich, tutaj skupimy się na jednej z najpopularniejszych, czyli na Scrumie. Zanim opowiemy o jego szczegółach, na początek trochę zamierzchłej historii.
Średniowieczny sprint
Jest rok 1015. W Strasbourgu rozpoczynają się prace nad dużym kościołem w stylu ottońskim, które ukończono w roku 1048. Powstała wówczas dość masywna, raczej ascetyczna konstrukcja o charakterystycznych dla tego nurtu w architekturze grubych murach. Tak zaczęła się historia jednej z najpiękniejszych katedr Notre Dame we Francji, która w tamtym czasie na pierwszy rzut oka w bardzo niewielkim stopniu przypominała obiekt znany dzisiejszym turystom. Dlaczego „jednej z katedr”? W całym kraju noszących tę nazwę gotyckich kościołów o różnej randze jest całkiem sporo, wśród nich oczywiście najbardziej znana paryska Notre Dame, ale są też inne, np. w Nicei czy w podparyskim Pontoise, gdzie Notre Dame stworzyli Pierre i Nicolas Le Mercier, pierwsi ze znanej w XVI i XVII wieku francuskiej rodziny architektów.
Zaraz po zakończeniu pierwszego etapu prac rozpoczęto modernizację obiektu i przekształcenie go w kościół utrzymany w stylu romańskim, co ukończono w roku 1180. Natychmiast przystąpiono do transformacji do – w tym czasie nowego i szybko zdobywającego popularność – stylu gotyckiego (1180–1235), co przyniosło typowy dla tego nurtu spad dachu, a w kolejnych rundach prac dobudowanie naw bocznych i charakterystycznych wsporników (1235–1275). Imponujący front od strony zachodniej, na której znajduje się wejście (pamiętajmy, że w tamtym czasie kościoły były obowiązkowo orientowane), powstał w latach 1275–1340, a następnie był jeszcze kilkakrotnie rozbudowywany. Wreszcie wieńcząca dach iglica powstała między rokiem 1419 a 1439.
Zauważmy, że kolejne etapy rozbudowy następowały praktycznie natychmiast po sobie. Po pierwszym stadium budowy powstał jednak w pełni funkcjonalny kościół, który już spełniał swoje zadanie (tzn. mógł przyjąć dużą liczbę wiernych) i teoretycznie można było spokojnie pozostawić go w takiej formie, jak to stało się w przypadku wielu innych obiektów sakralnych w całej Francji i nie tylko. A jednak zaraz po każdym etapie prac następował kolejny, który dodawał do strasburskiej Notre Dame kolejne elementy. I tu wracamy do Scruma.
Produkt, który działa
Jak czytamy w oficjalnym przewodniku po Scrumie (Scrum Guide), istotą tej metodyki są tzw. sprinty. Są to ograniczone czasowo do jednego miesiąca etapy pracy nad danym produktem. W tym okresie powstać ma jego działająca wersja możliwa do wypuszczenia na rynek. Oznacza to więc, że po maksymalnie czterech tygodniach pracy otrzymujemy już coś, co spełnia swoje podstawowe zadania. Jest to więc odpowiednik strasburskiej Notre Dame z roku 1048 – może i nie ma wielu ozdób, nie ma iglicy, nie ma wspaniałego portalu czy potężnych witraży (na potrzeby przykładu załóżmy, że wszystkie style architektoniczne były dostępne średniowiecznym budowniczym jednocześnie), ale wciąż był to pojemny kościół. Tym właśnie w Scrumie jest bardzo podstawowa, ale jednak działająca wersja.
I znów podobnie jak w przypadku rozbudowy strasburskiej Notre Dame, tak i w Scrumie kolejne cykle pracy (sprinty) następują bezpośrednio po sobie i polegają na wzbogacaniu ukończonej wersji o dodatkowe funkcje czy elementy. Co ważne, podczas sprintu nie są wprowadzane zmiany mogące stanowić zagrożenie dla realizacji jego celu, a oczekiwania względem jakości nie są obniżane. Nie oznacza to, że niemożliwe jest wprowadzenie zmian w zakresie prac. Klient może to jednak zrobić jedynie za pośrednictwem tzw. właściciela produktu (Product Owner). Gdyby więc zleceniodawca budowy katedry uznał, że potrzebuje więcej witraży i nie chciałby czekać do końca realizacji danego etapu budowy, musiałby wynegocjować ich dodanie z architektem, który w średniowieczu był również głównym budowniczym i czuwał nad postępem prac.
Oprócz właściciela produktu Scrum przewiduje także rolę Scrum Mastera, czyli tzw. lidera służebnego (servant leader). Jest to osoba, której głównym i podstawowym zadaniem jest usuwanie przeszkód mogących utrudnić zespołowi realizację powierzonego zadania. Gdyby Scrum Master był obecny na placu budowy średniowiecznej katedry, prawdopodobnie zajmowałby się zapewnieniem noclegu poszczególnym budowniczym, a także dbałby o niezakłócone dostawy materiałów i narzędzi, ale również pomagał rozwiązywać konflikty między pracownikami czy wspierałby robotników w doskonaleniu sposobów pracy. Poza wspomnianymi dwiema rolami oraz po prostu członkiem zespołu deweloperskiego, Scrum nie wyróżnia żadnej z osób pracujących przy projekcie. Członkowie liczącego od trzech do dziewięciu osób zespołu muszą umieć zorganizować się sami (choć może im w tym pomóc Scrum Master), a w jego skład wchodzą osoby o wszystkich kompetencjach pozwalających ukończyć powierzone zadanie. Nie ma wśród nich jednak podwładnych, przełożonych ani efektownych nazw stanowisk.
Wróćmy do sprintów, które stanowią odpowiedź na szybko zmieniające się oczekiwania klientów oraz uwarunkowania rynkowe. Stopniowe dodawanie elementów do podstawowej wersji produktu umożliwia natomiast częste i regularne upewnianie się, czy oczekiwania klienta są spełnione. Jest to szczególnie cenne w przypadku klientów, którzy nie do końca są przekonani, jakiego produktu tak naprawdę oczekują. Efekt pracy po każdym sprincie pokazuje bieżący stan produktu. Co więcej, powtórzmy, po każdym sprincie jest to produkt możliwy do wypuszczenia na rynek.
Lotnisko utopione
Przede wszystkim jednak sprinty pozwalają unikać tworzenia nadmiernie rozbudowanych produktów według zbyt ambitnych początkowych wizji zleceniodawców. Scrum zakłada, że znacznie ważniejsze od tworzenia opasłej dokumentacji oraz szczegółowego planowania ostatecznej wersji produktu jest po prostu dostarczenie podstawowego produktu, który działa, a potem – w razie potrzeby – wzbogacenie go o dodatkowe funkcje, które nie mają dla realizacji zadania znaczenia krytycznego.
O tym, jak groźne może być śmiałe nakreślenie zbyt ambitnego planu, a następnie uparte dążenie do jego realizacji, świadczy inny przykład z branży budowlanej (choć nie tylko), a mianowicie nieukończone jak dotąd berlińskie lotnisko Brandenburg. Jego przeciągająca się od lat budowa to praktyczne podręcznikowe studium działania kosztu utopionego (sunk cost), czyli kosztu już poniesionego i niemożliwego do odzyskania. Bardzo często decyzja o rozpoczęciu jakiegoś projektu zapada bez pełnej świadomości skali towarzyszących mu wyzwań. Kiedy natomiast realizacja zadania zaczyna napotykać już nawet nie wyzwania, ale bardzo poważne problemy, osoby decyzyjne często nakazują kontynuację projektu, ponieważ pochłonął już mnóstwo pieniędzy, sił i czasu. Szkoda więc, by te wszystkie nakłady poszły na marne. Rzecz w tym jednak, że taka decyzja tylko przedłuża i tak już bardzo kosztowną agonię przedsięwzięcia, generując przy tym oczywiście jeszcze większe wydatki.
Cofnijmy się na moment o niecałe 30 lat, kiedy w związku z nasycającymi się dwoma istniejącymi lotniskami obsługującymi Berlin zdecydowano się na realizację dość mocarstwowego planu stworzenia kolejnego portu lotniczego, mającego osiągnąć przepustowość nawet 34 milionów pasażerów rocznie (czyli mniej więcej połowę ruchu paryskiego portu Charles de Gaulle i dwukrotność ruchu warszawskiego Okęcia). Plany budowy lotniska z bardzo wielu powodów okazały się zbyt ambitne i nikt nie przewidział, jak duża będzie skala wyzwania. Wstępnie zakładano, że jego koszt wyniesie dwa miliardy euro, choć dwa lata temu podliczono, że budowa pochłonęła już grubo ponad dwa razy więcej, a obecnie mało kto odważa się podać pod nazwiskiem realny koszt inwestycji. Poprzestańmy więc na przypomnieniu opinii Dietera Faulenbacha da Costy, niemieckiego eksperta lotniczego, który już w 2013 roku ocenił, że całe lotnisko Brandenburg nadaje się do wyburzenia i zbudowania od nowa.
Budowa berlińskiego lotniska to nie tylko przykład brnięcia w nietrafioną inwestycję pod wpływem kosztów utopionych, ale również zgubnego realizowania projektów metodą Waterfall. Stanowi ona przeciwieństwo zwinności (w tym przypadku zwłaszcza Scruma) i opiera się na bardzo rozbudowanej fazie szczegółowego projektowania finalnego produktu, po której zakończeniu następuje realizacja, a dopiero po niej ocena odbioru rezultatu pracy przez klientów. Scrum natomiast umożliwia badanie reakcji klienta na bieżąco i wprowadzanie poprawek do już istniejących wersji. Teoretycznie po każdym sprincie klient może powiedzieć: „Stop, taka wersja nam wystarczy”.
W przypadku Waterfalla nie ma żadnych wersji – jest po prostu produkt końcowy, na który klient musi cierpliwie poczekać, by ocenić, czy spełnia stawiane przed nim oczekiwania. Oczywiście może być i tak, że w trakcie realizacji zadania uwarunkowania rynkowe mogły zmienić się wielokrotnie. I to tak bardzo, że – nawet wykonany wiernie według nakreślonych na początku szczegółowych wytycznych – produkt końcowy może być przestarzały już w momencie wypuszczania na rynek.
Aby lepiej zrozumieć porównanie Scruma i Agile w ogóle z Waterfallem, warto zerknąć do „Manifestu programowania zwinnego”, opracowanego m.in. przez twórców Scruma właśnie.
Manifest programowania zwinnego
Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy zaczęliśmy bardziej cenić:
Ludzi i interakcje | od | procesów i narzędzi |
Działające oprogramowanie | od | szczegółowej dokumentacji |
Współpracę z klientem | od | negocjacji umów |
Reagowanie na zmiany | od | realizacji założonego planu |
Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.
Źródło: https://agilemanifesto.org/
Nie wszystko naraz
Mimo ewidentnych słabości Waterfalla wiele firm jest do niego bardzo przywiązanych, tłumacząc to swoją kulturą organizacyjną. Ponieważ wprowadzanie w organizacji Agile wymaga często gruntownej przebudowy myślenia o codziennej pracy, a także np. rolach w organizacji, do tak ambitnego podejścia dobrze zabrać się z pewną ostrożnością. Mówiąc wprost, niezapowiedziana wizyta w gabinecie prezesa oraz oświadczenie mu od progu, że oto przychodzimy z genialnym pomysłem na rozwój firmy, ale musimy natychmiast pozbyć się kierowników, spłaszczyć strukturę i przestać zawracać sobie głowę rozbudowanymi prezentacjami w PowerPoincie, najprawdopodobniej nie jest najlepszym pomysłem.
Nie oznacza to naturalnie, że duże organizacje o ustabilizowanej hierarchii oraz długiej historii są w jakiś naturalny sposób odporne na Agile. Nie są, ale tak jak słonia można zjeść tylko po kawałku, tak samo w dużej (nierzadko skostniałej) firmie wprowadzanie zwinności możliwe jest metodą małych kroków. Dobrym miejscem na testowanie Agile są więc np. działy o niestrategicznym znaczeniu, którym łatwiej przychodzi uzyskanie zgody na eksperymentowanie z różnymi metodykami pracy. Szybkość realizowania projektów oraz ich dopasowanie do potrzeb rynkowych może stanowić silny dowód na sensowność wprowadzenia zwinności w kolejnych działach czy pionach firmy.
Mateusz Żurawik jest redaktorem MIT Sloan Management Review Polska i certyfikowanym Scrum Masterem (PSM I)
