10 typowych błędów projektów Agile, które Cię nie ominą

Szczegóły: Projekt agile’owy rozliczany fixed-price, czyli bez precyzyjnie określonych wymagań przy jednoczesnym oczekiwaniu od dostawcy stałej ceny i gwarancji prawa do codziennej kontroli prac.

Skutek: dostawca przestaje być transparentny, tworzy bufory na ryzyka, następuje utrata elastyczności i przeciąganie negocjacji CRów. Ostatecznie budżet zostaje przekroczony o 50%, a zakończenie projektu przesunięte o 11 miesięcy (60%).

Symptomy: Przejrzyj log kierownika projektu i sprawdź, które symptomy dotyczą Twojego projektu:

• Ruszam z nowym projektem na półtora roku, spory nowy system!
• Udało mi się przeprowadzić warsztaty wewnętrzne, na których wspólnie wypracowaliśmy listę wymagań. Może lista nie jest rozpisana bardzo szczegółowo, ale w końcu każdy zorientowany rozumie, co znaczy sprzedaż produktu online w 4 krokach: wybór produktu i podanie parametrów, możliwość wyboru dodatków, uzupełnienie danych do realizacji zamówienia i umowy, potwierdzenie i odpowiednie zgody.
• Mam potwierdzenie budżetu przez Zarząd.
• Wybieram dostawcę. Chcemy pracować z nim zwinnie, bo nie mamy szczegółowo rozpisanych wymagań. Poza tym chcemy mieć na bieżąco dobrą kontrolę nad jego pracą.
• Sukces! Wynegocjowaliśmy umowę. Wdrożenie jest podzielone na 4 funkcjonalne etapy, po każdym jest płatność dla dostawcy. W każdym etapie dostawca pracuje w sprintach, dookreśla wymagania, robi demo.
• Za mną pierwszy sprint. Praca idzie dobrze. Użytkownicy zmęczeni, ale zadowoleni. Doprecyzowywanie wymagań jest angażujące, ale też wymaga podejmowania decyzji i nowych ustaleń, których nie zawsze się spodziewaliśmy. Na demo zobaczyliśmy pierwszy ekran, bardzo obiecujące.
• Dzisiaj uczestniczyłem w dość zaskakujących warsztatach. Pracując nad krokiem wyboru produktu, analityk od dostawcy powiedział, że oczekiwany przez nas przycisk do obliczenia szacowanych kosztów nie mieści się w zakresie. I to ma być Agile? Eskaluję.
• Żenada. Wpadła nam ważna biznesowa zmiana od Zarządu – nowy produkt. I teraz dostawca mi mówi, że ekran wyboru produktu musi zostać w całości przepisany, ponieważ nie został wcześniej przygotowany do możliwości ponownego użycia.
• Rozmowy o CRze z nowym produktem są jakąś męką. Nie dość, że ja muszę poświęcać na to czas, ściągać użytkowników biznesowych, to dostawca wystawia do nich najbardziej doświadczone osoby, odciągając je od ratowania opóźniającego się projektu.
• Dostałem wycenę CRa. Muszę o tym poważnie porozmawiać. Jak przeliczę koszt na czas porównywalnych zdań, to dniówka pracy w tym CRze kosztuje mnie prawie dwa razy tyle, co w projekcie.
• Jestem po poważnej rozmowie z dostawcą. Od dłuższego czasu dokładają do projektu. Nie przewidzieli takiej złożoności naszych wymagań, szukają oszczędności i dewelopują najprościej, jak się da. Właściwie jak nie wezmę tego CRa na ich warunkach, to chcą wypowiedzieć umowę. To nie tak miało być…

Szczegóły: Testujemy tylko całe procesy biznesowe, czyli użytkownicy końcowi testują całe procesy biznesowe, przez co historyjki czekają na feedback 3-4 sprinty.

Skutek: niespodziewane rozbieżności w rozumieniu wymagań odkrywane po wielu tygodniach od developmentu, znaczący nieplanowany rework, opóźnienie uruchomienia pierwszego etapu o 2 miesiące oraz wzrost kosztu o 100%.

Symptomy: Przejrzyj log managera po stronie biznesu i sprawdź, które symptomy dotyczą Twojego projektu:

