Projekt zaplanowany od A do Z na sześć miesięcy wcześniej trafia do klienta dopiero na koniec - i wtedy okazuje się, że rynek zmienił się w trakcie, a klient potrzebuje czegoś innego niż to, co zamówił pół roku temu. To klasyczny problem tradycyjnego, kaskadowego zarządzania projektami, który Agile rozwiązuje, zmieniając sposób pracy z jednego dużego planu na serię krótkich, sprawdzanych na bieżąco iteracji.
Agile nie jest jedną konkretną metodyką, a zbiorem wartości i zasad, z których wyrosły konkretne podejścia - Scrum, Kanban i inne. Zrozumienie tych zasad pomaga wybrać właściwe narzędzia dla konkretnego zespołu, zamiast wdrażać metodykę "bo tak się teraz robi".
W tym artykule pokażę, czym Agile różni się od tradycyjnego zarządzania projektami, jakie ma fundamentalne wartości i kiedy faktycznie się sprawdza, a kiedy niekoniecznie.
Czym jest Agile
Agile to podejście do zarządzania projektami oparte na krótkich iteracjach, częstym sprawdzaniu rezultatów z odbiorcą i elastycznym reagowaniu na zmiany, zamiast trzymania się sztywnego planu ustalonego na samym początku. Nazwa pochodzi od Manifestu Agile - dokumentu spisanego w 2001 roku przez grupę praktyków oprogramowania, którzy mieli dość projektów ginących w nadmiernej dokumentacji i planowaniu.
Zamiast pytać "czy zrobiliśmy wszystko zgodnie z planem", zespół pracujący w Agile pyta częściej "czy to, co zrobiliśmy, faktycznie rozwiązuje problem odbiorcy". Ta zmiana pytania ma większy wpływ na codzienną pracę niż konkretna nazwa metodyki wypisana na tablicy.
Agile vs tradycyjne, kaskadowe zarządzanie projektami
Planowanie z góry vs planowanie iteracyjne
W modelu kaskadowym (waterfall) cały projekt jest planowany na starcie - wymagania, harmonogram, budżet - a praca przebiega przez kolejne fazy bez zawracania. W Agile zespół planuje szczegółowo tylko najbliższą iterację, na przykład sprint, a dalsze plany pozostają elastyczne i dopracowywane na bieżąco.
Planowanie najbliższej iteracji w praktyce odbywa się na spotkaniu znanym jako Sprint Planning - to właśnie tam zespół decyduje, co konkretnie wejdzie do najbliższych tygodni pracy, zamiast ustalać to raz na początku całego projektu.
Sztywny zakres vs elastyczny zakres
Tradycyjne podejście traktuje zakres jako stały punkt odniesienia - każda zmiana wymaga formalnego procesu i często wpływa na cały harmonogram. Agile zakłada, że zakres będzie się zmieniał, bo wraz z postępem pracy zespół i klient lepiej rozumieją, czego faktycznie potrzeba.
Jeden duży odbiór vs częste przeglądy
W modelu kaskadowym klient widzi efekt pracy zwykle na koniec projektu. W Agile efekt pracy jest sprawdzany po każdej iteracji, więc błędne założenia wychodzą na wierch po kilku tygodniach, nie po kilku miesiącach.
Cztery wartości Manifestu Agile
Manifest Agile opisuje cztery proste, ale wpływowe priorytety: ludzie i interakcje ważniejsze niż procesy i narzędzia, działające oprogramowanie ważniejsze niż obszerna dokumentacja, współpraca z klientem ważniejsza niż formalne negocjowanie kontraktu, oraz reagowanie na zmiany ważniejsze niż trzymanie się sztywnego planu.
Te priorytety nie są listą reguł do mechanicznego wdrożenia, a raczej kompasem do podejmowania decyzji w sytuacjach, w których trzeba wybrać między dwoma dobrymi pomysłami - na przykład między dodaniem kolejnej strony dokumentacji a szybszym dostarczeniem działającej funkcji do sprawdzenia przez klienta.
To nie znaczy, że dokumentacja, plan czy kontrakt nie mają znaczenia - znaczy, że w sytuacji konfliktu Agile wybiera elastyczność i komunikację nad formalnością.
Najpopularniejsze metodyki Agile
Scrum
Scrum organizuje pracę w sprinty - zwykle dwutygodniowe iteracje z jasno określonymi rolami, spotkaniami i artefaktami. Więcej o tym przeczytasz w artykule Scrum - kompletny przewodnik dla początkujących.
Kanban
Kanban skupia się na wizualizacji pracy na tablicy i ograniczaniu liczby zadań w toku, bez sztywnego podziału na iteracje. Szczegóły opisuje artykuł Czym jest metodyka Kanban i komu się sprawdzi.
Inne podejścia
Extreme Programming (XP) kładzie nacisk na praktyki techniczne, takie jak programowanie w parach i ciągła integracja. Lean skupia się na eliminowaniu marnotrawstwa w procesie. Większość zespołów w praktyce miesza elementy kilku podejść, dopasowując je do własnych potrzeb, zamiast trzymać się jednej metodyki w czystej formie.
Kiedy Agile się sprawdza, a kiedy nie
Agile dobrze działa w projektach, w których wymagania mogą się zmieniać, a produkt da się dostarczać w kawałkach - oprogramowanie, marketing, produkty cyfrowe. Słabiej sprawdza się w projektach, gdzie zmiana w połowie pracy jest bardzo kosztowna albo niemożliwa, na przykład w budowie fizycznej infrastruktury, gdzie nie da się "dostarczyć połowy mostu" i sprawdzić reakcji klienta.
Wiele firm korzysta z podejścia hybrydowego - część projektu, np. ogólny harmonogram i budżet, planowana jest z góry, jak w modelu kaskadowym, a sama realizacja oprogramowania czy konkretnych funkcji przebiega iteracyjnie, zgodnie z zasadami Agile. Nie trzeba wybierać jednego podejścia w czystej formie dla całej organizacji.
Przykład z praktyki
Firma budująca aplikację mobilną planowała pełny zakres funkcji na sześć miesięcy do przodu, zgodnie z modelem kaskadowym. Po trzech miesiącach okazało się, że użytkownicy testowi w ogóle nie korzystają z funkcji uznanej za priorytetową, a brakuje innej, o której zespół nawet nie myślał na etapie planowania.
Po przejściu na dwutygodniowe sprinty z regularnym testowaniem wersji z użytkownikami, zespół zaczął dostosowywać kolejne funkcje na podstawie realnych reakcji, nie wstępnych założeń. Finalny produkt różnił się znacząco od pierwotnego planu, ale lepiej odpowiadał temu, czego użytkownicy faktycznie potrzebowali - czego nie dałoby się odkryć, czekając na jeden duży odbiór na koniec projektu.
Najczęstsze błędy przy wdrażaniu Agile
- Wdrażanie nazw bez zmiany sposobu pracy - nazwanie spotkania "Daily Scrum" nie czyni zespołu zwinnym, jeśli sposób planowania i reagowania na zmiany się nie zmienia.
- Traktowanie Agile jako braku planowania - elastyczność nie znaczy chaos, Agile wciąż wymaga planowania, tylko w krótszych horyzontach.
- Kopiowanie procesu innego zespołu bez adaptacji - to, co działa w jednym zespole, nie musi działać w innym bez dostosowania do realnych warunków.
- Ignorowanie wartości na rzecz rytuałów - wykonywanie spotkań Scrum bez rozumienia, czemu właściwie służą, prowadzi do pustych formalności.
Jak zacząć wdrażać Agile w zespole
Najlepiej zacząć od jednej konkretnej zmiany, nie od wdrożenia całej metodyki naraz - na przykład krótszych iteracji pracy z regularnym przeglądem efektów, zamiast jednego dużego planu na pół roku. Po kilku iteracjach zespół naturalnie zauważa, które elementy Scruma czy Kanbana faktycznie mu pomagają, a które są zbędną formalnością w jego konkretnym kontekście.
Pomaga też wprowadzenie regularnego przeglądu samego procesu pracy, nie tylko efektów projektu - krótka rozmowa po każdej iteracji o tym, co utrudniało pracę, działa podobnie jak retrospektywa w Scrumie, niezależnie od tego, którą konkretną metodykę zespół wybierze.
Jak Taskello wspiera pracę w Agile
Taskello łączy elementy obu najpopularniejszych podejść - tablicę Kanban z limitami pracy w toku oraz natywne zarządzanie sprintami znane ze Scruma - bez konieczności wybierania jednej metodyki na starcie i trzymania się jej sztywno. Zespół może zacząć od prostej tablicy, a z czasem dodać sprinty, priorytety i checklisty Definition of Done, gdy faktycznie poczuje taką potrzebę.
Podsumowanie
Agile to nie jedna metodyka, a sposób myślenia o pracy projektowej - krótkie iteracje, częsty kontakt z odbiorcą i gotowość do zmiany planu, kiedy okazuje się, że pierwotne założenia były błędne. Scrum i Kanban są konkretnymi narzędziami wyrosłymi z tych wartości, nie odwrotnie.
Jeśli Twój zespół rozważa przejście na pracę w Agile, zacznij od pytania, który konkretny problem chcesz rozwiązać - zbyt długi czas do pierwszego feedbacku, brak elastyczności na zmiany, czy chaos w priorytetach - i wybierz podejście, które adresuje właśnie ten problem, zamiast wdrażać metodykę dla samej metodyki.
Niezależnie od wybranej metodyki, dobre podstawy - jasne priorytety zadań i sprawdzona metoda estymacji pracy - pozostają takie same. Więcej o tym przeczytasz w artykułach Priorytetyzacja zadań - sprawdzone metody i Estymacja zadań w zespole - jak szacować czas realizacji.