Blog

Scrum by the book. Czy to gryzie?

Opublikowano
Warszawa, październik 14, 2021
Scrum, święty graal wśród zwinnych frameworków. Każdy o nim słyszał, mało kto go rzeczywiście widział. Zdecydowanie częściej słyszymy o tym, dlaczego Scrum się nie udaje, przez co budujemy w sobie jeszcze większy opór oraz dystans.

Czy jest się czego bać?

Aby zacząć rozmowę o Scrumie, warto wziąć pod uwagę kilka perspektyw: zespołu, klienta, a także łączącej ich współpracy.

Wszyscy mamy podobne obawy. Boimy się zmian i nie jest to niczyja wina. Nasz system nerwowy zawsze będzie dążył do regulowania bodźców i harmonii. Wszystko, co wypycha nas poza strefę komfortu, odczuwamy jako potencjalne zagrożenie i idącą za tym niechęć. Zmiana to jednak nie wszystko.

Gdyby przeprowadzić anonimową ankietę, większość z nas opowiedziałaby się zapewne za jak najmniejszą dozą odpowiedzialności przy możliwie najwyższym wynagrodzeniu. Skoro reperkusje (źle – odpukać w niemalowane!) podjętej decyzji może ponieść ktoś inny niż my, po co w ogóle się tym przejmować? Trudno jednak zdefiniować tego „innego” w przypadku, gdy większość z nas myśli tak samo.

Kolejnym, ale z pewnością nie mniej istotnym problemem, który poruszę w dalszej części tekstu, jest zaufanie. A w zasadzie brak lub minimalne jego zasoby.

Czy praca w „podręcznikowej” wersji Scruma to jedynie pogoń za mitycznym jednorożcem, galopującym po barwnej tęczy naszych niespełnionych ambicji?

(Współ)praca zespołowa

Zgrany zespół jest jak rodzina. Spędzamy z nim relatywnie dużo czasu, momentami nas irytuje, czasami nie potrafimy się zrozumieć, ale na dłuższą metę nie wyobrażamy sobie bez siebie pracy. Ale im bliżej są ze sobą ludzie, tym trudniej pewne rzeczy od siebie egzekwować.

Kierując się empatią, często obawiamy się zostawić w tyle członków zespołu, którzy radzą sobie gorzej od innych. Dostosowujemy się więc, zaniżając kolektywny potencjał. Może wydaje nam się, że taka postawa będzie bardziej koleżeńska? Sądzę, że o wiele lepiej byłoby jednak wspólnie popracować nad tym, aby gorzej radząca sobie osoba postarała się dorównać reszcie. Jesteśmy zespołem, więc powinniśmy pomagać sobie w rozwoju. Nawet, jeśli nie zawsze będzie to wygodne i przyjemne. Uprzedzając: zazwyczaj przyjemne nie jest. Ale warto!

Czy potrafisz dawać i otrzymywać konstruktywny feedback? Ja miewam z tym problem i podejrzewam, że podobnie ma większość z nas. Od dziecka wychowujemy się w wadliwej kulturze otrzymywania i dzielenia się opinią. Omijamy konflikty zgrabnym, kocim ruchem, ponieważ są dla nas niewygodne. Boimy się być oceniani, boimy się oceniać innych.

Co się wydarzy, jeśli ktoś z zespołu źle o nas pomyśli? Czy przestaniemy być lubiani? Takich lęków może być sporo, więc przy tym wszystkim łatwo zapomnieć, że brak właściwej komunikacji stanowi największą przeszkodę dla osiągnięcia wspólnego celu.

Niezwykle ważnym jest, aby firma, w której pracujemy wspierała zespoły, zachęcając je do otwartej komunikacji.

Pomocne mogą być również szkolenia, np. z porozumienia bez przemocy, prowadzone przez wykwalifikowane osoby z działu Human Resources lub People. To, że czegoś nie potrafimy, nie oznacza, że nie możemy się tego nauczyć i warto się z tą myślą oswoić. W każdym momencie możemy poprosić o pomoc i – co najlepsze – z takiej pomocy skorzystać.