• Startujemy w końcu projekt, który unowocześni systemy wspierające nasze kluczowe procesy.
• Wybraliśmy dostawcę, który będzie pracował z nami zwinnie. Nie mamy dużego doświadczenia w projektach Agile, ale IT obiecało wsparcie w tym zakresie. Istotną zaletą jest to, że będziemy pracować nad wymaganiami już w trakcie projektu.
• Ruszamy z pierwszym sprintem. Codziennie uczestniczymy w warsztatach, wypracowując wymagania odnośnie pierwszego procesu. Dzięki makietom widzimy, jak elementy procesu będą wyglądały w tworzonym narzędziu.
• Z niecierpliwością czekamy na testy.
• Pracujemy dalej nad pozostałymi elementami. Kończymy wymagania do pierwszego procesu, zaczynamy opisywać kolejny proces. Czekamy na testy.
• Zbliżamy się do końca opracowywania wymagań do drugiego procesu, cały czas z niecierpliwością czekamy na testy pierwszego.
• Zaczynamy testy! Niestety nie jest to łatwy start – mamy wrażenie braku zrozumienia w wielu miejscach, z drugiej strony minęło sporo czasu i nie mamy pewności, czy o tym wszystkim rozmawialiśmy.
• Kontynuujemy pracę nad wymaganiami, bierzemy na warsztat kolejny proces, jednocześnie testujemy, zgłaszając sporo problemów.
• Wstrzymujemy pracę nad nowymi wymaganiami, koncentrujemy się wyłącznie na testach i poprawkach błędów. Niestety projekt nabiera opóźnienia.
• Cały czas testujemy i wyjaśniamy.
• Kolejny sprint poprawiania błędów. Następne procesy czekają. Opóźnienie wzrasta.
• Rozpoczynamy testy Family & Friends. Dostajemy kolejne błędy.

Szczegóły: Product Owner awansuje i zastępuje go proxy Product Owner, wszystko wydaje się funkcjonować jak dotychczas, ale stopniowo biznes zostaje oddzielony od zespołu scrumowego rozrastającą się warstwą dokumentacji wymagań.

Skutek: projekt stał się iteracyjnym waterfallem, przekroczenia budżetu 20-30%, przekroczenia harmonogramu o 200%.

Szczegóły: Jesteśmy agile, więc nie potrzebujemy szczegółowej dokumentacji, ale ponieważ biznes nie jest częścią zespołu scrumowego, to występuje etap UAT bazujący na doświadczeniu i pamięci biznesu.

Skutek: fala błędów, opóźnienie na poziomie 2 miesięcy, frustracja użytkowników biznesowych i zespołu developerskiego.

Szczegóły: Wdrożenie paczek realizuje zewnętrzny zespół adminów, przez co wydawanie wersji na środowisko testowe zajmuje 2 dni (budowanie paczek, przekazywanie do administratorów, oczekiwanie na instalację).

Skutek: brak przeglądu prac w trakcie/na zakończenie sprintu, zgłoszenia błędów wpadające w czasie trwającego następnego sprintu powodujące niedowiezienie zakresu sprintu obiecanego na planningu.

Szczegóły: Brak budżetu na realizację zadań zmniejszających dług technologiczny przez ponad rok w systemie rozwijanym już od 3 lat, w którym kilka większych zmian zrealizowano, zaciągając dług technologiczny w wysokości kilku pełnych sprintów.

Skutek: zmiana, która funkcjonalnie wymagała 2 sprintów, z powodu konieczności spłaty części długu technologicznego zajęła 4 sprinty.

Szczegóły: Pułapka dużego zespołu i dużych zadań polegała na tym, że duży 30-osobowy zespół pozwalał biznesowi operować na bardzo dużych zadaniach – zespół często brał 1 zadanie na sprint, co zespołowi sugerowało, że nie powinien dzielić się na mniejsze.

Skutek:  wysokie koszty spotkań (daily, planning, retrospektywa) dochodzące do 20-30% kosztu sprintu, z małą korzyścią dla zespołu z powodu rozległości systemu.

Szczegóły: Ekspansywna rozbudowa 10-osobowego zespołu, który otrzymał dwukrotnie większy strumień prac i postanowił urosnąć dwukrotnie w ciągu jednego sprintu. 

Skutek:  nawet po 4 sprintach nie było efektu przyśpieszenia, nastąpiło ono dopiero po kilku miesiącach.

Szczegóły: Product Owner bez umocowań w organizacji, który mimo swojej wiedzy biznesowej musi konsultować wszystko z wieloma interesariuszami i nie ma spójnej decyzji na czas. 

Skutek: realizacja przez zespół historyjek zastępczych, a potem jednoczesna realizacja wielu historyjek priorytetowych, postrzeganie przez interesariuszy pracy zespołu jako zbyt powolnej.

Szczegóły: Zespół silosowy ze sztywnymi rolami – analitycy, programiści i testerzy ograniczają się do „swojego” fragmentu procesu wytwórczego. Nie wychodzą poza tradycyjną rolę, czekają na polecenia lub zgłaszają oczekiwania, zamiast udzielać aktywnego wsparcia innym członkom zespołu. 

Skutek: kumulacja realizacji większości zadań w końcówce sprintu, co powodowało przesunięcie  ok. 20-30% z nich na kolejny sprint.