W 2001 roku 17 programistów spotkało się w ośrodku narciarskim w Snowbird w Utah. Kent Beck, Martin Fowler i piętnaście innych nazwisk, które dziś brzmią jak panteon branży IT. Trzy dni rozmów, kartki papieru i jeden dokument, który miał zmienić sposób, w jaki budujemy oprogramowanie. Problem w tym, że większość zespołów, które dziś twierdzą, że pracują w Agile, zna te cztery wartości z pamięci, ale w praktyce stosuje je mniej więcej tak, jak nowojorski taksówkarz przestrzega ograniczenia prędkości.
Ludzie i interakcje ponad procesy i narzędzia
Pierwsza wartość brzmi pięknie: ludzie i interakcje ważniejsze od procesów i narzędzi. W praktyce poznałem zespoły, które miały 12 różnych narzędzi do zarządzania projektami, trzy rodzaje daily standup i obowiązkowy szablon raportu z retrospekcji. Każda interakcja przepuszczona przez workflow w Jira, każda rozmowa udokumentowana w Confluence, każdy pomysł zatwierdzony przez komitet sterujący.
Problem nie polega na tym, że narzędzia są złe. Problem polega na tym, że gdzieś między Snowbird w 2001 a dzisiejszymi korporacjami Agile zmienił się w zestaw procedur, które mają udowodnić audytorowi, że jesteśmy zwinni. Spotkałem project managera, który spędził pół dnia na aktualizacji burn-down chart zamiast porozmawiać z developerem siedzącym trzy metry dalej. Wykres wyglądał świetnie, produkt nie działał, ale przynajmniej mieliśmy dane.
Działające oprogramowanie ponad obszerną dokumentację
Druga wartość dotyczy tego, co faktycznie dostarczamy. W oryginalnym Manifesto nie chodziło o to, żeby w ogóle nie pisać dokumentacji. Chodziło o to, że 200 stron specyfikacji technicznej, którą nikt nigdy nie otworzy, nie zastąpi kodu, który można uruchomić i przetestować.
Widziałem transformację Agile w banku, gdzie zespół składał się z ośmiu osób. Product Owner spędził sześć tygodni na pisaniu user stories według szablonu zatwierdzonego przez governance. Każda historia miała cztery sekcje, osiem pól obowiązkowych i trzy załączniki. Kiedy w końcu developer dostał zadanie, połowa wymagań była już nieaktualna, bo biznes zdążył zmienić zdanie dwa razy. Ale dokumentacja była kompletna, więc formalnie wszystko grało.
Współpraca z klientem ponad negocjacje umów
Trzecia wartość mówi o relacji z klientem. W 2001 roku autorzy Manifesto mieli dość projektów, gdzie specyfikacja była świętym dokumentem, a każda zmiana wymagała aneksu do umowy i eskalacji do zarządu. Pomysł był prosty: jeśli klient siedzi obok zespołu i widzi, co się dzieje, łatwiej zbudować to, czego naprawdę potrzebuje.
Dwadzieścia lat później mamy Product Ownerów, którzy widzą zespół raz na dwa tygodnie podczas Sprint Review. Mamy stakeholderów, którzy dostają prezentację PowerPoint zamiast dostępu do testowego środowiska. Mamy umowy ramowe z klauzulą o współpracy w duchu Agile, gdzie każda godzina pracy programisty musi być zaraportowana w systemie i zatwierdzona przez dwa szczeble zarządzania. Współpraca istnieje, ale tylko w zakładce numer siedem w Excelu.
Reagowanie na zmiany ponad podążanie za planem
Czwarta wartość brzmi jak manifest rewolucji: zmiany są OK, plan może się zmienić, świat nie jest przewidywalny. W rzeczywistości większość organizacji traktuje tę wartość jako teoretyczną ciekawostkę, którą można zacytować na szkoleniu, ale nie stosować w prawdziwym projekcie.
Spotkałem się z zespołem, który pracował w dwutygodniowych sprintach, ale roadmapa produktu była zamrożona na 18 miesięcy do przodu. Każda zmiana wymagała zgody komitetu, który zbierał się raz na kwartał. Sprint Planning trwał pół dnia, bo trzeba było dopasować zadania do planu zatwierdzonego rok wcześniej przez kogoś, kto już nie pracuje w firmie. Zespół formalnie robił Scruma, ale w praktyce realizował projekt wodnospałowy podzielony na 26 iteracji.
Co zostało z Snowbird
Cztery wartości z 2001 roku nie straciły sensu. Problem polega na tym, że łatwo je zacytować, trudniej zastosować. Łatwo powiedzieć, że ludzie są ważniejsi niż procesy, kiedy nikt nie pyta, dlaczegoDaily trwa 45 minut i wymaga trzech protokołów. Łatwo mówić o działającym oprogramowaniu, kiedy nikt nie liczy, ile czasu zespół spędza na dokumentacji, której nikt nie przeczyta. Łatwo deklarować współpracę, kiedy klient siedzi w innym mieście i komunikuje się przez e‑mail z działem sprzedaży.
Może warto zapytać: ile z tych czterech wartości faktycznie stosujemy, a ile tylko udajemy na slajdach?
Źródła
- Beck K., Fowler M. i in., “Manifesto for Agile Software Development”, agilemanifesto.org, 2001.
Zdjęcie: Gustavo Fring / Pexels