Ciekawe, ilu programistów na świecie obudziło się kiedyś zlanymi potem w środku nocy, bo przyśniło im się, że musieli rozmawiać z klientem… Rozmawiać! Z klientem! Zespół w Scrumie jest samoorganizujący się, co oznacza, że w obrębie określonych przez organizację ram, może podejmować decyzje samodzielnie. Ze względu na brak Project Managera, który dotychczas wszelką komunikację brał na swoje barki, to właśnie zespół deweloperski w ramach własnej odpowiedzialności powinien pozostawać w czynnym kontakcie z klientem (Product Ownerem).

Każdy z nas jest specjalistą w określonej dziedzinie, więc któż inny mógłby lepiej wyjaśnić specyfikę swojego pola działania klientowi? Doskonale wiem, że to może boleć, lecz warto pomyśleć o tej zmianie jak o rozwoju swoich kompetencji miękkich. Jednocześnie, może rozszerzenie swojego pola widzenia pozwoli także lepiej zrozumieć wyzwania, jakie dotychczas stały przed kierownikiem projektu, a przez to bardziej docenić kompetencje innych członków zespołu.

Zespół bez Project Managera

Ratunku, Project Manager zostanie bez pracy! Czy aby na pewno? Scrum buduje w zespole poczucie odpowiedzialności i samoorganizację, ale… Po pierwsze – jak każdy proces, wymaga to bardzo dużo czasu. Po drugie – być może odzywa się tu właśnie w project managerskich głowach strach przed utratą kontroli nad ludźmi i procesem?

W rzeczywistości jest to doskonała okazja do wyjścia poza swoją strefę komfortu i odnalezienia się w nowej roli lub skupienia się na tych elementach pracy, które przyniosą większą wartość organizacji. W Scrumie bowiem Scrum Master jest potrzebny bardziej niż kiedykolwiek wcześniej. To właśnie on będzie miał największy wpływ na tworzenie bezpiecznego środowiska, w którym zespół będzie w stanie stale przyjmować na siebie coraz większą odpowiedzialność za wykonaną pracę oraz podnosić sobie poprzeczkę, stając się jeszcze bardziej efektywnym bez utraty morale.

Spotkania, które nie mogłyby być mailem

Wszyscy nie lubimy spotkań, które mogłyby być mailem. Niemniej, niektóre spotkania są wartościowe i do takich właśnie należą cykliczne wydarzenia definiowane przez Scrum Guide:

  • codzienny Scrum (daily)
  • planowanie sprintu
  • przegląd sprintu
  • retrospektywa

 

Mimo, że każde z tych spotkań różni się agendą, wszystkie mają to samo zadanie: pomóc zespołowi osiągnąć cele związane ze stworzeniem jakościowego produktu. Konstrukcja wydarzeń scrumowych ułatwia komunikację, bieżącą wymianę i wyrównywanie wiedzy w zespole dotyczącej statusu prac. Pozwala ona również szybko identyfikować aktualne problemy oraz przez odgórnie określone ramy czasowe, naturalnie skłania uczestników do szybkiego podejmowania decyzji.

O ilu spotkaniach wrzuconych ad hoc w nasze kalendarze moglibyśmy powiedzieć to samo?

Doceńmy porażki

Strach przed porażką to bardzo trudny temat, który dotyczy każdego z nas. Zamiast jednak starać się jej unikać za wszelką cenę, lepiej zaakceptować jej obecność. W momencie, kiedy organizacja daje nam przestrzeń na popełnianie błędów i nie ruga za źle podjęte decyzje, naturalnie buduje się w nas postrzeganie ewentualnej porażki jako dobrej okazji do wzrostu i innowacji. Może zamiast płakać nad rozlanym mlekiem, milej będzie poklepać po ramieniu swojego kolegę lub koleżankę i pochwalić za to, że spróbował/a stworzyć dzbanek do mleka z dziubkiem w kompletnie innym miejscu?

Kliencie, ty druha we mnie masz

Czy po drugiej stronie płotu trawa faktycznie jest bardziej zielona? Zastanówmy się z jakimi problemami może mierzyć się osoba pracująca po stronie naszego klienta.

Bycie Product Ownerem (ang. właścicielem produktu), czyli osobą dbającą o to, aby produkt przyniósł jak największą wartość jego końcowym użytkownikom, przy uwzględnieniu potrzeb wszystkich zaangażowanych w proces interesariuszy, niesie za sobą dużą odpowiedzialność. Nie jest to jednak jedyne wyzwanie, z jakim trzeba się w tej roli mierzyć. Konieczność angażowania się w projekt i pracy ręka w rękę z zespołem wymaga czasu… dużo czasu. Tłumacząc się jego brakiem w obawie przed dodatkowymi obowiązkami często zapominamy, że transparentna komunikacja to solidna podstawa, której efekty można bardzo szybko dostrzec. Komunikując się bezpośrednio z członkami zespołu, unikamy przestojów w komunikacji i nieporozumień. Dzięki temu w ostatecznym rozrachunku tworzymy lepszy produkt, którego wizję w ten sam sposób rozumieją wszystkie zaangażowane strony.

Kolejne wyzwanie dla Product Ownera może stanowić konieczność sprawnego podejmowania trudnych decyzji. Większość z nas z wielu powodów ma z tym problem, a klient to przecież taki sam człowiek jak ja i Ty, tylko, że po drugiej stronie lustra. Obawa przed pojęciem złej decyzji i związane z nią konsekwencje mogą na wstępie sparaliżować niejednego śmiałka. Jednak hej…, czy nie na tym polega dorosłe życie? Dobrą informacją jest jednak to, że każda błędna decyzja może zostać naprawiona przy kolejnej iteracji. Poza tym, błędy są po to, aby je popełniać i uczyć się na nich bycia lepszymi.

Dlaczego “time & material”?

Let’s talk serious business now – porozmawiajmy o pieniądzach. Klienci wciąż bardzo niechętnie godzą się na pracę w modelu time and material, w którym rozliczamy się na podstawie faktycznie przepracowanego czasu. Jest to model, który między innymi w Scrumie, jest nie tylko najbardziej pożądany, lecz przede wszystkim najbardziej opłacalny w dłuższej perspektywie czasu. Zapewne znajdziemy sporo osób, które mogą podejrzewać, że zespół wykorzysta to rozwiązanie do maksymalizacji zysku. Największym zyskiem w Scrumie jest jednak dostarczenie dobrego produktu końcowemu użytkownikowi, więc najbardziej słusznym rozwiązaniem będzie… zaufanie swojemu partnerowi.

Przy realizacji projektu zarówno klient, jak i zespół powinien przyjąć, że żadna ze stron nie będzie nadużywała środków, które ma do dyspozycji. Dzięki iteracyjnemu podejściu do pracy, brak przyrostu rozumiany tu jako widoczny brak postępu w realizacji projektu zostanie bardzo szybko wychwycony. Miejsce na nadużycia jest więc dość niewielkie i nie sądzę, aby jakikolwiek zespół zaryzykował dobrą relację z Product Ownerem dla zysku, który szybko odbiłby się czkawką.

Czy Scrum jest drogi?

Skoro jesteśmy przy finansach, Scrum przez wielu klientów postrzegany jest jako drogie rozwiązanie. Nie trzeba tu skomplikowanych obliczeń, aby relatywnie szybko dojść do wniosku, że kaskadowy model pracy (ang. waterfall) w ostatecznym rozrachunku będzie dla klienta dużo droższy. Dlaczego, zapytasz? W ciągu całej długości życia projektu (przyjmijmy, że praca potrwa rok), świat na zewnątrz i potrzeby konsumentów są w stanie zmienić się na tyle dynamicznie, że po dostarczeniu produktu na rynek może okazać się, że jest on zupełnie bezwartościowy. Co to oznacza? Kolejne zmiany, poprawki, czas i tak… koszt, który będzie musiał pokryć klient. Warto więc samemu odpowiedzieć sobie na pytanie:

