Wiele osób trzyma się “swojej wersji Scruma”. Po ostatniej aktualizacji podręcznika, część z nich zaczęła głośno mówić o tym, co robią inaczej i jak to pasuje (bądź nie) do zmian. Są to ciekawe, ale w dużej mierze bezcelowe dyskusje.
#scrum25
Przy okazji ostatniej aktualizacji Scrum Guide pojawiło się wiele dyskusji na temat interpretacji i rozumienia Scruma. Tematem zmian w podręczniku, tego co wnoszą w nasze życie oraz jak bardzo i co musimy zmienić zajmiemy się jak już opadnie kurz, czyli w grudniu tego roku. Teraz piszą i mówią o tym wszyscy i robi się straszny szum informacyjny.
Żeby jednak nie pozostawać bez komentarza do wspomnianych zmian, pokuszę się o dosłownie trzy zdania. Po pierwsze, dla osób które czuły intencje autorów i miały dobry agile mindset, zmieni się niewiele. Wciąż w Scrumie chodzi o to samo. Po drugie, pojawiło się parę nowych elementów, które wymagają omówienia i komentarza (jak np. Product Goal). Zajmiemy się tym niedługo.
Przewrotnie jednak zaczniemy od tego, co powtarzamy od zawsze. Scrum Guide to nie jest święta księga, a my nie jesteśmy mnichami studiującymi jakieś starożytne zapisy. Nie mamy też żadnych ceremonii Scrum.
Ewengelizacja Scrum
Jako #białko nie jesteśmy ewangelizatorami Scrum. Powtarzamy to od samego początku naszej działalności. Co nie znaczy, że nie zalecamy trzymania się podręcznika. Ale, dzięki temu, że nie jesteśmy związani z żadną organizacją wydającą certyfikaty Scrum, możemy otwarcie mówić to, co naprawdę myślimy. I gdy widzimy, że coś nie działa, to zawsze to pokazujemy mówiąc coś w stylu “Scrum Guide mówi tak, ale z naszego doświadczenia wychodzi trochę inaczej.”
Idealnym przykładem była konieczność dodawania przynajmniej jednego usprawnienia, zidentyfikowanego w trakcie Sprint Retrospective do Backlogu następnego Sprintu. Tu już nawet nie chodzi o to, że nikt tego nie robił, ale o pozostałe problemy. Dlaczego tylko jedno, a nie wszystkie? Dlaczego do Sprint Backlogu? Co jest złego z trzymaniem usprawnień na osobnej liście?
I tu wracamy do tego, od czego zacząłem. Jeżeli dobrze rozumiemy intencję autorów i to, po co jest Scrum, to kolejne iteracje Scrum Guide niewiele nam zmienią. W najnowszej aktualizacji jest napisane, że najważniejszymi rzeczami zidentyfikowanymi na retro powinniśmy się zająć jak najszybciej i możemy (ale nie musimy) dodać je (wszystkie) do Backlogu Sprintu.
Nie mam zamiaru tutaj krzyczeć “A nie mówiłem!”, tylko powtórzę “Jeżeli wiesz, czemu służą niektóre zapisy, nie ma nic złego w tym, aby zrobić coś inaczej. Ważne, żebyś osiągnął cel.” Tylko, że to rodzi dyskusje dotyczące interpretacji.
Daily i Trzy Pytania
Ponieważ po aktualizacji podręcznika rozgorzało mnóstwo dyskusji i interpretacji, pozwolę sobie wybrać jeden z tematów, który mamy całkiem niezłe pokryty zarówno w sferze tekstów jak i filmów. Mowa o Daily Scrum.
Niektóre osoby z radością przyjęły “dopuszczenie” Product Ownera do Daily. Nowe zapisy mówią “The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, (…) If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.” i w swojej idei niczym nie różnią się od starych.
“Po staremu”, na Daily miało nie być osób przeszkadzających. Uważny Scrum Master, nawet stojąc z boku może zauważyć, czy obecność Product Ownera nie zmienia Daily w spotkanie statusowe. Jeżeli PO pojawiając się zaburza jego przebieg, nie jest na nim mile widziany.
Tak było i wcześniej, i tak jest teraz.
Jeżeli rozpiszemy wszystkie rzeczy do wykonania w ramach elementów backlogu wybranych do Sprintu, to jedno proste pytanie powie nam o tym, czy PO powinien pojawić się na Daily. Pytanie to brzmi, “Czy którąkolwiek z tych rozpisanych rzeczy będzie wykonywał PO?” Jeżeli tak, to jest Developerem i jak najbardziej niech się na Daily pojawi. Jeżeli nie, nie jest na nim potrzebny.
Kontrargumenty zwykle mówią o tym, że PO na Daily dowiaduje się, jaki jest status prac albo wyjaśnia co jest do zrobienia w backlogu. Tylko, że Daily w ogóle nie do tego służy! Jest ono od ustalenia planu prac na najbliższy dzień! Obecność PO odsuwa zespół od najważniejszego i przerabia to w spotkanie statusowe. Źle. Robienie refinementu na Daily to też jakaś patologia.
Mój Scrum, mój własny…
Dyskusje po aktualizacji Scrum Guide są o tyle ciężkie, że w wielu przypadkach osoby, z którymi się rozmawia “wiedzą lepiej”. Mają one swój ScrumBut, którego się trzymają i w którym modyfikują podstawowe aspekty.
Chociaż sami nie jesteśmy ewangelizatorami, to nie dlatego, że “wiemy lepiej”. Z naszego doświadczenia wychodzi, że czasami coś się nie sprawdza albo można to zrobić lepiej. Ale zawsze mówimy o innych sposobach dojścia do tego samego celu, który w podręczniku jest precyzyjnie określony w każdym przypadku.
Wracając do Daily – jego celem jest zaplanowanie sobie przez Deweloperów następnego dnia wspólnej pracy. I w czasach, gdy słynne “trzy pytania” jeszcze były obowiązkowe, nie widzieliśmy wartości dodanej z odpytywania każdego do znudzenia z tego samego. Więc odradzaliśmy ich używanie, transparentnie mówiąc, że Scrum Guide mówi inaczej. Bo ciągle chodziło o to, żeby się zaplanować. Nie zmienialiśmy celu wydarzenia, ale jego formułę.
Tymczasem osoby zapraszające PO na Daily i robiące z niego status albo refinement zmieniają jego cel. To nie jest “tuning Scruma”, to jest poważna zmiana, która powoduje, że inne aspekty procesu przestają działać poprawnie. Patrz: Broken Window Theory.
Tak więc skoro ktoś się decyduje na zmianę podstaw, celu poszczególnych wydarzeń, odpowiedzialności ról, to dlaczego taka osoba w ogóle się przejmuje zmianami w Scrum Guide? Przecież i tak nie trzyma się podręcznika, co ją zmiany w ogóle obchodzą?
Nas obchodzą, bo chcemy zajmować się Scrumem, a nie czymś do niego podobnym. Ale możecie być pewni, że jeżeli zauważymy, że coś nie działa albo można zrobić lepiej, to Wam o tym powiemy. Zachowując pełną transparentność, usłyszycie od nas nieśmiertelne “Podręcznik Scrum mówi tak, ale z naszego doświadczenia…”
I tych lepszych doświadczeń Wam życzymy. Dość teoretyzowania, zajmijmy się Scrumem w praktyce.
