Transparentność 

Transparentność –  jedno ze słów (obok np. taxi) zapożyczonych z języka angielskiego (ang. transparency), które na język polski można przetłumaczyć używając między innymi słowa przejrzystość. Odmieniane w zwinnych podejściach na każdy, możliwy sposób. Co ona oznacza w środowisku biznesowym i jaki ma wpływ na nasze projekty?

Transparentność na co dzień

Aby odnaleźć polski odpowiednik słowa transparentność udałem się po Słownik Języka Polskiego. Hasło transparentność zostało tam wyjaśnione przy użyciu następujących określeń:

przezroczysty lub lekko przeświecający
łatwy do rozpoznania lub przewidzenia
jawny – SJP PWN

Wszystkie powyżej przytoczone określenia odnoszą się do jawności i przejrzystości. Nie ma tutaj znaczenia, czy rozpatrujemy transparentność w kontekście działania, stanu czy np. koloru. Używając tego określenia mamy na myśli czystość, przejrzystość analizowanego przedmiotu.

Już z powyższej definicji wynika, że w pełni transparentna postawa nie jest łatwa. Podobnie sytuacja wygląda z transparentnością rzeczy fizycznych, czyli artefaktów. W sytuacji, w której wydarzyło się coś negatywnego i mamy potencjalną możliwość ukrycia tego faktu, wiele osób z tej możliwości skorzysta. Co najważniejsze, nie zrobią one tego po to, aby osiągnąć korzyści, zrobią to po to aby uniknąć negatywnych konsewkencji.

Zastanawiając się nad sensem takiego podejścia, szybko dojdziemy do wniosku, że w długim terminie zadziała ono na szkodę absolutnie wszystkich interesariuszy.

Transparentność w Scrum Guide

Termin transparentność możemy znaleźć również w podstawowym źródle wiedzy o Scrum czyli w Scrum Guide. Został on tam użyty w dwóch kontekstach:

„Empiryczna kontrola procesu opiera się na trzech filarach: przejrzystości, inspekcji i adaptacji.” – Scrum Guide

Zgodnie z powyższym cytatem, transparentność jest jednym z trzech filarów stojących za Scrum. W tym ujęciu została więc wyniesiona do czynnika, bez którego metodyka o nazwie Scrum nie może istnieć.

Metodyka Scrum opiera się na empiryzmie. Co to oznacza w kontekście braku przejrzystości? Bez wiarygodnych danych „wejściowych” nie będziemy w stanie ocenić procesu wytwórczego. Dane, na podstawie których podejmować będziemy decyzje (pozyskane np. podczas spotkań Daily Scrum Meeting, Sprint Retrospective czy Sprint Review) będą w najlepszym wypadku niepewne, a w najgorszym – zupełnie błędne.

Nietrudno wyobrazić sobie sytuacje, w których członkowie zespołów deweloperskich przez błędnie rozumianą transparentność nie przekażą wszystkich niezbędnych informacji. Nie musi to być jednak celowe działanie, może to być nieświadome działanie członków zespołu deweloperskiego, którzy nie są w stanie przewidzieć konsekwencji. A czasami po prostu założą, że „i tak wszyscy to wiedzą”, co rzadko kiedy jest prawdą.

Nie tylko jeden z filarów…

Przejrzystość jest widoczna praktycznie we wszystkich elementach Scrum. Nie wyobrażam sobie przeprowadzić bez niej chociażby Sprint Retrospective. To właśnie podczas tego spotkania powinniśmy powiedzieć sobie wszystko, co ma zarówno pozytywny jak i negatywny wpływ na pracę naszego zespołu. Za każdym razem, kiedy nie mówimy lub kiedy boimy się transparentnie powiedzieć o naszych spostrzeżeniach musimy mieć na uwadze to, że sami osłabiamy swój zespół.

Transparentność jest istotna także w relacjach z klientem. Czasami zauważymy, że klient zamówił czegoś, czego nie potrzebuje lub z czego nie skorzysta . Innym razem okazuje się, że aktualnie realizowana funkcjonalność nie jest zgodna z Big Picture. W takich sytuacjach przede wszystkim powinniśmy o tym otwarcie porozmawiać.

