Prawdomówność i jej nieodłączni towarzysze

Trzy role. Trzy cechy. Transparentność, zaufanie i prawdomówność. Mówiliśmy już zarówno o scrumowych rolach, jak i wielokrotnie o poszczególnych cechach. Nadszedł czas na nieco głębsze przemyślenia. Dziś #białko w wariancie filozoficznym.

 

Prawdomówność, czyli zdrowa współpraca

Żeby nasz Scrum Team darzył siebie zaufaniem, musi się znać i zgrać. Co więcej, nie może też być w jego historii przypadków karania za zwinne eksperymenty. Nie możemy wytykać sobie sytuacji w których “spróbowaliśmy i się nie udało”, bo ani nie będziemy próbować, ani nie będziemy przyznawać się, że coś nie wyszło. Stracimy prawdomówność, a co za tym idzie – transparentność.

Bo to właśnie pełna transparentność powoduje, że decyzje podejmowane są na podstawie realnych przesłanek. Gdy planujemy podróż, liczmy na to, że wskazania prędkościomierza i stanu paliwa są realne. W pracy zaś zakładamy, że wszystkie informacje, które do nas spływają są wiarygodne. Inaczej nasza praca zamienia się w horror.

Jeśli nie ufamy temu, co inni do nas mówią, to i sami niekoniecznie będziemy grzeszyć prawdomównością. Nie możemy przecież odkryć wszystkich naszych kart. I tak prawdomówność, która przecież leży u podstaw zwinności idzie w odstawkę. Zamiast niej pojawiają się knucie, naciąganie rzeczywistości, rzeczy “prawie zrobione” i “niepełne sukcesy”.

 

Płaszczyzny porozumienia

Mamy trzy role w Scrum. Product Owner zasadniczo maksymalizuje wartość dostarczanego przez Zespół Deweleperski Przyrostu, a nad wszystkim czuwa Scrum Master, który dba o to, by Scrum był stosowany efektywnie. Tu nie ma żadnego miejsca na brak prawdomówności. W żadnym przypadku, żadna z ról nic nie “zyskuje” na kłamaniu bądź pomijaniu prawdy.

Wiemy już, że w sytuacji, w której system nagradza niepożądane zachowanie, mamy praktycznie gwarancję jego częstszego występowania. Jeśli więc za “niedowiezione” wymagania w Sprincie nasz Product Owner będzie urządzał awantury, to Development Team odniesie korzyść na zatajaniu przed nim prawdy. A to nie o to chodzi.

Zespół mówi prawdę i sobie ufa. Product Owner nie kontroluje zespołu, ale zakłada, że prognozy są realne, a artefakty – transparentne. Wszyscy od wszystkich oczekują szczerości i poszanowania, a nikt nie zamiata nic pod dywan. To są warunki, przy których nie tylko kwitnie współpraca, ale i w których nasz klient będzie miał szansę być zadowolony.

 

Zagrożenia prawdomówności

Nie wyobrażam sobie żadnej sytuacji, w której wewnątrz jakiegokolwiek zespołu mającego wspólny cel “opłaca się” kłamanie czy nieprzekazywanie kluczowych dla wszystkich informacji. Jeśli gramy do jednej bramki, to w żadnym wypadku brak informacji o naszych słabych stronach albo nawet zatajenie mocnych stron nie przyniesie nam korzyści.

Takie pseudokorzyści mogą pojawić się w przypadku braku zaufania na linii zespół – PO lub zespół – rola zewnętrzna. Taka rola, która może niejako wymuszać pozytywne informacje spływające od zespołu, to na przykład Project bądź Product Manager. Oni, podobnie jak Product Owner, mogą naobiecywać interesariuszom rzeczy, z których nie będą potrafili się potem wywiązać.

Tylko jest to postawienie problemu na głowie. Transparentność, zaufanie i prawdomówność jak najbardziej leżą też w kręgu zainteresowań naszego klienta.

Jeżeli oddaję motocykl na przegląd i słyszę, że będzie on do odbioru za dwie godziny, to planuję np. wizytę na siłowni, a potem spotkanie biznesowe na które nim pojadę. Jeżeli zabrakło transparentności i mechanik nie miał szans się nim zająć przez najbliższe trzy godziny, to kierownik warsztatu nie był dla mnie prawdomówny. A co za tym idzie, warsztat stracił moje zaufanie.

Jeżeli nasz system do zarządzania backlogiem posiada wiele różnych zestawów uprawnień albo wręcz nie jest w ogóle dostępny dla naszego klienta, to niestety mamy tu do czynienia z obiecywaniem “będzie pan zadowolony”. Gdybym widział grafik pracy wspomnianego powyżej mechanika, mógłbym zupełnie pominąć pośrednictwo kierownika i samemu zaplanować swój dzień o wiele lepiej.

Najczystsze scrumowe sytuacje jakie widziałem, to cały Product Backlog w pełni dostępny dla klienta wewnętrznego. Wtedy rolą Product Ownera nie jest raportowanie statusu projektu, ale nauczenie interesariuszy znaczenia poszczególnych liczb.

Im bardziej gramy w otwarte karty, tym więcej zaufania ma do nas nasz klient. W granicznym przypadku udostępniamy mu pełnię informacji o toczonych się pracach, a on z tych informacji nie korzysta. Ufa nam, że wszystko będzie tak szybko jak się da, przy zachowaniu znanej mu jakości.

 

Prawdomówność – jak zacząć

Żeby wyrwać się z zaklętego kręgu w którym nikt nie mówi prawdy, bo nie ufa, więc działamy przy braku transparentności, ktoś musi zacząć. Ktoś musi zacząć ufać, stworzyć bezpieczne środowisko i przede wszystkim nie karać i nie wytykać porażek. W ogóle. Czasami przecież coś po prostu nie wychodzi.

Jeżeli zatrudniliśmy najlepszych dostępnych ludzi i stworzyliśmy im najlepsze możliwe warunki do pracy, to załóżmy, że wkładają oni maksimum wysiłku i starają się osiągnąć najlepsze wyniki. Przyznajmy sami przed sobą, że oni mają te same przemyślenia i odczucia jak my i w podobny sposób wykonują pracę.

I dotyczy zarówno naszych koleżanek i kolegów z zespołu, jak i naszych przełożonych czy podwładnych. Czyli inaczej mówiąc – ludzi.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: