Webinaria: Zarzadzanie projektami | Zwinne zarzadzanie | Agile

Dlaczego klienci nie pracują w AGILE, nawet jak mówią, że pracują?

Udostępnij!

Metodyki zwinne są dziś w fazie ogromnego rozwoju. W mojej ocenie szczególnie w Polsce jest dziś po prostu modnie zarządzać zwinnie. Wiele firm na poziomie deklaracji mówi, że chce zarządzać zgodnie z Agile, jednak jak przychodzi co do czego to okazuje się nie są do końca skłonni dopełnić podstawowych założeń jakie wiążą się z metodyką Agile. W tym video dowiesz się co powoduje, że klienci nie zawsze chcą podjąć się pracy w metodyce Agile.

 

TRANSKRYPCJA

 

Cześć, witajcie. Nazywam się Justyna Broniecka, jestem jednym z trenerów Altkom Akademii. Zajmuję się prowadzeniem szkoleń z metodyk zwinnych i tradycyjnych i dzisiaj chcę opowiedzieć Wam dlaczego klienci nie pracują w Agile, chociaż mówią, że pracują. Przejdźmy do tego, że dzisiaj klienci bardzo łatwo ulegają modzie. Często można przeczytać, że wszystko da się zrobić w Agile, że Agile jest taki fajny, że elastyczny, że modny, że szybko dostarcza. Przyjrzyjmy się jak jest naprawdę.

Jak to naprawdę jest z tym Agile?

Porywająca elastyczność – to jest pierwsze o czym chcę Wam powiedzieć. Prawda jest taka, że ta elastyczność to jest elastyczność w stosunku do potrzeb biznesowych, natomiast sam Agile ma bardzo jasną strukturę, ma bardzo jasny zespół procedur, których trzeba przestrzegać więc to nie jest tak, że możemy sobie w tym projekcie robić absolutnie wszystko bo wtedy nie mówilibyśmy w ogóle o projekcie. Agile mówi o tym, że szybko i często dostarcza. Rzeczywiście tak jest, natomiast trzeba mieć po stronie klienta i dostawcy niezwykle responsywnych ludzi, którzy chcą ze sobą współpracować, którzy są zaangażowani. I prawda jest taka, że po stronie klienta bardzo często istnieje opór. Projekt i komunikacja z dostawcą nie są dla nas priorytetem i później dostawca nie dostarcza tego co my chcemy. Kolejna rzecz – oczekujemy od dostawcy gwarancji. Najczęściej mówię tu o gwarancji zakresu, czyli ostatecznego wyglądu produktu. Jest to sprzeczne z założeniami metodyki, dlatego, że w metodyce Agile mówimy o tym, że najpierw przychodzi do nas klient, mówi o swojej potrzebie biznesowej i my warstwami odkrywamy jego potrzeby związane z produktem. Komunikacja to kolejny problem na linii klient – dostawca, szczególnie w środowisku B2B. Klienci bardzo rzadko chcą się w poprawny sposób angażować, to co z mojej strony jest też bardzo ważne, to, że nam się wydaje, że w Agile mamy luźne podejście, miłą atmosferę. Oczywiście jesteśmy nastawieni na współpracę, na otwartość, na transparentność, natomiast to czy jest luźna i miła atmosfera, zależy raczej od kultury organizacyjnej niż od samej metodyki.

„Expectations vs Reality”.

No i teraz zobaczmy jak wygląda rzeczywistość. Ta elastyczność zakresu powoduje, że musimy mieć sztywność czasu i kosztu i na to bardzo często klienci nie chcą się zgodzić, wolą móc negocjować czas i koszt, a nie rezygnować z zakresu. Druga sprawa to wycena za  roboczogodziny. Tutaj jest największy opór ze strony klienta, dlatego, że większość z nich chce stałej ceny, tak zwaną fixed price. Chce stałą cenę za rozwiązanie, natomiast środowisko Agile zakłada, że klient dostaje w blokach czasowych konkretny zespół do dyspozycji i ten zespół mu coś wyprodukuje. I teraz on będzie płacił za roboczogodziny tego zespołu. Kolejna sprawa to zaangażowanie biznesu, o tym już wspominałam, że bardzo rzadko klient angażuje się w realizację projektu na takim poziomie żeby dostawca mógł rzeczywiście korzystać z metodyki Agile i dostarczać mu to czego chce. No i czego chcą klienci? Klienci dzisiaj chcą elastyczności w ramach stałej ceny, co w ogóle się ze sobą kłóci. Nie da się być z jednej strony elastycznym, a z drugiej proponować stałą cenę. Cały czas w ramach time boxów czy sprintów chcą dorzucać wymagania, nie rozumieją, że sprint nie jest z gumy i że tam nie ma jakichś magicznych, dodatkowych rąk do pracy, ale, jeżeli dokładamy zakres,  to musimy wyjąć jakieś założenia po to żeby nadal ilość czasu się zgadzała. Klienci oczekują bezbłędności w szacowaniu. To nie jest możliwe – jeżeli szacujemy technologię, jeżeli szacujemy coś co robimy po raz pierwszy, to niestety trzeba wziąć pod uwagę to, że będzie tam pewien procent błędu. Oczywiście ten procent błędu będzie dotyczył doświadczenia, będzie dotyczył technologii, będzie mówił o tym w jaki sposób ze sobą pracują ludzie. Natomiast faktem jest, że nie jesteśmy w stanie oszacowywać zadań w punkt.

