Blog

7 listopada ukazała się nowa wersja Scrum Guide – podstawowego dokumentu metody Scrum autorstwa Kena Schwabera i Jeffa Sutherlanda. Najważniejsze zmiany to podkreślenie, że Scrum jest używany nie tylko do tworzenia oprogramowania, wyjaśnienie że produkt można wydawać częściej niż raz na sprint oraz uczynienie „trzech pytań” na Daily opcjonalną praktyką.

Poniżej pełna lista istotnych zmian:

• Dodanie rozdziału podkreślającego iż Scrum jest używany także w innych dziedzinach niż tylko rozwój oprogramowania, głównie chodzi tu o rozwój i utrzymanie różnego rodzaju produktów.

• Rezygnacja z „trzech pytań” jako wymaganego metodą formatu spotkania Daily Scrum – zmiana ta wynikła z obserwacji, że w wielu miejscach spotkanie to zaczęło być traktowane jako rytuał, który należy wypełniać by „robić Scrum” przy braku zrozumienia sensu Daily Scrum jako codziennej empirycznej inspekcji i adaptacji zespołu w jego pracy nad osiągnięciem Celu Sprintu. Twórcy Scrum mają nadzieję, że określenie „trzech pytań” jako dobrej ale nie jedynej praktyki pomoże w upowszechnieniu lepszego zrozumienia sensu tego spotkania. Dodatkowo wyjaśniono, że Daily Scrum to wewnętrzne spotkanie Development Team, jeśli są na nim obecne inne osoby Scrum Master ma dopilnować, że nie zaburza to (ang. *disrupt*) Daily.

• Podkreślenie, że fundamentem Scrum jest nieduży zespół, elastyczny i dostosowujący się.

• Wyraźne zapisanie, że działająca wersja prodktu (*„Done” increment*) musi być gotowa przed rozpoczęciem Przeglądu Sprintu.

• Podkreślenie, że na Przeglądzie mamy inspekcję przyrostu a nie jego „akceptację”.

• Zmiana opisania roli Scrum Mastera – podkreślenie, że Scrum Masterzy mają promować i wspierać Scrum takim, jakim jest on zapisany w Scrum Guide oraz wyjaśnienie, że mają to robić przede wszystkim poprzez pomoc innym w zrozumieniu Scruma. Dodatkowo rozszerzono opis co Scrum Master robi dla PO, zespołu i reszty organizacji – ważne dodatki to podkreślenie, że Scrum Master powinien umieć zaplanować wprowadzanie Scruma w organizacji oraz współpracować z innymi obecnymi w niej Scrum Masterami nad ulepszaniem efektywności i jakości Scruma w niej.

• Podkreślenie, że Retrospekcja powinna być pozytywna i produktywna – skutkować podejmowaniem przez zespół działań usprawniających. Temu ostatniemu celowi służy również zapisanie, że co najmniej jedno konkretne działanie usprawniające z retrospekcji ma bezpośrednio trafić do Backlogu Sprintu w kolejnym sprincie. Podkreślono także, że Scrum Master uczestniczy w retrospekcji jako członek zespołu – nie jest zewnętrznym, obojętnym facylitatorem lecz uczestniczy w dyskusji.

• Backlog Produktu zawiera tylko takie funkcje, co do których na tą chwilę wiemy, że będą potrzebne w produkcie (dotychczas było iż wiadomo, że mogą być potrzebne).

Zmiany idą zatem w tym samym kierunku co zeszłoroczne – uczynienia Scruma jeszcze mniej dyrektywnym i bardziej skupionym na empiryzmie w praktycznej pracy zespołowej.

Zapraszam też do obejrzenia webinaru poświęconego zmianom w nowej edycji Scrum Guide.