Czy w dłuższej perspektywie czasu dzięki bardziej zwinnemu podejściu do pracy nie tylko zaoszczędzimy pieniądze, ale i stresu – klientowi, interesariuszom i zespołowi?

Czas ma znaczenie

My tu o pieniądzach, a przecież czas to również pieniądz. Zespół scrumowy jest w stanie jakościowo zaplanować swoją pracę do mniej więcej dwóch tygodni naprzód (dwa tygodnie to najpopularniejsza długość sprintu). Trudno tu jednak mówić o podpisaniu się krwią pod datą finalnego oddania produktu, która już na tym etapie jest z góry określona przez biznes.

Co to oznacza dla klienta? Najczęściej strach i pot na plecach, bo przecież przełożeni chcą wiedzieć, kiedy produkt wejdzie na rynek. Tu, podobnie jak wyżej, potrzebujemy obopólnego zaufania. Działanie w Scrumie nie oznacza „hulaj dusza, piekła nie ma”, natomiast pozwala zabezpieczyć się przed sytuacją, którą każdy z nas zna z codziennej pracy. Niech pierwszy rzuci kamieniem ten, kto widział projekt, który zmieścił się w ustalonym na początku prac terminie. Nawet Wróżbita Maciej nie jest w stanie tak daleko sięgnąć swym trzecim okiem w przyszłość, aby przewidzieć, co wydarzy się po drodze.

Każdy zakończony sprint, każda dostarczona funkcjonalność przynosi w Scrumie mierzalne wyniki

Dzięki mierzalnym wynikom Product Owner może oszacować, w jakim tempie pracuje zespół i jaki progres w tym czasie uczynił. Na podstawie pierwszych sprintów, które powinny służyć rozpoznaniu wielkości i wymagań projektu, zespół będzie mógł o wiele sprawniej oszacować czas potrzebny do ukończenia prac nad poszczególnymi funkcjonalnościami i na tej podstawie zaproponować przewidywany termin oddania ukończonego produktu. W sytuacji, w której deadline oraz budżet są odgórnie narzucone przez interesariuszy, Scrum pozwoli dość precyzyjnie oszacować, jaką część produktu zespół może realnie zrealizować do tego czasu. Jeśli jednak będą to czynniki negocjowalne, zespół będzie w stanie dokładnie zweryfikować, ilu dodatkowych developerów trzeba dodatkowo zatrudnić, aby dostarczyć produkt ze wszystkimi jego funkcjonalnościami.

Toast za komunikację

Wspomniałam już, że komunikacja buduje fundamenty dobrze zorganizowanej współpracy. Bez niej żaden, nawet najbardziej utalentowany zespół nie osiągnie wspólnie wyznaczonego celu. Każdy z nas, bez względu na obejmowaną przez siebie rolę, może zachęcać innych do szczerej i otwartej komunikacji. Jeśli w zespole mamy osoby, które na co dzień unikają okazji do rozmowy, możemy wspólnie zadbać o to, aby każdy miał tę samą przestrzeń na wyrażanie swoich myśli i potrzeb. Już tak proste ćwiczenie, jak zmiana osoby facylitującej wydarzenie scrumowe, może przynieść dużo korzyści i pomóc otworzyć się co bardziej introwertycznym osobowościom. Możliwości jest wiele, wystarczą chęci i wytrwałość, aby te chęci przekuć w czyny.

Na koniec świata i jeszcze dalej

Poruszyłam sporo wątków, ale pytanie pozostaje jedno: co zrobić, aby było dobrze?

Próbować, popełniać błędy, padać na kolana, podnosić się z nich, otrzepywać kurz i… próbować dalej!

Scrum to proces, a w organizacji takiej jak SYZYGY pozwalamy sobie na błędy, bo wierzymy, że innej drogi do wzrostu nie ma. Do tego dodajmy transparentną komunikację, która zwiększa zaufanie do organizacji, jak i członków naszego zespołu, ale… o turkusowym zarządzaniu jeszcze na pewno opowiemy.

W SYZYGY pełnię m.in. role Agile Facilitator i Backlog Master