Każda metoda czy filozofia może zostać użyta także w niewłaściwy sposób. Podejście zwinne powinno oczywiście opierać się na zaufaniu, ale warto znać sztuczki dostawców i działów IT, po to, by lepiej zrozumieć i zabezpieczyć nasz projekt. Niestety opisane w tym artykule sytuacje zdarzyły się naprawdę, natomiast nie prowadziłem badań, aby określić, w jakim stopniu były to jednostkowe przypadki. Przykłady mogą jednak stanowić listę kontrolną dla osób, które chcą mieć większe zrozumienie we współpracy z zespołami zwinnymi.
Popatrzmy na sztuczki w Agile.
Priorytet w backlogu
Znamy sytuacje, które są problematyczne dla wielu kierowników projektów, kiedy to działy biznesowe walczą o jak najwyższy priorytet zleconych wymagań. A co w sytuacji, kiedy to dostawca zawyża priorytet zgłoszeń klienta? Taka sytuacja miała miejsce w czasie jednego projektu, który realizowałem. Podczas spotkań na poziomie klient-dostawca, to właśnie ten drugi podnosił priorytety w backlogu. Kiedy klient mówił, że wymaganie jest na poziomie priorytetu C (Could w priorytetyzacji MoSCoW), to dostawca sugerował, że na pewno to wymaganie wiąże się z innymi, dlatego jego znaczenie powinno być wyższe.
Skąd takie zachowanie? Okazało się, że dostawca ma płacone za zamówione iteracje, a jednym z głównych czynników powodujących dalsze zamówienia była liczba kluczowych wymagań czekających do realizacji. Podbijając priorytety, dostawca zapewniał sobie, że w rejestrze wymagań ciągle czekały ważne funkcjonalności do realizacji.
Lista zadań technicznych
W każdym sprincie/iteracji wykonywane są zadania techniczne, na przykład przebudowa elementu konfiguracji systemu, w celu możliwości realizacji nowego wymagania, czy sprawdzenie możliwości wykonania integracji dwóch modułów. Zdarza się, że nowe wymagania powodują konieczność przebudowy już przygotowanych funkcjonalności. W takiej sytuacji najczęściej złożoność wdrażanego elementu jest większa albo pokazywane to jest jako osobne zadanie do wykonania. W jednym z projektów analiza liczby takich zadań technicznych w kilku ostatnich sprintach pokazała, że procent wykonywania takich zadań był znacząco większy niż w podobnych projektach.
Oczywiście nie możemy nigdy porównać 1:1 takich projektów, ale sytuacja w ocenie kilku osób (również z wewnętrznego IT) była jednoznaczna – dostawca zawyża ilość zadań technicznych w backlogu. Zidentyfikowany powód takiego działania to oczywiście realizacja mniejszej liczby funkcjonalności (zakresu) w jednym sprincie i tym samym klient będzie musiał zapłacić za więcej iteracji, aby zrealizować cały zakres.
Skala zespołu scrumowego
A co w sytuacji, kiedy jeden dostawca przedstawia nam skład osobowy w postaci 7 osób, a drugi dostawca potrzebuje do tego samego projektu na stałe tylko 3 członków zespołu? Czy pierwszy ma wyższe standardy jakości? Czy rzeczywiście przy tym wdrożeniu potrzebujemy na stałe 2 testerów do zespołu scrumowego? Czy może różnica wynika z kompetencji i efektywności pracy różnych zespołów? A może jeden dostawca zawyża skład, a drugi nie do końca umie planować? Najlepiej byłoby obu dostawcom dać kawałek prac i porównać efekty. Czy taka próba realizowana tylko po to, aby wygrać kontrakt będzie reprezentatywna do prognozowania przyszłych losów projektu?
Jako ciekawostkę powiem, że po kilku sprintach klient ocenił, że do tego projektu potrzebuje 4 osoby od dostawcy. Czy w przypadku dostawcy numer jeden, który przedstawił konieczność zaangażowania 7 osób, nastąpiłoby zmniejszenie do 4 po kilku iteracjach? Śmiem wątpić. Poza zaufaniem są przecież jeszcze plany sprzedażowe do wykonania…
Zawyżona złożoność tematu
W jednym projekcie zewnętrzny zespół projektowy zaczął zawyżać złożoność zgłaszanych funkcjonalności. Dzięki takiemu podejściu zespół mógł oszukiwać, że realizuje więcej zakresu projektu i tym samym, że poprawia wydajność pracy (lepsze velocity). Zawyżanie złożoności pomagało również brać mniej wymagań z backlogu do sprintu. Tym samym dostawca poprawiał sobie bezpieczeństwo dostarczania całości sprintu (skoro miał w praktyce mniejszy zakres do realizacji). Niestety często tam, gdzie są wskaźniki do dowiezienia, tam zaczynają się manipulacje…
Rework – poprawki w projekcie
O ile łatwiej jest nam przypilnować zespół w zakresie wyceny złożoności pewnych funkcjonalności (z racji tego, że porównujemy to z innymi funkcjonalnościami referencyjnymi), o tyle ciężej nam zweryfikować, czy szacowanie wpływu nowego wymagania na dotychczas zrealizowany zakres jest poprawne. Mówiąc inaczej: rework, który należy wykonać, jest trudniejszy do zweryfikowania i pozwala na dowolne zawyżenie kosztów. Na szczęście w praktyce nie spotkałem się z takim działaniem w celu większego zarobku na projekcie. Natomiast kilka razy miałem sytuację, że zespół zawyżał pracochłonność wprowadzenia zmiany w celu… nie wprowadzenia nowego wymagania od klienta.
Zmiany oczekiwań (zwykle wynikające z krzywej uczenia) powodują dużą niechęć zespołu do ponownego przerobienia zakresu danego produktu. Bo kto z nas lubi kolejny raz poprawiać wykonaną już dobrze pracę tylko dlatego, aby ktoś w końcu zrozumiał, czego potrzebuje?
Ukryte koszty na później
Agile stał się wspaniałym elementem sprzedaży rozwiązań do klienta. Wcześniej mieliśmy wielomiesięczne ustalania zakresu do przetargu, przeprowadzanie postępowania, aby móc realizować projekt dla klienta. Oczywiście cały czas poświęcony na tę fazę pozwalał zwymiarować koszty i podjąć świadomą decyzję po stronie klienta/zamawiającego.
Co się dzieje w świecie zwinnym? Dostawca lub wewnętrzne IT proponują nam zainwestowanie czasu w kilka sprintów, w celu wspólnego przygotowania prototypu, zweryfikowania możliwości wykonania projektu czy doprecyzowania oczekiwań. W efekcie widzimy namacalny kawałek rozwiązania i tym samym… trochę automatycznie zapada decyzja o realizacji projektu lub przynajmniej kolejnych sprintów. I do tego momentu nie ma problemu – obie strony korzystają z takiego podejścia.
Problemy zaczynają się później, kiedy okazuje się, że kolejne rozbudowy wymagają już innej architektury rozwiązania, struktur danych, czy wręcz zmiany technologii. Koszty z tym związane okazują się tak duże, że gdybyśmy mieli ich świadomość od początku, w ogóle nie rozpoczęlibyśmy tego projektu. Trochę jak z grami komputerowymi, zagraj za darmo, a później orientujesz się, że aby móc konkurować z innymi na tym samym poziomie, musisz sporo zapłacić za dodatki.
Taką sytuację widziałem w audytowanym projekcie. Okazało się, że dostawca dopiero na zakończenie projektu wycenił ogromną pracochłonność przygotowania dokumentacji użytkownika i administratora. I tu ciekawostka, okazało się, że nie chodziło o „zarobienie” na kliencie na koniec projektu, ale po prostu dostawca nie miał kompetencji i efektywnych metod pracy do tego obszaru, stąd wycena była tak duża. Problem udało się rozwiązać, ale zaskoczenie było ogromne.
Podsumowanie
Wymienione powyżej sytuacje służyły do uzyskania korzyści przez jedną ze stron i oczywiście nie powinny nigdy mieć miejsca. Zakładam, że były one jednorazową sytuacją i nie są standardem rynkowym. Moim zdaniem aktualnie najczęściej oszukujemy w poniższych sytuacjach:
- Malowany agile: brak zrozumienia filozofii i wartości zwinnego podejścia oraz bezmyślne stosowanie zasad Scrum powoduje, że zespół nie umie na bieżąco reagować na trudniejsze sytuacje projektowe. Na przykład – członek zespołu projektowego nie umie podjąć decyzji o tym, czy może poświęcić 2 dni na naprawę błędu w funkcjonalności, którą właśnie przygotował. Nie umiał zdecydować, czy w takiej sytuacji wymaganie powinno wrócić do backlogu i ponownie podlegać decyzji projektowej, czy można poświęcić dodatkową pracochłonność jeszcze w tym sprincie.
- Ukrywany agile: drugie oszustwo jest realizowane przez kierowników projektów, którzy ukrywają zwinny zespół przed sponsorem, komitetem sterującym projektu czy organizacją. Brak świadomości wartości z zastosowania agile lub złe doświadczenia organizacji w tym zakresie powodują, że „Zarząd nie chce słyszeć o zwinnym podejściu”. Ponieważ w wielu miejscach zespoły chcą pracować tym trybem, dochodzi do sytuacji, że wewnątrz projektu część zespołu pracuje zwinnie, ale kierownik dla spokoju wszystkich woli o tym fakcie nie informować…
Może warto w naszym projekcie wykorzystać powyższą listę i sprawdzić, czy agile nie stał się idealnym narzędziem dla dostawcy, czy wewnętrznego zespołu do zapewnienia spokoju pracy, a nie zagwarantowania efektywności realizacji projektu? Czasami poproszenie o ponowną wycenę jakiegoś elementu, może pokazać ciekawe dane.
Pamiętajmy proszę: powyższa lista przypadków nie powinna stanowić elementu zwiększenia kontroli nad zespołem czy dostawcą, bo w dalszym ciągu naszym głównym celem jest zbudowanie relacji, odpowiedzialności i zaufania w całym zespole.
Ekspert w zakresie zarządzania projektami, portfelem projektów i PMO. Specjalizuje się w obszarze usprawnień organizacji poprzez wdrożenie zarządzania portfelem projektów i PMO oraz w obszarze rozwoju kierowników projektów. Od 2003 roku związany z PMI®, gdzie pełnił m.in. funkcję Prezesa Oddziału Polskiego. Z centralą PMI® w USA związany od 2010 roku – obecnie pracuje w Komitecie do Spraw Certyfikacji (CGC). Od 2010 roku prezes firmy WHITECOM Project Experience specjalizującej się w szkoleniach, ustawianiu PMO oraz zarządzaniu projektami i portfelem projektów. Współautor książki PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji.