4
Kilka tygodni temu, wystartowałem z projektem, który dość mocno podrażnił moje synapsy. Nie tylko moje, zresztą. Trafił mi się klient, który, w zasadzie pracuje tylko z dostawcą zewnętrznym. I to nie jednym. Dosłownie każdy projekt jest w ten sposób zorganizowany. I nie byłoby w tym nic dziwnego, gdyby w całej tej układance, nie pojawił się temat Scruma.
Zanim jednak zaczniemy głębiej wbijać łopatę, poniżej rysunek, na którym zobaczcie jak skonfigurowaliśmy zespoły. To jest dość ważne, z punktu widzenia mojej dalszej refleksji.
W ten sposób, uruchomiliśmy trzy projekty pilotażowe. Każdy z nich, pod względem struktury jest bardzo podobny. Scrum Master i Product Owner działają po stronie Klienta. Zorganizowaniem zespołu developerskiego zajął się dostawca. I tu leżał pies pogrzebany. Czy to sens? Czy zadziała? Nad tą kwestią „namóżdzaliśmy się” najbardziej. I najdłużej.
Dostawca nas zambarasował
„Z tym największy jest ambaras, żeby dwoje chciało naraz” – pisał Tadeusz Boy Żeleński. No właśnie. A co jak dwoje nie chce? Muszę przyznać, że wcześniej, w ogóle, by mi to do głowy nie przyszło, że dostawca zewnętrzny nie będzie chciał pracować w Scrumie. Z tego, co widzę na rynku IT, dostawcy najczęściej rwą się do pracy w tej metodzie. „Tak, tak, my już od trzech lat pracujemy w Scrumie” – chwalą się przy okazji różnego rodzaju rozmów zakupowych. To bardzo dobrze. Wcale nie ironizuję. Tu jednak było zupełnie inaczej. Dostawca gwizdał sobie na Scruma. Sprawiał wrażenie, jakby mu w ogóle na niczym nie zależało. Miałem wrażenie, jakby robił wielką łaskę klientowi tym, że w ogóle z nim pracuje. Cóż za wielkoduszność! Cóż za ABSURD (no raczej).
Jak się okazało, największym problem, z którym nasz dostawca nie mógł sobie poradzić było zaufanie. Nie ufał klientowi. Nie podobało mu się, że musi się „odsłonić”. To był prawdziwy problem, bo w rozwiązaniu, które zaproponowaliśmy wszystko było maksymalnie przejrzyste. ScrumMaster i Product Owner wprawdzie pracowali po stronie klienta, ale byli częścią zespołu scrumowego, w skład którego wchodziła ekipa dostawcy. Takie podejście wymaga zaufania. Bez tego się nie da. Trzeba być szczerym i móc na sobie polegać. Dostawca nie był już traktowany jak czarna skrzynka, o której klient nie ma zielonego pojęcia, co jest w środku.
Jak budować zaufanie w pracy z dostawcą?
O zaufaniu mówimy, że się go zdobywa lub też, że można go stracić. Podobnie jest w przypadku relacji klient-dostawca. Jeżeli kiedykolwiek zdecydujecie się na pracę w metodzie Scrum z udziałem dostawcy (a bardzo zachęcam), skupcie się w pierwszej kolejności nie na narzędziu, bo z tym nie będziecie mieli problemów, ale na zbudowaniu odpowiedniej sytuacji – na klimacie zaufania. Nie podam wam gotowej recepty jak to zrobić. Są jednak trzy działania, które z pewnością wam w tym pomogą.
1. BĄDŹ PRZEJRZYSTY. Stephen Covey, w jednym z wywiadów powiedział, że:
Przejrzystość to mówienie prawdy w sposób, który ludzie sami mogą zweryfikować i poświadczyć. Przejrzystość jest szczególnie istotna, jeżeli zaufanie bardzo spadło, ponieważ ludzie nie ufają temu, czego nie mogą zobaczyć. Zatem pozwól im to zobaczyć.
Jak obserwuję, przejrzystość jest największym problemem przy wdrożeniach Scruma, właśnie po stronie dostawcy. Bo musi się „odsłonić”. Musi przestać ściemniać, że w projekt jest zaangażowanych 10 osób, a w rzeczywistości pracuje tylko pięć (autentyczna historia). Musi umieć przyznać się do błędów i starać się je naprawiać.
2. DOTRZYMUJ OBIETNIC. Jeżeli coś obiecałeś, spełnij to. W swoich zobowiązaniach, bądź realistyczny. Nie tak dawno wspierałem wdrożenie Scruma w niemieckiej firmie w Bawarii. Jednym z dostawców była firma, działająca w Sofii, w Bułgarii. Scrum dla nich był prawdziwym horrorem. Ale, jak się okazało, finalnie, bardzo poprawił poziom ufności z klientem. Zanim jednak do tego doszło, notorycznym problemem było nad-zobowiązania. Ciągle brali za dużo na klatę. Ciągle chcieli coś udowodnić. Że zrobią, że nie ma problemu. To bardzo mocno podcinało ich wiarygodność. Jeżeli rezultaty nie odpowiadają składanym obietnicom, rodzi się rozczarowanie, a potem nieufność.
3. ZAUFAJ. To chyba najtrudniejsze. Ale zapewniam was, że daje naprawdę piorunujący efekt – dla obu stron. To bardzo proste. Jeżeli chcecie, żeby dostawca zaczął wam ufać, zróbcie pierwszy krok – obdarzcie go zaufaniem. Wielu menedżerów liniowych, liderów ufa tylko sobie, a później narzeka, że współpraca z dostawcą oparta na zaufaniu to tylko propagandowe mrzonki. Jeżeli ktoś ma potencjał, a wy mu nie ufacie, nigdy się nie wykaże. Bo nie będzie miał ani cienia szansy, żeby się „odsłonić”. I w drugą stronę. Dostawca powinien zaufać klientowi. Zobaczycie, że korzyści, które daje zaufanie, są dużo większe niż ryzyka.
2 Odpowiedzi na “Scrum, dostawcy i zaufanie”
Krzysztof
Chciałem krótko, ale chyba nie będzie. Na bieżąco prowadzimy kilkanaście projektów z klientami w SCRUM’ie. Na przestrzeni ostatnich dwóch lat udało się nam wypracować dwa schematy konstruowania zespołów SCRUM’owych. Choć podobne do Twojego (przedstawionego na rysunku), to jednak minimalnie różniące się. Właśnie te minimalne różnice mogą stanowić o sukcesie bądź nazwijmy to delikatnie kłopotach.
W pierwszym schemacie, kiedy to klient nie ma wiedzy/doświadczenia praktycznie cały zespół jest po naszej stronie – dostawcy. W tej konfiguracji osobą łączącą klienta i nas jest nasz Product Owner. Tu muszę dodać, że po stronie klienta jest zawsze kierownik projektu. Jest on w ścisłym (codziennym) kontakcie z Product Ownerem. Z doświadczenia powiem, że zwykle z biegiem czasu projektu, kierownik taki nabywa wiedzę, doświadczenie i umiejętności przez co jego rola staje się nadrzędna i to on staje się głównym Product Ownerem. Przyznam, że jest to bardzo dobra sytuacja, która sprawdziła się nam wielokrotnie we współpracy z klientami.
Druga konstelacja, to zespół dzielony, często również rozproszony. To znaczy: w skład zespołu wchodzą członkowie klienta i dostawcy. Product Owner działa w sposób opisany powyżej. Ważną różnicą w stosunku do Twojego schematu jest to, że Scrum Master jest zawsze członkiem zespołu. Tu znowu, na przestrzeni wielu projektów, mając członków z odpowiednio dużym doświadczeniem, udało się nam wypracować sytuację, że rola Scrum Mastera jest przechodnia. To znaczy: na początku pełni ją zawsze członek zespołu dostawcy. W trakcie trwania projektu następują jednak cykliczne zmiany. Oznacz to, że również przedstawiciel Klienta odgrywa taką rolę. Jeżeli zespół dojdzie do wniosku, że jest to sytuacja pożądana, to taki członek zespołu (ze strony klienta) może pełnić taką rolę przez dłuższy czas lub do końca projektu.
Na koniec odniosę się do zaufania, o którym napisałeś powyżej. To bodaj najważniejsza sprawa w AGILE. Nasze doświadczenie pokazało, że trzeba na nie mocno zapracować. Jest ono jednak konieczne. Bez niego nie będzie możliwości lub będzie bardzo trudno realizować kolejne iteracje w projekcie.
Jeżeli chodzi o otwartość i przejrzystość, to jeszcze jakiś czas temu nie udostępnialiśmy klientom żadnych danych dotyczących naszej „produkcji”. Bardzo szybko okazało się, że prowadząc projekty w SCRUM’ie, gdzie jest zespół składający się z członków klienta i dostawcy nie da się nic ukryć. Mało tego okazało się, że nie ma sensu tego robić.
W kilku ostatnich projektach udostępnialiśmy, ba nawet wspólnie raportowane były „wypalane godziny”, ilości Story Pointów, obłożenie członków zespołu itp. Robiliśmy to razem, rozmawialiśmy na retrospekcjach gdzie są problemy, co trzeba zrobić aby cały proces usprawnić. Taka otwartość, ma moim zdaniem, więcej plusów niż minusów we współpracy z Klientem. Musi on przy tym zaakceptować odpowiednie stawki realizacji projektu oraz co tu dużo owijać w bawełnę – orientacyjną marżę jaką na projekcie uzyska dostawca. Jest to jednak możliwe, czego przykładem są nasze projekty. Dzięki nim dostarczamy wartość która jest o wiele większa niż poniesione przez klienta koszty. Przy tym wszystkim obie strony mają olbrzymią satysfakcję z niesamowitej współpracy oraz niezłej… zabawy.
Pozdrawiam
Krzysztof Wiśniewski
CEO w CONTMAN.pl
Mariusz Chrapko
Wygląda to bardzo fajnie. W tym drugim przypadku, podoba mi się to, co napisałeś: „Jeżeli zespół dojdzie do wniosku, że jest to sytuacja pożądana, to taki członek zespołu (ze strony klienta) może pełnić taką rolę przez dłuższy czas lub do końca projektu”. To bardzo dojrzałe jest. Każdy „nieprzekonany dostawca” powinien przeczytać to, co napisałeś o zaufaniu. Jest taka scena w filmie Indiana Jones i ostatnia krucjata, w której dr Jones stoi cały mokry od potu nad skrajem głębokiej przepaści. Żeby ocalić życie swojego ojca, który wcześniej został postrzelony przez jednego ze zbirów, musi przeskoczyć na drugą stronę, i odnaleźć Świętego Graala. Misja niemożliwa. Kiedy jednak pospiesznie szuka wskazówek w notatniku znajduje takie oto słowa: „Jedynie skokiem z głowy lwa dowiedziesz swojej wartości”. Wtedy Jones skacze. Prosto w przepaść. W tym momencie, pod jego stopami pojawia się kamienny most. Jones przechodzi na drugą stronę. Dalej już ma z górki. I bardzo podobnie jest, jeśli chodzi o pracę w Scrumie z dostawcą. Budowanie zaufania jest najtrudniejsze. Bo wymaga niemożliwego skoku.