Houston, mamy problem, Scrum nie działa! (cz. 2)

Po rozbiciu na części pierwsze tematu spotkań i samoorganizacji w cz. 1, przyszedł czas na przyjrzenie się kolejnym dwóm sprawom – Product Ownerowi i pytaniu “Projekt czy produkt?”. Obie są bardzo istotne i warto zagłębić się w nie nieco bardziej, ponieważ mają znaczący wpływ na ostateczny kształt tego, co wytwarzamy. Ah, i przyczyniają się do tego, że stwierdzenie “Scrum nie działa” zyskuje na popularności. Zachęcam do lektury!

Product Owner

Właściciel produktu w Scrum pełni bardzo ważną rolę. To on wyznacza kierunek działań, ma pełną decyzyjność, największą wiedzę o produkcie, użytkownikach i docelowego rynku na jaki go kierujemy. Dzięki PO zespół wie co przyniesie na dany moment największą wartość odbiorcom, jakie są priorytety, plany na przyszłość. PO jest wizjonerem, nadającym działaniom zespołu sens.

Co sprawia zatem, że PO przyczynia się do wspierania ruchu “Scrum nie działa”?

Przyczyna

„Product Owner nie jest dla nas dostępny”
„Możemy odpuścić retrospektywę?”
„Dlaczego to zadanie trwało tak długo? Przecież wygląda na proste!”

Pierwszą, wg mnie najważniejszą sprawą jest jego dostępność dla zespołu. W projektach w których uczestniczyłam, był to najczęściej występujący problem. Prawie każdy PO nie miał dla nas czasu, rzadko bywał dostępny, uczestnictwo w spotkaniach starał się ograniczać do minimum. Oliwy do ognia dolewał fakt, że PO po stronie klienta, najczęściej był z innej strefy czasowej. Drugi ważny temat, o jaki często się potykaliśmy, to nieznajomość procesu. Nowy, nieświadomy, wrzucony na głęboką wodę klient, nie znał Scruma, celu poszczególnych działań czy spotkań. To co dla nas było ważne, znane i lubiane, dla niego często było niczym istotnym, kradło mu z budżetu pieniądze. Stwierdzenie „Możemy odpuścić retrospektywę?” było dla mnie zawsze jasnym tego potwierdzeniem.

Kolejna sprawa, która ze wszystkich wymienionych wymaga najwięcej zaangażowania od zespołu, to brak zaufania PO do ludzi, z którymi pracuje. PO będący na co dzień w innej organizacji rzadko ufał odległemu o setki kilometrów zespołowi. Taki brak zaufania przejawia się w ciągłym dopytywaniu „ile to trwało?”, czy też denerwowaniu się gdy coś okazywało się trudniejsze niż zakładaliśmy. Często w czasie estymacji dało się słyszeć z ust PO „przecież to jest proste, na pewno to mniej niż 8”. Nie trzeba dodawać, że zespół deweloperski odczuwał to jak patrzenie im na ręce podczas pracy. W takich sytuacjach, dało się zauważyć frustracje, demotywację i poczucie niekompetencji. W rezultacie taka atmosfera od razu uruchamia negatywne myślenie. I wtedy słychać “W software housie Scrum nie działa”.

Rozwiązania

Podczas rozważania jak pracować z PO by zniwelować opisane problemy do minimum, zdaliśmy sobie sprawę, że tak naprawdę, każdy nasz PO stawał się nim nie z wyboru, lecz w wyniku wymagań jakie były przez nas stawiane. Sytuacja trochę jak z komiksu na slajdzie – krótkie wprowadzenie, szkolenie odhaczone, a wymagania rosną. Nie dlatego, że to był warunek umowy, ale dlatego, że nasza organizacja tak funkcjonuje – w Scrum. Każdy z klientów, nieświadomy tej roli zgodził się na nią, a my nie do końca świadomi jego niewiedzy, uparcie szliśmy tą drogą. W efekcie mieliśmy nieznającego Scruma PO, który nie rozumiał procesów i prawdopodobnie pewny siebie zespół stawiający przed nim coraz to nowe wyzwania i wymagania. Dodatkowo, chcieliśmy, by nam zaufał, pozwolił robić swoje, bez wyjaśnień i przestrzeni na zrozumienie każdego z etapów wytwarzania jego własnego produktu. Skutkiem były obie strony sfrustrowane wzajemną postawą.

Na wszystkie te problemy są oczywiście rozwiązania. Przede wszystkim warto mieć świadomość, że PO może nie być obeznany z należącymi do niego obowiązkami. Z pewnością ogromną rolę odegra Scrum Master, którego zadaniem jest właśnie wsparcie PO.

