Scrum Guide 2017 – zmiany okiem młodego Scrum Mastera

Wczoraj Jeff Sutherland i Ken Schwaber ogłosili kilka niewielkich choć ciekawych zmian do Scrum Guide’a. Chciałbym napisać parę słów o trzech z nich, które będą mieć moim zdaniem, duży wpływ na postrzeganie Scruma w dłuższej perspektywie.

Daily Scrum i trzy pytania

„The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?”

Jestem pewien, że w tym momencie tysiące developerów odczuło ulgę. Nigdy więcej mechanicznego odpowiadania na pytania podczas Daily jak na spowiedzi.

Bardzo się cieszę z tej zmiany, bo faktycznie sporo zespołów skupiało zbyt dużą uwagę na tym, aby każdy odpowiedział na wszystkie trzy pytania, zamiast tego, aby każdy rozumiał, co jako zespół zrobiliśmy od wczoraj, jaki jest plan na dzisiaj i jakie są przeszkody w osiągnięciu Celu Sprintu.

Choć pytania zostały, to są one przedstawione nie jako wymaganie, a jedynie jako propozycja, jedna z wielu technik w jaki sposób można realizować Daily Scrum.

Myślę, że w dłuższej perspektywie, ta modyfikacja będzie miała bardzo pozytywny wpływ na postrzeganie Scruma, przede wszystkim przez developerów.

Akcje z retro w Sprint Backlogu

„The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

Dobry zespół, pracujący w duchu kaizen, zapyta „ale gdzie ta zmiana, przecież my tak robimy od zawsze?”. Zgadza się, wdrażanie w życie akcji z retrospekcji wydaje się naturalne i intuicyjne… choć jak się okazuje niekoniecznie dla wszystkich. Kilka razy spotkałem się z opinią, że Scrum nic nie zmienia albo że nawet nie pretenduje do tego, aby cokolwiek usprawnić. Zamiast tego konserwuje status quo, a zespoły sprintując, tylko kręcą się szaleńczo w kołowrotku jak chomiki, a koniec końców ulegają wypaleniu.

Drążąc temat, często okazywało się, że za tą opinią kryje się lekceważenie retrospekcji jako okazji do inspekcji i adaptacji („mamy retro, ale raczej gadamy o tym co poszło ok a co nie, nie planujemy propozycji usprawnień„) ale jeszcze częściej brak konsekwencji i przede wszystkim planu na wdrożenie usprawnień w kolejnym Sprincie („zidentyfikowaliśmy akcje, ale nie było na nie czasu”). Wraz z powyższą zmianą do Scrum Guide’a, zespół Scrumowy będzie zobowiązany uwzględnić w Sprint Backlogu co najmniej jedno usprawnienie, a tym samym zarzut, że Scrum nawet nie stara się czegokolwiek usprawnić  zostaje formalnie zaadresowany. Oczywiście może paść inny zarzut, o zbytnią preskryptywność (autokorekta szaleje, choć dam sobie rękę uciąć, że jest takie słowo), ale trudno, wszystkim marudom się nie dogodzi.

Zapewne pojawią się też dwa rodzaje pytań:

  • Czy umieszczenie usprawnienia w Sprint Backlogu oznacza utworzenie nowego PBI’a? A może sub-taska w JIRZE? Albo przyklejenie karteczki na ścianę?
  • Co z usprawnieniami, które nie są związane bezpośrednio z inkrementem np. jakaś zmiana w procesie lub aspekty interpersonalne? Czy też powinny trafić do Sprint Backloga?

Moim zdaniem ma to drugorzędne znaczenie i powinno wyjść w praniu każdorazowo podczas planowania. Dużo ważniejsze jest aby podczas Sprint Planningu zespół zarezerwował trochę czasu i zaplanował wprowadzenie tego usprawnienia. W końcu Sprint Backlog to nie tylko worek na PBI’e ale również plan na najbliższy Sprint.

„The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.”

Kompetencje Zespołu Developerskiego

„Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis”

Tutaj de facto nic się nie zmienia, a modyfikacja może wynikać z pewnego nieporozumienia związanego z tym jak Scrum ma się do kultury DevOps (albo raczej DevOps do Scruma). Scrum od zawsze postulował, że Zespół Developerski powinien mieć wszystkie kompetencje potrzebne do stworzenia i utrzymania produktu, a zatem nigdy nie był sprzeczny z tym co dziś głosi ruch DevOps. Ken Schwaber bardzo ciekawie opowiedział o tym w webinarze na temat zmian do Scrum Guide’a https://youtu.be/WVSQkU5VaC8?t=41m46s

Niestety bardzo często jako Zespół Developerski rozumie się wciąż jedynie grupę programistów, testerów i jeśli dobrze pójdzie to również analityków. Kompetencje oraz osoby odpowiedzialne za architekturę, infrastrukturę i utrzymanie znajdują się poza zespołem i jeśli są dostępne to tylko ad-hoc. Nierzadko, w większych firmach, tak skonstruowany Development Team jest również całkowicie odcięty od produkcji, a releasem zajmuje się osobny zespół, z którym trzeba przerzucać się ticketami (tak jak do niedawna programiści przerzucali się nimi z testerami). Jak w takiej sytuacji wygląda poczucie ownershipu za produkt? No właśnie, tak jak na animacji poniżej. Dlatego postrzegam tę małą zmianę jak duży krok w odczarowywaniu pewnych mitów, które narosły wokół Scruma.

„Nie działa na produkcji?”

 

 

 

 

 

 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *