W ostatnich latach zwinne zarządzanie projektami stało się… modne. Wiele organizacji zdecydowało się wdrożyć pracę w sprintach i mówić o swojej działalności jako „zwinnej”. Czy sprinty i daily to klucz do sukcesu, czy może schodzą one na dalszy plan? I czym tak naprawdę, pod pokrywą wielu wpisów na wielu blogach, jest ten agile?


Termin agile pojawił się po raz pierwszy w roku 2001. Powstał podczas spotkania przedstawicieli alternatywnych metodyk programowania w resorcie Snowbird w Utah. Osoby obecne na spotkaniu sprzeciwiały się rozwojowi oprogramowania w oparciu o ciężką i skomplikowaną dokumentację. Efektem tego spotkania jest dokument Agile Manifesto (agilemanifesto.org), opisujący wartości, którymi powinien kierować się każdy, kto chce rozwijać oprogramowanie w sposób zwinny.

„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”

agilemanifesto.org

Z biegiem lat programowanie zwinne stało się bardzo popularną koncepcją i stojące za nim zasady zaczęły być adaptowane do innych kontekstów. Jednym z tych kontekstów jest oczywiście zarządzanie projektami. Te kilka zdań Manifestu Agile to fundament każdej zwinnej metodyki przeznaczonej dla project managerów i ich zespołów. Na podstawowych wartościach się jednak nie kończy. Aby ułatwić wdrażanie wartości agile do codziennej pracy, manifest programowania zwinnego jest również rozszerzony o 12 zasad zwinnego wytwarzania oprogramowania. Przekazują one dobre praktyki, które powinny zostać zaimplementowane do pracy zespołu, aby ta stała się prawdziwie zwinna. Według tych zasad każdy zespół pracujący zwinnie powinien między innymi: 

  • dostarczać wartościowe oprogramowanie w regularnych, krótkich iteracjach,
  • regularnie poszukiwać możliwości usprawnień w organizacji działań projektowych,
  • minimalizować ilość koniecznej do wykonania pracy,
  • oraz uznać działające oprogramowanie za podstawowy wskaźnik swojego postępu.

Teoria a wdrożenie

Czy jednak każde wdrożenie agile wygląda tak jak zaleca manifest? Oczywiście – nie. Kiedy rozmawiamy z pracownikami i managerami, którzy mieli okazję pracować według metodyk agile’owych, okazuje się, że bardzo wiele prób transformacji zwinnej kończy się fiaskiem.Przyjrzyjmy się najpopularniejszym scenariuszom porażek organizacji, które próbowały pracować zwinnie i przegrały.

Zespół czy cała firma?

Jedną z najpopularniejszych przyczyn porażek wdrożeń agile jest brak spójności w organizacji. Pewna firma otrzymała zlecenie stworzenia systemu wspierającego pracę jednego z działów w firmie klienta. Project Manager, po rozmowach z klientem i zapoznaniu się z jego problemami podjął decyzję o przyjęciu metodyki Scrum do realizacji projektu. Zespół rozpoczął prace nad projektem, zaplanował pierwszy sprint, a Project Manager (teraz wcielający się w rolę Product Ownera) razem z klientem zaczęli precyzować kolejne etapy inkrementalnego dostarczania wartości biznesowej. Kłopoty w realizacji projektu rozpoczęły się, kiedy PM otrzymał od swoich przełożonych polecenie wykonania pełnej dokumentacji projektu przed rozpoczęciem jego wdrożenia. Realizacja projektu została poważnie zaburzona, ponieważ szczegółowa dokumentacja została postawiona wyżej niż działające, wartościowe oprogramowanie. Ponadto organizacja wykazała się brakiem spójności w kwestii przyjętej metodyki pracy. 

Agile wymaga dostosowania się całej organizacji, która powinna dążyć do dostarczania interesariuszom realnej wartości biznesowej. Wartość ta jest z kolei stale redefiniowana wraz z rosnącym poziomem wiedzy na temat rozwiązywanego problemu.

Działające oprogramowanie główną miarą postępu

Przykładem braku zrozumienia istoty pracy zwinnej jest historia firmy, która chciała pozyskać zewnętrznego inwestora dla swojego innowacyjnego produktu. W tym celu, manager odpowiedzialny za innowacje zlecił swojemu pracownikowi wykonanie dokumentu prezentującego produkt potencjalnym inwestorom w sposób iteracyjny. Wykonanie dokumentu zajęło 3 razy więcej czasu niż pierwotnie zakładano – kilkanaście razy wdrażano w nim stylistyczne poprawki, aby był idealny. Potencjalni inwestorzy nie byli jednak zainteresowani wejściem w projekt. 

Gdzie popełniono błąd? Praca nad dokumentem zupełnie pominęła jedną z podstawowych koncepcji agile – częste wdrażanie nowych wersji „oprogramowania” dostarczających wartość biznesową. Stylistyczne poprawki, podczas kiedy w firmie brakowało wiedzy o zainteresowaniu potencjalnych inwestorów, były marnotrawstwem czasu i zasobów. Według niektórych praktyków lean i agile najprawdopodobniej nawet wykonywanie takiego dokumentu nie miało sensu – wystarczy zajrzeć do Agile Manifesto, aby dowiedzieć się, że kluczowe jest dążenie do minimalizacji ilości koniecznej pracy. W tej sytuacji zamiast tworzyć dokumenty zachwalające inwestycję, wystarczyło wykonać kilka rozmów, aby określić kierunek dalszych poszukiwań.

Zombie Agile

Przykłady przytoczone powyżej są dość oczywistymi naruszeniami idei stojącymi za zwinnymi metodykami zarządzania projektami. Jednak nie zawsze popełnione błędy są łatwe do zidentyfikowania. Częstym przypadkiem jest takie wdrożenie agile, w którym zespół realizuje wszystkie zasady wybranej metodyki, ale nie dostarcza wartości biznesowej. Jest to zjawisko tak popularne, że doczekało się swoich własnych opracowań oraz nazwy – Zombie Scrum. Jak sama nazwa wskazuje jest to termin odnoszący się do metodyki Scrum, niemniej jego znaczenie można rozszerzyć na wszystkie metodyki zwinne. Najprostszą definicją tego zjawiska jest „Scrum bez bijącego serca w postaci działającego oprogramowania”. Zespoły, które wpadły w pułapkę Zombie Agile z zewnątrz wyglądają na sprawnie funkcjonujące ekipy, które w regularnych odstępach czasu pokazują interesariuszom projektu postępy swoich prac, na przykład w postaci nowej wersji oprogramowania. Jednak jeśli przyjrzeć się bliżej temu, co zespół dostarcza w ramach iteracji, okaże się, że jego praca mija się z istotą zwinnych metodyk. Działające oprogramowanie lub użyteczna wartość biznesowa w innej postaci jest dla zespołu realizującego projekt szansą na uzyskanie informacji zwrotnej na temat kierunku, w którym zmierza projekt oraz pozwala na skorygowanie planu dalszego działania. Jeśli praca projektowa nie skupia się na dostarczaniu weryfikowalnej wartości biznesowej, niweluje ona wszystkie zalety zwinnych metodyk realizacji projektów.

Klucz do sukcesu agile

Autentyczne historie przytoczone powyżej świadczą o tym, że decyzja organizacji o wdrożeniu zwinnych metod pracy to dopiero początek drogi. Podążając nią, załoga firmy zetknie się z wieloma problemami oraz będzie musiała zmierzyć się z dużą liczbą starych nawyków i przyzwyczajeń. Podczas tej transformacji odpowiedzi warto szukać nie w sprintach, planowaniach czy retrospektywach, ale w podstawowych założeniach zwinności. Odpowiedzią na większość problemów związanych z wdrożeniem agile w firmie są wartości, które zostały spisane w Agile Manifesto. Zmiany wprowadzane w organizacji powinny wspierać wdrażanie wartości z manifestu, aby agile stał się narzędziem dostarczania większej wartości w krótszym czasie, a nie labiryntem spotkań, planowań, backlogów i sprintów.