Stare przyzwyczajenia a Agile.

Kolejna rzecz to kontrola dyrektywna. Niestety bardzo często klienci i dostawcy są wychowani na metodykach waterfallowych co jest normalne i dzisiaj bardzo ciężko jest im się przestawić z takiej kontroli dyrektywnej, na współpracę, na kooperację, moderację. Oczekujemy kar umownych, czyli jak nasz dostawca się z czegoś nie wywiąże to chcemy żeby zapłacił karę, oczekujemy gwarancji. Prawda jest taka, że projekty Agile nie są w stanie nam tego dostarczyć, dlatego, że założenia tej metodyki są kompletnie inne. No więc pytanie jak jest, jak jest naprawdę. Oczywiście metodyka Agile zakłada, że mamy jasny cel biznesowy, później wiemy, że nie mamy szczegółów odnośnie kwestii technicznych, czyli wiemy na przykład, że klient chce polepszyć sobie efektywność pracy linii produkcyjnej, czyli chce po prostu dostarczać szybciej, ale nie wie w jaki sposób to zrobić. W związku z tym dostawca proponuje mu rozwiązanie, na przykład wprowadzenie robotów na linie produkcyjne, które zwiększą szybkość, prawdopodobnie będzie mniejsza liczba błędów i też spowoduje to, że wyeliminujemy czynnik ludzki. Natomiast przy szacowaniu tego typu zadań musimy wprowadzać duże tolerancje i do tego potrzebny jest nam ktoś po stronie klienta, czyli jest nam potrzebny biznes. To będzie ktoś, np. w przypadku branży produkcyjnej, z utrzymania ruchu, to będzie ktoś wprowadzał nas w świat robotów, będzie mówił jak to wygląda, będzie mówił jakie ma doświadczenia. I z drugiej strony musimy też być elastyczni na zmiany. Biznes ma w każdym momencie prawo wprowadzić zmianę i to jest z założenia agile’owe.

Stare przyzwyczajenia cd. Dlaczego mamy kłopoty z Agile?

Kolejna sprawa to są zmiany w zakresie. Bardzo często dostawca wręcz wścieka się jak klient przychodzi i mówi, że chce coś jeszcze. To jest tak zwane „dorzucanie”. Natomiast jeżeli macie świadomego klienta, który rzeczywiście chce pracować w Agile, to on wymieni Wam rzeczy w zakresie, czyli powie „nie potrzebuję tego robota, ale potrzebuję innego szybciej”. Więc wyjmujemy zadanie A, a wkładamy w to miejsce zadanie B. W metodykach zwinnych koszt i czas jest zamrożony. W związku z tym klient zaspokaja swoją potrzebę biznesową w określonym koszcie i w określonym czasie. No i oczywiście wycena naszej pracy powinna być oparta o roboczogodziny więc pytanie czy klienci są w stanie zaakceptować środowisko Agile tak naprawdę. Bo dzisiaj niewiele firm pracuje w środowisku Agile w takiej wersji 1:1, są jakieś elementy, natomiast Agile operuje na zaufaniu, na tolerancji, na nieszukaniu kozłów ofiarnych, na pozwoleniu sobie na błędy, na dosyć dużą tolerancję, na elastyczność w zakresie i na to wszystko bardzo często klienci biznesowo, mentalnie, nie są gotowi. No więc pytanie jak wyglądają dzisiaj projekty Agile w środowisku B2B. Prawda jest taka, że, niestety, z uwagi na rys historyczny i to, że mieliśmy wojnę, to, że mieliśmy zabory, to, że mieliśmy inny ustrój gospodarczy, jesteśmy nauczeni swego rodzaju kombinatorstwa i cwaniactwa i teraz w związku z tym bardzo rzadko firmy między sobą sobie ufają, bardzo trudno jest właścicielom firm, klientom, zaufać dostawcom i odwrotnie. Cały czas szukamy dziury w całym, obudowujemy się bardzo specyficznymi umowami, wpisujemy kary umowne i później bardzo często wykorzystujemy te formalne zapisy do negocjacji zamiast spróbować się dogadać na miękko. Jest taki domysł po stronie klienta, że jeżeli nasze wymagania mamy spriorytetyzowane za pomocą metodyki MOSCOW, to są tak zwane musty, shouldy i couldy, czyli wymagania, które absolutnie muszą być dostarczone, które powinny być dostarczone i mogą być dostarczone, to po stronie klienta istnieje domysł, że jeżeli on nam płaci za roboczogodziny, to my będziemy na siłę tylko dowozili musty żeby resztę roboczogodzin sobie zabukować na inne projekty. Bardzo często taki zarzut pada po stronie klienta dlatego bardzo trudno jest mówić o zaufaniu i o pracy agile’owej.

 

 

