W pogoni za wartością – streszczenie webinaru Scrum.org

Niedawno miałam okazję być słuchaczem webinarium zorganizowanego przez Scrum.org. Miało ono ciekawy tytuł „The Continous Hunt for Value”. Jako, że pełniąc rolę PO temat wartości jest mi z definicji bliski, to właśnie tytuł spotkania skusił mnie do zapisania się na to wydarzenie. Zaskoczył mnie fakt, iż jednym z prelegentów okazał się Polak – Tomasz Maj – praktyk i pasjonat metodyk zwinnych z ponad 10-letnim doświadczeniem.

Webinarium poświęcone było przedstawieniu tematyki, o której Tomasz wraz z zespołem napisali publikacje o tytule: „In pursuit of value – not work”. Podkreślają tam znaczenie różnicy między wykonywaniem pracy dla samej pracy, a pracą na rzecz tworzenia wartości. Wnioski, które wyciągają bazują na analizie danych z wywiadów z praktykami agile.

Poniżej znajdziecie streszczenie najistotniejszych punktów owej pracy. Jeżeli będziecie chcieli zgłębić temat, to nagranie z webinarium można znaleźć tu [1], natomiast publikację do przeczytania tu [2].

Wprowadzenie w tematykę

Scrum jest obecnie bardzo popularną metodyką stosowaną w wielu organizacjach. Udane zwinne transformacje pokazują, że można osiągnąć m.in. nawet 30% zwyżkę zadowolenia użytkowników z produktu. Większość firm jednak nie osiąga tak spektakularnych wyników. Autorzy publikacji stawiają tezę, że jest to spowodowane faktem, iż Scrum jest realizowany „mechanicznie”, czyli z naciskiem na wykonywanie pracy, a nie dostarczanie wartości.

W takim środowisku liczy się odhaczanie kolejnych tasków, a ich liczba jest miarą sukcesu; istotny jest ciągły wzrost prędkości dostarczania (ang. velocity), zamiast efektu dla użytkownika (ang. Customer outcome); brak jasności dlaczego robimy to co robimy; brak bezpośredniego kontaktu z użytkownikiem. Nie jest to ani prawdziwy Scrum, ani zwinność.

Autorzy zauważają trzy główne korzyści wynikające z ukierunkowania uwagi całego Zespołu na dostarczanie wartości:

  • Elastyczność, która umożliwia tworzenie kreatywnych i innowacyjnych rozwiązań.
  • Lepsze rozumienie celu wykonywanej pracy, co wpływa pozytywnie na motywacje Zespołu.
  • Tworzenie dobrej, bazującej na zaufaniu relacji z Klientem, co przyczynia się do lepszych rezultatów produktu.

W 2020 „Przewodnik po Scrumie” został uaktualniony o ideę Celu produktu [3]. Miało to na celu zmianę podejścia do Backlogu – zamiast traktować go jako uporządkowaną listę zadań do wykonania, miał stać się tworem, który realizuje jeden jasno zdefiniowany Cel Produktu. To z kolei ma zachęcać Zespoły do aktywnego angażowania się w jego tworzenie, umożliwiając samo-organizację i innowacyjność. Backlog powinien powstawać w skupieniu na efekcie końcowym, czyli na dostarczanej wartości.

Autorzy publikacji opisują dalej 4 schematy utraconych szans, których doświadczają organizacje, w wyniku braku ukierunkowania na dostarczanie wartości.

Tracimy SZANSE, gdy..

Management traktuje Zespoły jako trybiki, które jedynie realizują zadania.

Gdy tak się dzieje, Zespoły często nie mają jasnej wizji Produktu. Nie wiedzą jaki efekt końcowy dla użytkownika ma zostać uzyskany i jak realizowane elementy wpływają na pełen obraz produktu. Dostają do realizacji gotowe opisy rozwiązań i nie mają możliwości ich kwestionowania. Takie podejście zabija kreatywność i motywację.

Sytuacja zmienia się, gdy Management przejrzyście mówi o celach strategicznych organizacji, a także o tym jak Produkt będzie je realizował. Zaszczepia w Zespole wizję Produktu i oddaje w ich ręce kontrolę nad kwestią „JAK”. Zespoły mają możliwość samodzielnego wypracowania najlepszego rozwiązania i dzięki temu czują sens swoich działań, co pozytywnie przekłada się na ich motywację.

Praca jest priorytetyzowana bazując na rozmiarach zadań, zamiast na dostarczanej wartości.

Brak określonej, opartej o cel definicji sukcesu powoduje, że członkowie Zespołu nie mają wspólnego zrozumienia czym jest wartość. Istniejące metryki nie obrazują tego aspektu. Na planowaniu, zamiast rozmawiać o wartości dostarczanej Użytkownikowi, Zespół skupia się na tym, by wszyscy mieli zakolejkowane zadania. Używane metryki skupiają się na efektywności Zespołu, co przekierowuje jego uwagę na to by robić jak najwięcej i najszybciej. Nikt nie zastanawia się nad celem tego, co robimy.

Rozwiązaniem problemu jest jasne określenie czym jest sukces w kontekście użytkownika. Następnym krokiem jest zdefiniowanie metryk skupionych wokół wartości, a nie pracy zespołu. Przekierowując uwagę zespołu na takie metryki prawdziwa wartość staje w centrum uwagi. Jeżeli metryki te wskazują sukcesy – celebrujcie je!

Agile Coaching skupiony na „robieniu Scruma dobrze”, zamiast na dostarczaniu wartości.

W tych sytuacjach Scrum Masterzy skupieni są głównie na procesie. Mierzone są jedynie prędkość i przewidywalność, będące wyznacznikiem „dobrze” działającego Scruma. Często zaniedbuje się jednak aspekty związane ze zrozumieniem przez Zespół tego, czym jest wartość; kim są prawdziwi Interesariusze Produktu; jak praca Zespołu na rzecz Produktu realizuje cele firmy.

Aby zyskać na prawdziwej zwinności Scrum Masterzy powinni pomóc Zespołowi zrozumieć powyższe kwestie. Można to robić poprzez dobre sformułowanie Celu Produktu i każdorazowo Celu Sprintu (przez Zespół!) – tak, by były one skupione wokół wartości. Dbanie o to, aby powyższe Cele były jasno widoczne i zrozumiałe dla całej organizacji pozwoli uzyskać pełną zgodność celów firmy, z tym co realizuje Zespół. Takie działania umacniają Zespół i kierują ich uwagę ku wartości.

Brak kontaktu całego Zespołu z Klientem

Najlepiej kiedy kontakt z użytkownikami ma cały Zespół, a nie tylko Właściciel Produktu. Brak bezpośrednich interakcji z Interesariuszami utrudnia zrozumienie sedna problemu. Brak możliwości porozmawiania z użytkownikami końcowymi, powoduje, że de facto Zespół realizuje przekazywane wymagania zamiast samodzielnego wypracowania najlepszego rozwiązania. Takie odizolowanie od prawdziwego użytkownika często jest podyktowane kulturą organizacji lub procesami w firmie, ale niekiedy także brakiem chęci ze strony członków Zespołu. Wymaga to bowiem wyjścia ze strefy komfortu, jeżeli nie jest to dla kogoś codzienność.

Zmiana tego podejścia powinna polegać na uzyskaniu kontaktu z odpowiednimi Interesariuszami. Jeżeli to możliwe, użytkownicy końcowi powinni uczestniczyć w spotkaniu Przeglądu Sprintu, prowadzonego nie jako demo, ale przede wszystkim jako rozmowa o tym co zostało zrobione i jaki będzie to miało wpływ na wykorzystanie przez nich Produktu. Zespół powinien mieć także możliwość bezpośredniego kontaktu z Interesariuszami w trakcie Sprintu, jeśli pojawiają się pytania.

Podsumowanie

Wiele ciekawych aspektów zostało opisanych w artykule i podczas webinarium. Warto zastanowić się nad nimi chwile, gdyż głębsza analiza działania Scruma w organizacji może obnażyć niewidoczne na pierwszy rzut oka słabości. Wprowadzenie zmian, szczególnie zahaczających o kulturę organizacji, może się wydawać niemożliwe. Jednak autorzy zachęcają do próby, gdyż zmiany nie muszą być wcale rewolucyjne. Małymi krokami można zmieniać kierunek uwagi Zespołu i odzyskać utracone wcześniej szanse.

Można zacząć od działań takich jak: zmiana sposobu myślenia o wykonywanej pracy (z myślenia o wykonywaniu pracy, na dostarczanie wartości); pomyślenie o kontekście za każdym razem, gdy rozwiązujemy problem; postawienie Użytkownika końcowego w Centrum naszej uwagi.

Gorąco polecam przesłuchanie webinarium (Tomasza się świetnie słuchało, ma on niesamowitą płynność i swobodę mówienia o temacie). Wiedza oparta o analizę danych przekazana jest w przystępny sposób. Na koniec przekazane są rekomendacje, co możemy zrobić jako Liderzy i jako członkowie Zespołu. Cały przekaz pokazuje, co powinno być istotne, jeżeli chcemy osiągnąć sukces ze swoim Produktem.

Bibliografia

[1] The Continuous Hunt for Value – The Unfortunate Reality for Many Scrum Teams; https://www.scrum.org/resources/continuous-hunt-value-unfortunate-reality-many-scrum-teams

[2] In pursuit of value—not work; https://scrumorg-website-prod.s3.amazonaws.com/drupal/2022-10/in-pursuit-of-value-not-work_final.pdf

[3] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *