Zaufanie to podstawowy element każdej współpracy, bez znaczenia czy pracujemy z klientem wewnętrznym czy zewnętrznym. Gdy myślę, czym jest dla mnie zaufanie w biznesie, do głowy przychodzą mi takie pojęcia jak partnerstwo, otwartość, przejrzystość, mówienie prawdy czy poczucie bezpieczeństwa.
W tym wpisie podzielę się sprawdzonymi sposobami na to, jak wzmacniać zaufanie, wykorzystując do tego celu to, co “z pudełka” dostarcza nam Scrum.
1. Zrezygnuj ze Sprintu 0
Ciągnące się Sprinty 0 — bo bywa, że jest ich więcej niż jeden — nie pomagają w budowaniu zaufania. Szansa na jego wzmocnienie, poprzez pokazanie czegoś namacalnego na pierwszym Przeglądzie Sprintu, przepada. Naszemu klientowi pozostaje wierzyć, że tydzień lub dwa mało widocznej, zwykle przygotowawczej pracy, miały sens.
Rozumiem, że gdy zaczynamy pracę nad produktem, konieczne są pewne przygotowania. Jeśli jednak zależy mi na wzmacnianiu zaufania, dostarczam na koniec pierwszego Sprintu choćby najmniejszy spełniający Definicję Ukończenia Przyrost produktu.
Jak więc dostarczyć wartość dla klienta już od pierwszego Sprintu? Dobrym punktem startu jest zainteresowanie się podstawami podejścia iteracyjnego, pojęciem pocisków smugowych oraz techniką Story Mappingu.
2. Skróć czas trwania Sprintu
Od zawsze byłem fanem krótkich Sprintów. Korzyść ze skracania czasu ich trwania jest zasadnicza — klient może zobaczyć coś namacalnego już po tygodniu pracy, co wzmocni jego zaufanie do Ciebie. Dodatkowo, zespół ma szansę otrzymać informację zwrotną, bez konieczności czekania na nią dwa lub trzy tygodnie.
Kiedy słyszę od zespołów, że w tydzień nie da się nic dostarczyć, przypomina mi się historia Gmail’a. Pierwsza wersja tej aplikacji powstała w 24 godziny. Dla mnie ten przykład to esencja zwinności: dostarcz coś wartościowego tak szybko jak potrafisz, zbierz informację zwrotną i na jej podstawie przygotuj kolejną wersję produktu.
Krótki czas Sprintu wymaga dzielenia pracy na małe kawałki – jeśli nie wiesz jak to zrobić, poczytaj mój wpis na ten temat.
3. Nie czekaj na Przegląd Sprintu
Gdy myślę o Przeglądzie Sprintu, do głowy przychodzi mi kilka poziomów dojrzałości Zespołów Deweloperskich, jeśli chodzi o realizowanie tego wydarzenia.
Poziom 0 – brak Przeglądu Sprintu. Klient nie ma możliwości na bieżąco oceniać postępu prac. Na bazie moich doświadczeń, może to prowadzić to pogłębiającego się braku zaufania, co może skutkować frustracją oraz pokusą mikro-zarządzania ze strony klienta.
Poziom 1 – zamiast Przeglądu Sprintu, realizowana jest tylko sesja demo, podczas której Zespół Deweloperski pokazuje efekty pracy. Lepsze to niż nic, natomiast szansa na pogłębioną dyskusję produktową oraz omówienie kolejnych kroków, przepada.
Poziom 2 – realizowany jest cykliczny Przegląd Sprintu. Dla klienta jest to okazja, aby regularnie dokonywać inspekcji oraz adaptacji produktu. Powtarzalność i przewidywalność tego wydarzenia jest czynnikiem wpływającą na zwiększenie zaufania, ponieważ klient wie, że przykładowo, co piątek o 12:00, zobaczy kolejną wersję swojego produktu.
Poziom 3 – pokazywanie efektów pracy wcześniej niż na Przeglądzie Sprintu. Dla osób pracujących Kanbanem oddawanie pracy zaraz po jej ukończeniu nie jest niczym nowym, jednak w Scrumie utarło się, że trzeba z tym czekać do końca Sprintu — co nie jest prawdą.
Pokazywanie skończonych elementów Backlogu Produktu tak szybko jak to możliwe ma wiele zalet: wcześnie wykrywa potencjalne nieporozumienia, przyspiesza proces uczenia się Zespołu i upewnia klienta, że zespół jest skupiony na szybkim dostarczaniu wartości.
4. Dostarczaj kompletne funkcjonalności
Pracowałem kiedyś jako Scrum Master z zespołem odpowiedzialnym za całkowitą zmianę interfejsu pewnej aplikacji oraz dodanie nowych funkcjonalności. Zadecydowaliśmy, że w pierwszej kolejności dostarczymy zmieniony interfejs aplikacji, natomiast zamiast faktycznych danych powpisujemy lorem ipsum. Na pierwszym Przeglądzie Sprintu faktycznie dostarczyliśmy odmieniony interfejs użytkownika dla strony głównej aplikacji, informując klienta, że to tylko “wydmuszka”, i że prawdziwe dane podłączymy później.
Dalej było już tylko gorzej. Na kolejnym Przeglądzie Sprintu nie byliśmy wstanie pokazać niczego nowego, ponieważ nie mogliśmy sobie poradzić ani z cache’owaniem danych, ani z zależnościami z innymi zespołami. Klient przyjął tą informację z zaskoczeniem, chociaż jeszcze ze zrozumieniem.
Kolejny Przegląd Sprintu był podobny. Tym razem mieliśmy kłopoty aktualizacją struktury tabel w bazie danych, aby móc przetrzymywać tam dane, które potrzebne nam były, aby zasilić nowy interfejs użytkownika. Nie mieliśmy szans pokazać niczego nowego. Drugi raz z rzędu. Nie pomagało to nam w budowaniu zaufania z klientem, który stawał się coraz bardziej niecierpliwy.
Co bym zrobił inaczej, gdybym mógł cofnąć czas? Próbowałbym dostarczyć kompletne funkcjonalności w trakcie jednego Sprintu. Oczywiście głębia odwzorowania rozwiązania byłaby niska, ale dzięki świadomemu przejściu po wszystkich warstwach aplikacji (interfejs, warstwa cache’owania, baza danych, logika biznesowa) bylibyśmy w stanie zidentyfikować problemy na bardzo wczesnym etapie.
Co by nam to dało? Po pierwsze, zaczęlibyśmy rozwiązywać wspomniane problemy po pierwszym, a nie po trzecim Sprincie. Myślę, że taki okres czasu robi różnicę. Po drugie, uniknęlibyśmy smutnej niespodzianki dla klienta na zasadzie “znowu nic nie możemy pokazać”.
Technika, która jest pomocna w tego rodzaju przypadkach to przykładowo walking skeleton autorstwa Alistair’a Cockburn’a.
5. Utrzymuj wysoką przejrzystość prac
Doświadczony pracą w zwinnych środowiskach uważam, że wysoka przejrzystość prac jest kluczowa, aby budować zaufanie. Zupełnie innego zdania był pewien zespół , z którym miałem okazję pracować. Wyznawali oni zasadę, że im mniej klient wie, tym lepiej, “bo wtedy nie wnika”.
Oczywiście klient miał inne zdanie na temat transparentności współpracy. Brakowało mu przejrzystości, przewidywalności oraz wglądu w postęp prac. Nie był też świadomy blokerów do rozwiązania po jego stronie, które umożliwiły by nam płynną pracę. Sprawy nie ułatwiał fakt, że my pracowaliśmy w Polsce, a nasz klient w Londynie. Mogę sobie wyobrazić, że taki stan rzeczy nie pomaga zbudować zaufania.
Aby usprawnić tę sytuację, zdecydowaliśmy się na kilka konkretnych kroków, mających na celu zwiększenie przejrzystości prac.
Po pierwsze, ze względu na dzielącą nas odległość, zdecydowaliśmy się na usprawnienie sposobu, w jaki korzystaliśmy z tablicy z zadaniami w JIRA, która pokazywała bieżący status prac. Osoba pracująca nad konkretnym zadaniem, przypisywała się do tego zadania, więc było jasne, z kim rozmawiać w razie pytań. Jeżeli zadanie było zależne od wiedzy lub decyzji klienta, oznaczaliśmy je czerwoną flagą, więc od razu rzucało się w oczy, gdzie leżą zależności. Dodatkowo, dla każdego zadania wprowadziliśmy trójkolorowy status (RAG – Red, Amber Green), który informował o stopniu ryzyka powiązanego z zadaniem.
Dodatkowo zdecydowaliśmy wspólnie z klientem, że po naszym Codziennym Scrumie, będziemy się zdzwaniać przez Hangout na kilka-kilkanaście minut, aby omówić bieżące zadania i ewentualne zagrożenia z nimi związane.
Ostatnim usprawnieniem było dodanie na stałe sekcji “Ryzyka i wyzwania” do agendy Przeglądów Sprintu. Był to blok, podczas którego omawialiśmy wszystko, co mogło mieć negatywny wpływ na przebieg współpracy — od zagrożeń technicznych, poprzez braki w zrozumieniu produktu, na ryzykach typowo ludzkich kończąc.
Wiem, że wymienione wyżej pomysły mogą być dla niektórych osób oczywiste, jednak nie były one oczywiste dla tego konkretnego zespołu :)
Podsumowanie
Jak radzicie sobie z zaufaniem? Jak wykorzystać framework Scrum, aby lepiej budować zaufanie z klientem? Co jeszcze można zrobić, aby wzmocnić zaufanie?
Podyskutujmy w komentarzach :)
Chcesz dowiedzieć się więcej o tym, jak budować zaufanie z klientem zewnętrznym w Scrumie? Zobacz moje 2-dniowe warsztaty “Scrum dla software houseów”, które przygotowałem na bazie moich doświadczeń w pracy z klientami z USA, UK, Irlandii, Niemiec oraz Polski. Więcej informacji znajdziesz na stronie http://www.scrumdlasoftwarehouseow.pl/
Photo by Thomas Drouault on Unsplash
