Zainspirowana głosami, że rola Scrum Mastera kiedyś była kompletnie inna, zaczęłam wczytywać się w pierwszą wersję Scrum Guide’a z 2010 roku. Jednak w trakcie lektury uderzyło mnie co innego. Coś, czego w aktualnym Przewodniku po Scrumie już tak bardzo nie widać, ale zdałam sobie sprawę, że nadal jest to fundament idei Scruma. Widzę też obecnie wiele wyzwań z tym związanych. O co chodzi? Jedna rzecz najbardziej zwraca uwagę: obsesyjne skupienie na zespole, który wytwarza produkt lub usługę. 

Scrum? tak, ale dla zespołu wytwórczego

W kontekście pierwszej wersji Przewodnika warto wspomnieć o roli Scrum Mastera. W 2010 roku stał on zdecydowanie po stronie zespołu wytwórczego a nie równoważnie pomiędzy Zespołem i Product Ownerem. Można było nazwać go wysłannikiem zespołu developerskiego. Był odpowiedzialny za wyszukanie, wskazanie i odpowiednie przeszkolenie potencjalnego Product Ownera z zasad Scruma. Scrum Master był rozliczany z tego, czy Product Owner w ogóle jest, oraz czy jest odpowiednio przygotowany do swojej roli. PO był zatem raczej biernym uczestnikiem całego zamieszania, dostosowywał się do potrzeb i wymagań zespołu wytwórczego.

The ScrumMaster works with the customers and management to identify and instantiate a Product Owner. The ScrumMaster teaches the Product Owner how to do his or her job, in order to optimize the value of the use Scrum. If they don’t, the ScrumMaster is held accountable.

Scrum Guide, 2010

Potrafię sobie to wyobrazić. Zespół wytwórczy ma do wykonania pewną pracę. Podporządkowuje sobie zatem, z pomocą Scrum Mastera, wszystkie możliwe okoliczności i otoczenie pod swoje potrzeby. Co w jakimś sensie jest dla mnie uderzające, to wrażenie, że głównym celem Scruma na samym początku nie był przede wszystkim produkt, ale święty spokój zespołu wytwórczego. PO był do dyspozycji zespołu i realizował takie funkcje, które temu zespołowi służyły. Ewidentnie Scrum był frameworkiem z ramienia IT, w którym w kontrolowany sposób wtłaczano klienta, aby ułatwić życie programistom. Biznes był tylko inkubatorem, dodatkiem, gościem, nie współtwórcą. Cwane, cwane!

O języku w Przewodniku z 2010

Niezbyt skomplikowana analiza semantyczna wersji Scrum Guide’a z 2010 tylko potwierdza powyższe. Na ponad 60 przypadków użycia słów „The Team” było o połowę mniej przypadków użycia słów „Product Owner” lub „Scrum Master”. Czasowniki używane przy PO i ZD również pokazują, kto grał tu pierwsze skrzypce.

Zespół: może zmienić, dodaje, modyfikuje, planuje, identyfikuje, może zarządzić, robi przegląd, ma na myśli, samoorganizuje się, zdaje sobie sprawę, zaprasza, determinuje, dochodzi do wniosku, zaczyna, buduje, optymalizuje, grupuje, zaznacza, wykonuje pracę, angażuje się, spotyka się, rozmawia, ma ostatnie zdanie, ma granice tolerancji. Wcześniejsze zakończenie sprintu TRAUMATYZUJE zespół wytwórczy. Brzmi jak odniesienie się do żywego, uczestniczącego, reagującego na otoczenie organizmu.

W międzyczasie Product Owner jest „oficjalnie odpowiedzialny”, „to jest osoba, która”: utrzymuje, zapewnia, wyjaśnia, zarządza artefaktem, odpowiada za aktualizację listy wymagań, prezentuje, jest dostępna, musi zrozumieć, jeśli zespołowi nie uda się czegoś dostarczyć. Jeśli zespół nie jest w stanie czegoś zrobić, PO powinien zrozumieć. W końcu liczy się komfort zespołu. Brzmi przedmiotowo do potęgi.

I muszę przyznać, że o ile w wersji z 2017 zarówno PO, jak i SM to już dwie dojrzałe role posiadające autonomię, mające więcej wolności, szacunku, zaufania, przestrzeni, nadal Scrum skupia się przede wszystkim na zespole wytwórczym. Dokument rozrasta się niemal wyłącznie w jednym kierunku.

My, wy i wasz Scrum

Scrum zaczynał jako framework czysto wytwórczy i do dziś mierzy się, mam wrażenie, z tego konsekwencjami. Nie umie być w naturalny sposób przyjazny biznesowi. Nie wspiera go wystarczająco, choć i tak robi to już w większym stopniu niż dekadę temu. Dlatego, mam wrażenie, po stronie biznesu traktowany jest często po macoszemu. Jako że bannerem Agile’a w biznesie jest właśnie Scrum, to całemu konceptowi myślenia zwinnego dostaje się rykoszetem. „Mamy Scrum Masterów, jesteśmy Agile, bo IT tak chce. Dajcie nam już spokój”. Wynika to być może z przekonania, jakoby Scrum był ramą czysto techniczną. To jest coś, co IT robi biznesowi. Scrum Masterzy są przecież zatrudniani głównie w IT. Znam kierowników, którzy do swoich SM-ów mówią: „jesteś z IT, pracuj z zespołem wytwórczym a nie z biznesem”. Mam jednak nadzieję, że będę to słyszeć coraz rzadziej.

Powyższe dotyczy dekady wstecz, a zeszłoroczny raport Scrum Master Trends pokazuje, że w 2019 roku Scrum nadal uznawany był za ramy postępowania narzucane biznesowi przez IT a nie te wynikające ze wspólnej pracy IT i biznesu nad rozwojem produktu. Co poszło nie tak? Czyżby za słaby marketing, żeby mimo wszystko Scrum usadowił się stabilnie po obu stronach w imię wspólnej pracy nad produktem czy usługą, a nie tylko wychylał się przez okno do klienta z piwnicy zawalonej kartonami, serwerami i wybrakowanymi meblami?

Co zrobić, aby to zmienić?