Istotne będzie edukowanie PO ze spokojem i cierpliwością, a także z dużą dozą transparentności i szczerości. To także prosta droga do zdobycia zaufania. PO to członek zespołu scrumowego, więc jest integralną częścią wszystkich działań jakie ten podejmuje. Powinien też wiedzieć, że jest tu potrzebny, a nawet kluczowy. Regularny feedback na retrospektywach i poza nimi pozwoli Właścicielowi Produktu oswoić się z pracą jaką ma do wykonania.

Cytując jednego z twórców Scruma:

„Jak przekonać klienta do używania Scruma? Nie eksponuj tego klientowi. Po prostu zacznij używać Scruma, dostarczaj coś w równych odstępach czasu i pytaj, czy to jest to, czego potrzebuje.”
Ken Schwaber

Czasami zapominamy, że to właśnie PO jest tym, który kreuje wizję i wyznacza kierunek. Stopniowe wprowadzanie go w nasze potrzeby, wspierania i pomoc tam, gdzie tego potrzeba na pewno pozwoli zrobić krok do przodu. Nie zawsze zadzieje się to z dnia na dzień, na naukę potrzeba czasu.

Projekt czy produkt?

Ostatni już punkt, to właściwie pytanie. Realizujemy projekt czy produkt? Na czym się skupiamy? Na realizacji konkretnego zakresu czy dostarczaniu wartości użytkownikom?

I dokładnie w tym miejscu dochodzimy do sedna problemu. Zespoły stają przed tym wyzwaniem praktycznie cały czas – pracujemy nad określonym w czasie projektem, czy może wytwarzamy produkt? O to pytanie można oprzeć szereg problemów np. brak transparentności, niespełnione cele sprintów, wykonywanie niedodających wartości elementów produktu itd.

Bezsprzecznie problemem w tym punkcie jest kierunek myślenia, to na czym się skupimy – ścisłym zakresie czy realnej wartości? Finalnie, będzie to miało odzwierciedlenie w końcowym kształcie produktu, jego sukcesie, czasie wprowadzenia na rynek, a także na zadowoleniu ogólnym zespołu ze swojej pracy.

Przyczyna

Płynnie przechodząc do przyczyny, w tym punkcie, wg mnie, ważne jest właściwe skupienie uwagi. Przyzwyczajeni do standardów projektowych myślimy o tym nad czym pracujemy jak nad dokładnie rozpisanym, ograniczonym w czasie zakresie, co niejednokrotnie okazuje się błędem i kończy się rozczarowaniem po stronie biznesu. Scrum przecież jest frameworkiem wspierającym wytwarzanie i utrzymywanie produktów, które nierzadko się zmieniają.

Z drugiej zaś strony zespół staje się zdemotywowany, wydaje się że wykonaną wcześniej pracę należy wyrzucić do kosza, nowym funkcjonalnościom nie ma końca, a termin wydania staje się coraz bardziej odległy. W tym wszystkim znika myślenie o dużym tworze jakim jest produkt, a dominuje zapatrzenie w swoje zadania. W następstwie definiuje się cele sprintów po to by były, a nie po to, by miały faktyczny sens dla użytkownika. Najważniejsze staje się to, że zadanie jest odhaczone.

Rozwiązanie

Scrum nie działa jak projekt, framework to procesy nakierowane na wytwarzanie wartościowych produktów. A zatem:

Co jest teraz najważniejsze?

Do jakiego celu wszyscy dążymy? Chcemy mieć na końcu działający produkt. Z pewnością mając to na względzie, możemy podejmować jako team najlepsze dla całości decyzje. Czasami by ten stan osiągnąć, należy wywrócić dotychczasową pracę do góry nogami.

Idąc dalej – Scrum Guide mówi nam, że co sprint powinien być wydawany działający i potencjalnie gotowy do przekazania użytkownikom przyrost. Warto zastanowić się, czy tak faktycznie tak jest, czy cel sprintu jest mierzalny i sensowny? Czy nasz przyrost dostarcza wartość użytkownikowi?

To jak? Scrum nie działa?

Podsumowując, przekazane przeze mnie w dwóch artykułach (zobacz cz.1) zagadnienia reprezentują wg mnie jedne z ważniejszych problemów z jakimi się spotykamy w zwinnym środowisku. Oczywiście łatwo zauważyć, że każdy z omówionych punktów nie wyczerpał tematu, bo przecież ile zespołów i produktów, tyle będzie większych lub mniejszych problemów.

Jedno mogę zapewnić – zwalczając przedstawione przeze mnie problemy spowodujecie, że machina, jaką jest Scrum nie będzie potrzebowała wsparcia bazy w Houston i bezpiecznie sprowadzicie swój statek na ziemię.

Na koniec myśl jednego z dwóch twórców Scruma, z którą zgadzam się w 100% i z którą chciałabym Was zostawić, jednocześnie zachęcając do usprawniania procesów we własnych organizacjach i zespołach.