Tutaj wracamy do podstaw metodyk zwinnych. Co prawda w przypadku zaniechania realizacji tej funkcjonalności, być może uszczuplimy dochody firmy, ale w długiej perspektywie spowodujemy wzrost zaufania u naszego klienta. A zaufanie w biznesie jest bezcenne i na pewno się zwróci.

Czasami trzeba się „przyznać”

O transparentność trzeba zadbać u źródła, poprzez stworzenie dla niej właściwego środowiska. Na vlogu #białko, w filmie dotyczącym Agile Mindset mówiliśmy o gotowości na porażkę.

„Wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Reguła przejrzystości wymaga, by aspekty te były opisane wspólnymi dla osób zaangażowanych standardami, tak by wszyscy obserwatorzy tak samo rozumieli to, co obserwują.” – Scrum Guide

To właśnie m. in. właściwe rozumienie gotowości na porażkę definiuje poziom transparentności na projekcie. Jeśli (zgodnie z Agile Mindset) żaden z członków zespołu deweloperskiego nie będzie ukrywał np. problemów z realizacją Backlogu Sprintu, to osiągniemy pożądany stan rzeczy. Co nim będzie? Przeświadczenie, że nikogo nie spotkają żadne negatywne konsekwencje za borykanie się z problemami. To z kolei pozwoli na podejmowanie decyzji na podstawie wiarygodnych danych pochodzących od członków zespołu deweloperskiego świadomie dzielących się zarówno sukcesami, jak i porażkami.

Nie będzie jednak przyjaznego środowiska, nie będzie gotowości na porażkę, bez Agile Mindset na poziomie całej organizacji. Nie ma tutaj znaczenia, czy mówimy o prezesie firmy, czy o testerze w zespole. Tylko takie podejście do zwinności zagwarantuje nam background niezbędny do pełnej przejrzystości.

Korzyści z przejrzystości

Nikogo nie trzeba przekonywać o korzyściach wynikających z transparentności. Nie ma tutaj znaczenia, czy mówimy o transparentności w życiu prywatnym, czy o transparentności w pracy. W obu przypadkach przejrzystość naszych zachowań i ekstrawertyczne dzielenie się sukcesami i wyzwaniami prowadzić będzie do osiągnięcia zamierzonego celu.

W zespole siła. Jeśli mamy problem, który uniemożliwia nam realizację zadań, zespół przyjdzie nam z pomocą. Podobnie w przypadku, gdy wykonywane przez nas zadanie jest powiązane z zadaniami innych członków Zespołu Deweloperskiego. Transparentne przestawienie sytuacji, informacje o trudnościach w realizacji zadania oraz o potencjalnych opóźnieniach z tego wynikających pozwoli na sprawną i bezbolesną reorganizację pracy ludzi zależnych od realizacji naszego zadania.

Negatywne aspekty transparentności

Jeżeli chodzi o współpracę – nie ma negatywnych konsekwencji dzielenia się stanem faktycznym naszej pracy. Jeżeli zaś chodzi o słynną „gotowość na porażkę”, to może pojawić się sytuacja, w której zespół deweloperski zbyt dosadnie przyswoi tę postawę. Może doprowadzić to do sytuacji, w której przez jakiś czas duża część Backlogu Sprintu nie będzie kończona.

Czy powinniśmy coś z tym zrobić? Oczywiście że tak. Powinniśmy transparentnie ustalić przyczynę takiego stanu rzeczy, a następnie wprowadzić działania naprawcze (zgodnie z ideą Inspect & Adapt). Spowoduje to umocnienie przekonania, że transparentne podzielenie się swoimi problemami prowadzi do wdrożenia najlepszych (w danym czasie), podjętych na podstawie prawdziwych informacji, akcji naprawczych.

A to pozwoli wszystkim zrozumieć, że transparentność to klucz do sukcesu.