Zdarza mi się trafiać na komentarze, których autorzy wskazują jak bardzo wybrakowanym procesem jest Scrum.
Szczególnie punktowany jest fakt, że Scrum całkowicie pomija obszar związany z zarządzaniem produktem. Że nie definiuje czym dokładnie jest ta cała „wartość”. Że całkowicie pomija fazę odkrywania pomysłów na rozwój. Nie mówi nic o definiowaniu nowych obszarów. Ba, nie ma w nim nawet słowa o długofalowym planowaniu, o road mapach, a nawet – (skandal!) nie ma nic na temat wizji produktu.
I to wszystko, by podkreślić jak bardzo ten cały Scrum jest dziurawy.
A mi te komentarze podnoszą ciśnienie, bo bardzo się z nimi nie zgadzam ?
Celowo niekompletny
Alright, stop!
Zatrzymajmy się na moment.
Zacznijmy od tego, że Scrum:
… jest celowo niekompletny, definiuje jedynie elementy wymagane do wdrożenia teorii Scruma. Scrum opiera się na inteligencji zbiorowej jego użytkowników. Zamiast dawać ludziom szczegółowe instrukcje, reguły Scruma pozwalają kształtować wzajemne relacje i interakcje
Czyli w skrócie – sięgając po Scruma, nie otrzymasz szczegółowych instrukcji jak zarządzać organizacją czy produktem. Definicje Scruma mogą pomóc wcielić w życie wartości i zasady Manifestu, tak – by dostarczać działające i wartościowe rozwiązania.
Wychodząc od założenia, że ludzie i ich interakcje są ważniejsi niż procesy i narzędzia. A procesy i narzędzia powinny wspierać ludzi w ich interakcjach. I tak właśnie jest w przypadku procesów scrumowych. Choć to oczywiście nie jedyna wartość Manifestu, którą w Scrum wciela w życie.
I tu mógłbym postawić kropkę. Ale jedźmy dalej.
Różnorodne procesy
W Scrumie można stosować różnorodne procesy, techniki i metody.
Scrum obejmuje istniejące praktyki lub sprawia, że stają się zbędne.
Czyli: zwrócenie się w kierunku Scruma nie oznacza, że nie wolno nam korzystać z żadnych innych praktyk czy procesów. Że jeśli o jakichś praktykach nie ma ani słowa w przewodniku po Scrumie, to nie wolno nam z nich korzystać.
Jeśli miałeś do tej pory jasny sposób na product discovery, stosowałeś do tej pory roadmapy, posiadałeś jasną i klarowną wizję produktu to sięgając po Scruma nie musisz wyrzucać tych standardów do kosza.
Wręcz przeciwnie. Autorzy frameworka dostrzegają, że Scrum „znajduje zastosowanie w wielu dziedzinach, w których do wykonania są złożone zadania, także poza obszarem rozwoju oprogramowania”. Dlatego, z każdą kolejną aktualizacją reguł gry, Scrum staje się on coraz bardziej uniwersalny. Zostawiając przestrzeń na wykorzystywanie praktyk adekwatnych do specyfiki naszej pracy.
Autorzy celowo nie definiują, ani nawet nie rekomendują konkretnych narzędzi czy metod. Bo każda branża i każda organizacja ma inne wyzwania i inne potrzeby. A za pomocą empirycznego procesu możemy odkrywać to, co dla nas jest użyteczne i przydatne.
I tu mógłbym postawić kropkę. Ale jedźmy dalej.
Maksymalizowanie wartości
Product Owner ponosi odpowiedzialność za maksymalizowanie wartości produktu (…). Sposób, w jaki to robi, może znacznie się różnić w zależności od organizacji (…).
Product Owner maksymalizuje wartość produktu między innymi poprzez sprawne zarządzanie Product Backlogiem. Czyli ustalanie takiej kolejności jego elementów, by na szczycie tej uporządkowanej priorytetami u góry listy znajdowało się to, co w kolejnej iteracji przyniesie najlepszy zwrot z inwestycji.
Product Backlog wprowadza transparentność w komunikowaniu najbliższych zmian w produkcie. To co znajduje się na jego szczycie jest tym, nad czym w kolejnych iteracjach będzie pracował zespół Scrumowy.
Ale… skąd biorą się elementy Product Backlogu? A w jaki sposób zamieniane są w przyrost?
Ustalmy jedną rzecz
Scrum nie definiuje tego, jak poszczególni członkowie w zespole mają wykonywać swoją pracę.
Scrum jako proces stwarza przestrzeń dla przejrzystości, inspekcji i adaptacji. Sprawia, że to nad czym pracujemy staje się widoczne. Daje miejsce do regularnej weryfikacji czy obrane kierunki są właściwe. A jeśli nie – daje miejsce do wprowadzenia korekt tak szybko, jak tylko to możliwe. By koszt usunięcia strat lub defektów był jak najniższy.
Ale…
Scrum nie określa w jaki sposób Developerzy mają wykonywać swoją pracę. Scrum nie określa w jaki sposób Scrum Master wpływa na efektywność zespołu Scrumowego. Scrum nie określa dokładnie w jaki sposób Product Owner maksymalizuje wartość produktu.
Bo każda z osób pełniących powyższe odpowiedzialności posiada swój zestaw praktyk, narzędzi i procesów, które pomagają dostarczać wartość organizacji i pozostałym członkom zespołu.
W przypadku Product Ownera tymi praktykami, narzędziami i procesami jest cały obszar z zakresu zarządzania produktem. Jeśli chcesz dowiedzieć się więcej na temat tego obszaru, to aktualnie chyba nie ma lepszego miejsca w sieci niż stworzona przez Pawła Huryna lista.
Scrum temu winny?
A jeśli w Twojej organizacji brakuje procesów związanych z zarządzaniem produktem, to…
Może to nie wina Scruma? Może to jego zasługa?
W końcu, przecież…
Scrum unaocznia względną skuteczność dotychczasowego zarządzania, środowiska, technik pracy, aby umożliwiać wprowadzanie usprawnień.
SM jako nauczyciel
Czy wiesz, że o jakość stosowanych praktyk, procesów i narzędzi w zespole Scrumowym odpowiedzialny jest Scrum Master?
Osoba pełniąca tą odpowiedzialność powinna swobodnie czuć się między innymi w rolach nauczyciela, mentora i coacha. I za pomocą tych wcieleń szerzyć zwinne praktyki nie tylko w zespole z którym współpracuje, ale również w całej organizacji.
A czy wiesz, że w mojej ofercie posiadam również indywidualny mentoring dla Scrum Masterów?
Zainteresowałem? Odezwij się i znajdźmy przestrzeń do współpracy ?♂️
Wszystkie użyte w tekście cytaty pochodzą z polskiej wersji Scrum Guide’a.