Z kim my pracujemy?! - #białko czyli Scrum i Agile

Tak naprawdę chciałem zapytać „Z kim Wy pracujecie?!”, ale nikt nie jest wolny od pewnych ułomności naszego umysłu. A więc, z kim my pracujemy? I czy rzeczywiście nasze obawy i projekcje mają podstawy?

Zakładanie złej woli

Dzisiejszy tekst jak zwykle nie wziął się znikąd. Czasami rozmawiając o podwalinach zwinności, spotykamy się z pustymi spojrzeniami i niedowierzaniem. Szczególnie gdy wspominamy o zaufaniu, transparentności, prawdomówności, samoorganizacji i wierze w członków zespołu. A to akurat dużo bardzo istotnych słów.

Zawsze powtarzamy, że niektóre rzeczy są ściśle od siebie zależne. Jeżeli ufamy ludziom i utworzymy im właściwe środowisko oraz nałożymy odpowiednie ramy, to rozwinie się samoorganizacja. A jeżeli do tego te osoby są profesjonalistami przez wielkie P, a w organizacji mamy agile mindset na każdym kroku, to efekty mogą być godne pozazdroszczenia.

A co jeżeli nie są profesjonalistami? No i tu wracamy do tytułowego pytania. To z kim my tak naprawdę pracujemy, że nie potrafimy im zaufać, że spodziewamy się najgorszego i potrzebujemy na wszystko potwierdzenia na piśmie, a kontrola jest u nas najwyższą formą… i tak dalej. Czy to naprawdę są nasi współpracownicy, których widujemy codziennie?

Podobne rozumowanie przeprowadzałem już przy okazji walki z „dupokrytami„. Problem niestety wraca i to za każdym razem w innej formie. A to znaczy, że poszczególne jego aspekty – zapisywanie wszystkiego na papierze, odbiory User Stories, wysyłanie notatek ze Sprint Retrospective do zarządu – to tylko przejawy większego i znacznie poważniejszego problemu.

Tym problemem jest brak zaufania.

Zaufanie, a warsztat samochodowy

Na szkoleniach i warsztatach często używam analogii z życia codziennego. Niektórzy mogą też powiedzieć, że nadużywam tych motoryzacyjnych. Ale co ja zrobię, że świetnie mi się dzięki nim tłumaczy Definition of Done, kryteria akceptacji wymagań i… zaufanie właśnie. W szczególności, zaufanie do Zespołów Deweloperskich związane z „odbiorem prac”.

Wyobraźmy sobie następującą sytuację – odstawiamy samochód na przegląd, na którym wiemy, że będzie wymieniany olej, filtr oleju, świece, regulowany rozrząd i zawory. Dodatkowo mamy mieć wymienione dysze od spryskiwaczy, bo akurat przestały działać. Zadziać się ma więc wiele różnych rzeczy – prostszych i trudniejszych. Teraz ręka do góry, kto po odebraniu samochodu z warsztatu sprawdzałby po kolei te wszystkie rzeczy?

Pewnie każdy sprawdzi te nieszczęsne spryskiwacze. Jeszcze uwierzę, że ktoś zweryfikuje poziom i kolor oleju, lub ewentualnie zrobi to w domu. Ale reszta? A skąd! Czemu więc jesteśmy w stanie zaufać mechanikom, którzy serwisują coś, co ma wpływ na nasze życie, a zupełnie inaczej traktujemy ludzi z którymi pracujemy na co dzień?

Ktoś może powiedzieć, że w pracy nie mamy do czynienia z zadaniami do wykonania, ale z wymaganiami. Chcemy się upewnić, że zostały dobrze zrealizowane. Tylko to jest właśnie cała istota zwinności. Zdefiniujmy wymagania tak, żeby nie być rozczarowanymi, ale „weryfikację” przeprowadźmy z interesariuszami (np. na Sprint Review) bądź z klientami (po wdrożeniu).

Tylko co wtedy, jak się okaże, że nasze oczekiwania rozmijają się z produktem? To jest właśnie moment, w którym powinniśmy się zastanowić, z czego to się wzięło i postarać się zadziałać tak, żeby następnym razem zadbać o wspólne zrozumienie potrzeb i możliwości ich realizacji.

To z kim my w końcu pracujemy?!

„Kontrolując” i „odbierając prace” w przypadku rozbieżności zwykle mówimy tylko „to nie to, zróbcie inaczej”. A tak naprawdę powinniśmy zastanowić się gdzie to niezrozumienie powstało, bo inaczej skazujemy się na kolejne jego wystąpienia w przyszłości.

W filmie pod tytułem „Kiedy Product Owner akceptuje prace Zespołu Deweloperskiego?” zastanawialiśmy się nad tym, skąd wynika potrzeba takiej kontroli i sprawdzania wszystkiego. Czasami jest to pokłosie przyzwyczajeń i poprzedniego trybu pracy. Jeżeli kierownik zespołu rozdzielał zadania, a potem je odbierał, to trudno może być takiej osobie stać się Product Ownerem, który zajmuje się backlogiem, a decyzje o tym „jak” wykonać pracę podejmuje Zespół Deweloperski.

Bardzo często jednak potrzeba kontroli pojawia się z powodu kiepskich doświadczeń. Sprawdzamy, bo kiedyś się przejechaliśmy. Przenoszenie jednak traum z przeszłości na wszystkie kolejne interakcje to po części droga donikąd, a po części samospełniająca się przepowiednia. Bo zakładając, że wszyscy chcą nas oszukać przyciągniemy takich ludzi do siebie i sprawimy, że udowodnią nam, że mamy rację. A tak wcale może nie być.

Spróbujmy założyć, że wszystkie rezultaty prac są wynikiem maksymalnego wysiłku włożonego przez zaangażowanych ludzi, którzy starają się spełnić wymagania w najlepszy według nich sposób. I jeżeli wyjdziemy z tego punktu, to zastanówmy się, dlaczego wyniki nie odpowiadają oczekiwaniom.

Odpowiedzią na „zawsze dostaję nie to co zamówiłem” nie jest „będę zawsze wszystko dokładnie sprawdzał zanim zaakceptuję”, tylko „zidentyfikujmy gdzie leży problem i go naprawmy”. Ewentualnie „rozstańmy się, bo współpraca nam nie idzie”. Taka możliwość też przecież istnieje. Być może nie mamy do czynienia z profesjonalistami, tylko z leserami, którzy wykorzystają każdą sytuację, żeby swojego pracodawcę naciągnąć.

Tylko pytanie wtedy brzmi: kto ich zatrudnił?