Problemy z priorytetyzacją:

Czasami klienci twierdzą też, że dostawcy specjalnie przeszacowują zadania, czyli jeśli coś trwa dwa dni, to oni mówią, że to zajmie cztery po to żeby sobie robić bufor. Po stronie klienta to wygląda dosyć nieelegancko, po stronie dostawcy, dostawca z uwagi na złe doświadczenia z innymi klientami albo z tym klientem specjalnie sobie dokłada bufory żeby nie mieć jakichś sytuacji podbramkowych. I tutaj znowu jest kwestia zaufania, którego po prostu nie ma. Klienci bardzo rzadko chcą rezygnować z zakresu, czyli te musty, shouldy i couldy na samym początku definiują jako musty i nie chcą schodzić z priorytetu na should albo could. Oznacza to, że w takiej najbardziej skrajnej wersji dostawca ma prawo dostarczyć tylko musty i to jest zgodne z metodyką dlatego, że okaże się, że mamy dużo błędów w szacowaniu, że zadania trwają dłużej niż założyliśmy no i potem klient zostaje tylko z mustami w ramach budżetu i czasu, który założył no i niestety klienci nie chcą rezygnować z zakresu, czyli chcą mieć zakres, czas i koszt sztywne, a wiemy, że tanio, szybko i dobrze nie działa.  No i oczywiście w związku z tym bardzo często mówi się o pływającym budżecie. Prawda jest taka, że zgodnie z metodyką powinniśmy zamrażać budżet, natomiast w świecie rzeczywistym budżety często są ustalane z timeboxa na timebox, z przyrostu na przyrost i tak naprawdę na samym początku nikt nie zastanawia się ile ma pieniędzy na to żeby tę potrzebę zaspokoić. No i teraz pytanie jak można do tego podejść. Przede wszystkim zarówno klient jak i dostawca powinni rozumieć system dostarczania, czyli wiedzieć czym są musty, shouldy i couldy, rozumieć, że priorytetyzacja polega na tym, że możemy dostać tylko musty. Musimy wiedzieć o tym, że jedna i druga strona musi być elastyczna na zmianę więc podejście do zmian jest takie, że zmiana jest czymś oczywistym tylko żeby ją wprowadzać potrzebujemy też zaangażowanego biznesu. Potrzebujemy przedstawiciela biznesu, który będzie naszą osobą do kontaktu, która będzie cały czas zaangażowana w projekt, która będzie dla nas dostępna i umocowana do podejmowania decyzji.

Trzeba się dogadać. A gdyby spotkać się w pół drogi….?

Trzeba założyć, że klient i dostawca grają do tej samej bramki, czyli z jednej strony dostawca chce zaspokoić potrzebę biznesu, a biznes wierzy w to, że dostawca ma najlepsze możliwe intencje. Na samym początku musicie pracować wspólnie przy ustalaniu zasad, zasad współpracy, komunikacji, raportowania, zasad wprowadzania zmian. To wszystko trzeba ustalić na początku dlatego, że jeżeli macie kompletnie skrajne kultury organizacyjne, to będzie bardzo trudno Wam się współpracowało. Trzeba założyć, że wymagania muszą być spriorytetyzowane, czyli każde wymaganie ma status albo must albo could albo should. Te statusy mogą się zmieniać, ale decyduje o tym klient i trzeba przyjąć, że to jest metodyka gdzie priorytetyzacja jest czymś obowiązkowym. No i kolejna sprawa – trzeba wiedzieć ile mam pieniędzy i w jakim czasie potrzebuję zaspokoić swoją potrzebę biznesową po to żeby móc zamrozić czas i koszt. No i może się okazać, że klienci dzisiaj nie są gotowi na aż taką zmianę w podejściu dlatego, że jesteśmy wychowywani na projektach waterfallowych i takie wejście w kompletnie odwrotny świat dla wielu z nas staje się absolutnie niemożliwe. Pytanie więc co by się stało gdybyśmy wzięli najlepsze cechy z metodyk tradycyjnych i z metodyk zwinnych no i w tym momencie powstają tak zwane metody hybrydowe. Pytanie – co gdyby nieco usztywnić Agile i wprowadzić trochę zasad z metodyk tradycyjnych? Ale o tym w kolejnym video dotyczącym podejścia hybrydowego.