Scrum Guide 2020 - jeszcze bliżej biznesu
Słowem wstępu
Początki Scruma sięgają lat 90-tych, a pierwsza wersja Scrum Guide’a została opublikowana w 2010 roku. Z biegiem lat zyskiwał coraz większą popularność m.in. w branży IT. Wraz z jego coraz szerszym stosowaniem, ewoluował i adoptował się do zmieniającej się rzeczywistości, a także naszych potrzeb. W wyjątkowym 2020 roku pojawiła się jego kolejna, już piąta odsłona. Co nowego Scrum ma dziś do zaoferowania i co się w nim zmieniło? Rzućmy okiem na framework, który nie bez powodu ma miano “Easy to learn, Hard to master”.
[info] Jeżeli nie miałeś jeszcze do czynienia ze Scrumem i pojęcia, które pojawią się poniżej są Ci obce, zachęcamy do przeczytania innego naszego artykułu, który wprowadzi Cię w Scruma i jego rolę w procesie tworzenia oprogramowania. Gorąco zachęcamy do zajrzenia tutaj.
Co nowego?
Product Goal
Cel produktu (Product Goal) to zupełnie nowe pojęcie, które wprowadza Scrum Guide 2020. Dotychczas jedynym celem, który definiował Scrum Team był cel sprintu (Sprint Goal).
Pojawienie się celu produktu umieszcza Scrum Team (o, którym więcej poniżej) jeszcze bliżej biznesu. Dzięki niemu jesteśmy w stanie określić cel, jaki chcemy osiągnąć realizując kolejne, pomniejsze cele sprintu. Pokazuje szerszą perspektywę i wzbudza większą świadomość tego, na jakim etapie jesteśmy w jego osiągnięciu.
Podobnie, jak w przypadku Sprint Goal, Product Goal w danym momencie powinien być zdefiniowany wyłącznie jeden. Dopiero po jego osiągnięciu możemy rozpocząć pracę nad kolejnym.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Dodanie celu produktu uporządkowuje również kwestię artefaktów scrumowych. Każdy z nich posiada obecnie swoje “zobowiązanie”. Dla Przyrostu (Increment) jest nim Definition of Done, dla Sprint Backlogu to Sprint Goal, a dla Product Backlogu jest nim Product Goal.
Trzy pytania na Sprint Planningu: Why, What, How
Wprowadzenie wyżej wymienionego pojęcia jakim jest Product Goal oraz jego implikacje na pozostałe elementy mające miejsce w Scrumie to wielki ukłon w stronę świata analizy biznesowej ;). Już od dawna Analitycy Biznesowy męczą swoje zespoły jak również Product Ownerów (PO) o udzielenie odpowiedzi na pytanie Why?. Dotychczas w trakcie planowania kolejnych Sprintów skupiano się bardziej nad tym What? będzie realizowane, a następnie Deweloperzy odpowiadali na pytanie How? będzie to realizowane. Wyraźne zaznaczenie pytania Why? wydaje się naturalnym krokiem ponieważ już od wielu lat funkcjonuje ono m.in. w trakcie zdobywania wymagań poprzez technikę znaną jako...5 why’s. Również osoby, które stosują opisywanie wymagań wykorzystując User Stories wiedzą, że pytanie Why? jest bardzo istotną częścią opisu ponieważ pozwala poznać zysk jaki osiągnie wymieniony na początku historyjki użytkownik. Skupiamy się nad tym dla kogo ma być i co ma być zrealizowane i co dzięki temu osiągniemy. Niestety bardzo często ten fragment jest pomijany, nie wiedząc czemu, ale dzięki zmianie w najnowszym Scrum Guide już nie będzie wymówek do takiego działania. Dodatkowym plusem tak niewinnie brzmiącego pytania ma ogromną moc sprawczą, ponieważ pozwala Deweloperom poznać wartość biznesową danej funkcjonalności lub konkretnego User Story, czyli pięknie odwołuje się do jednej z 7 principles of Agile Business Analysis jaką jest See the whole. W ręce Deweloperów trafia potężne oręże do poznania tak naprawdę business need danego zadania, a nie tylko skupienia się nad jego stroną technologiczną.
Czym dokładnie jest business need można przeczytać tutaj:
https://tsh.io/blog/user-stories-business-needs-software-development/
Why? wymusza również na PO przeprowadzenia procesu analyze to determine what is valuable przed umieszczeniem danego elementu w Backlogu, który czasem stosowany jest jak lista życzeń, które nie zostaną nigdy zrealizowane. Jest to kolejny ukłon w stronę świata Analizy Biznesowej ponieważ o takim podejściu wspomina m.in organizacja IIBA w Agile Business Analysis.
Co się zmieniło?
Krótszy Scrum Guide
To, co przede wszystkim rzuca się w oczy, to objętość nowego Scrum Guide’a. Poprzednia wersja liczyła 19 stron, nowa tylko 13 - to ponad 30% mniej treści. Skąd ta różnica? Przede wszystkim zrezygnowano z pewnych zbędnych i złożonych instrukcji, a także z pytań na Daily Scrum. Skrócono sekcję dotyczącą anulowania Sprintu - wcześniej poświęcony był jej cały podrozdział, teraz dosłownie dwa zdania:
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
Sam język stał się mniej normatywny, a nowa forma daje większe pole do elastyczności i dostosowania Scruma dla własnych potrzeb.
Można pomyśleć, że twórcy dążyli do osiągnięcia minimalizmu w treści przy jednoczesnej maksymalizacji kluczowych wartości.
Brak pytań na Daily Scrum
Według nas to dość ważna zmiana. Forma trzech pytań (o której więcej możecie przeczytać w https://tsh.io/blog/perform-effective-daily-scrum/) odnoszących się do pracy danego dewelopera nie zawsze dawała satysfakcjonujące efekty. Z naszego doświadczenia podczas Daily Scrum często skuteczniejsze jest przejście przez wszystkie zadania będące elementem Sprint Backlogu i śledzenie ich postępu. Dzięki temu łatwiej zorientować się na jakim etapie od osiągnięcia Sprint Goalu jest zespół. Warto mieć na uwadze, że brak z góry narzuconej formy pozwala eksperymentować i dostosować Daily Scrum do potrzeb zespołu.
Scrum Guide jednocześnie podkreśla, że śledzenie postępu w osiągnięciu Sprint Goal powinno odbywać się cały czas, a nie tylko podczas Daily Scrum, szczególnie gdy Scrum Team dostrzega pewne zagrożenia. Powinien niezwłocznie o tym poinformować, a nie czekać do kolejnego Daily Scrum.
Wyraźne zaznaczenie Definition of Done
Jak już zostało wspomniane w “Co nowego?”, Definition of Done stało się “zobowiązaniem” dla Przyrostu. Oznacza to, że Definition of Done jest pewnego rodzaju standardem, którego osiągnięcie równoważne jest z dostarczeniem odpowiedniej jakości Przyrostu. Definition of Done zapewnia przejrzystość, gwarantując wszystkim wspólne zrozumienie tego, co dokładnie zostało wykonane. Niezwykle ważne jest, aby wszystkie elementy Sprint Backlogu spełniały założone Definition of Done. W tej kwestii nie ma wyjątków. Przykładem może być poniższa lista:
Code review is done
Functionality is implemented and tested
Test scenarios for functionality are prepared
Task is in DONE column
Code is deployed and available on staging environment
Jeżeli Definition of Done zostało zdefiniowane jako standard w całej organizacji, powinniśmy zachowywać go w każdym produkcie. Wpływa to na większą transparentność wśród wszystkich zespołów i ułatwia pracę nad różnymi produktami. Świadczy to również o dojrzałości całej organizacji i świadomym podejściu w stosowaniu Scruma. Myślę, że jest to niezwykle istotne dla naszych potencjalnych klientów. Dzięki tej świadomości i dojrzałości, możemy tworzyć produkty o najwyższej jakości.
Wyraźne zaznaczenie Sprint Goal
Jak podaje Scrum Guide: Sprints are the heartbeat of Scrum, where ideas are turned into value. I lepiej tego nie można by napisać. Niemniej jednak aby Sprint przyniósł jakąś wartość i przybliżył nas do osiągnięcia Product Goal musimy sobie ustalić Sprint Goal. Powstaje on w trakcie pierwszego spotkania jakie ma miejsce na rozpoczęcie Sprintu czyli Planningu. W trakcie tego spotkania Zespół Scrumowy musi odpowiedzieć na wcześniej już omówione pytanie - Why?, a dokładniej na Why is this Sprint valuable? W celu odpowiedzi na tak postawione pytanie musimy przejść przez pewien proces, który cytując Scrum Guide, wygląda następująco: The Product Owner proposes how the product could increase its value and utility in the current Sprint. Następnie, co bardzo istotne the whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Co równie istotne Sprint Goal powinien zostać podany do końca Planningu. W swojej karierze miałem przyjemność pracować w Zespołach, gdzie pilnowaliśmy tego procesu, co ułatwiało priorytetyzację zadań w Sprincie, niestety nie wszędzie jest to regułą. Co bardzo istotne, to to, że Sprint Goal może być przyczyną przerwania Sprintu, gdy okaże się on już nieaktualny.
Inne nazewnictwo zespołu
W nowym Scrum Guide postanowiono wyraźnie zaznaczyć nowe nazewnictwo oraz podział odpowiedzialności w zespole. W miejsce Dev Team pojawił się Scrum Team. W tej chwili pod pojęciem Scrum Team ukryci są: one Scrum Master, one Product Owner, and Developers. Nie zmienił się koncept odnośnie członków zespołu. W dalszym ciągu zespoły te powinny składać się z niewielkie ilości osób, najlepiej ok. 10 członków, być cross-functional - posiadające wszystkie umiejętności do ukończenia zadanych prac oraz self-managing - niezależne w decydowaniu kto, kiedy, jak i za co odpowiada.
Kolejną nową nazwą jest Developers, która oznacza the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. Scrum Guide nie opisuje jakimi konkretnymi cechami ma się charakteryzować Developer, mają one być broad and will vary with the domain of work. Co jest ukłonem w stronę innych dziedzin życia gdzie z powodzeniem można zastosować Scrum.
Odpowiedzialności w zespole
Ogromnym plusem nowego Scrum Guide jest również podanie odpowiedzialności jakie spoczywają na poszczególnych rolach. Autorzy Scrum Guide wyróżnili dwa rodzaje zadań do wykonania - responsible i accountable. Czytając nowego Scrum Guide możemy zauważyć że The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. Czytając dalej dowiadujemy się, że The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Pamiętając, że Scrum Team składa się z trzech ról, które również dostały wyraźne instrukcje na temat odpowiedzialności. I tak the Developers are always accountable for:
Creating a plan for the Sprint, the Sprint Backlog;
Instilling quality by adhering to a Definition of Done;
Adapting their plan each day toward the Sprint Goal; and,
Holding each other accountable as professionals.
Product Owner natomiast is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Jak również he is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood
I wymieniona na samym końcu, ale to nie znaczy, że nie ważna, rola Scrum Mastera, która odpowiedzialna jest za: for establishing Scrum as defined in the Scrum Guide oraz the Scrum Team’s effectiveness. I tylko tyle dla głównego bohatera? Chociaż w części odpowiedzialności wymienione zostały tylko dwie rzeczy, to należy pamiętać, że rola Scrum Mastera jest kluczowa dla funkcjonowania Scrum. Niby dlaczego? O tym poniżej...
Wyraźne zaznaczenie, że Scrum nie istnieje bez Scrum Mastera
Nawiązując do tytułu tego akapitu w nowym Scrum Guide znajdziemy miejsca gdzie autorzy wyraźnie zaznaczają, że Scrum nie istnieje bez Scrum Mastera.
Scrum requires a Scrum Master to foster an environment
Nie oznacza to, że teraz firmy powinny zatrudniać osoby dedykowane do bycia Scrum Masterem, ale istotne jest aby była wyznaczona osoba, która będzie pełniła tą rolę i była odpowiedzialna za zadania przypisane do Scrum Mastera. Potwierdzeniem tej tezy jest jeden z ostatnich akapitów przewodnika, co dla mnie osobiście jest również wyraźnym sygnałem jak należy stosować zapisane tutaj reguły:
The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Podsumowanie
Podsumowując, choć Scrum istnieje już od 25 lat to nie jest skostniałą organizacją, która nie reaguje na zmieniający się świat. Dowodem na to jest właśnie nowy Scrum Guide, w którym możemy znaleźć wiele istotnych zmian, o których pisaliśmy powyżej. Do najważniejszych jakie należy zaliczyć to otwarcie się na inne dziedziny życia niż tylko branża IT, z którą związane było podejście Agile do realizacji projektów.
Kolejnym pozytywnym krokiem jest wyraźne zadanie sobie pytania Why? w odniesieniu do każdego elementu, działania jakie ma miejsce w trakcie trwania projektu. Wyraźne skupienie się na Product Goal przenosi ciężar odpowiedzialności z realizacji budowania produktu na podniesienie jego wartości. To w znaczącym stopniu przybliża Scrum Team do biznesu i zwiększa świadomość tego, co chcemy wspólnie osiągnąć.
Dużym plusem nowego przewodnika jest również wypunktowanie odpowiedzialności jakie mają na sobie poszczególne role. Co jeszcze warto dodać na koniec to również, już wcześniej cytowane dwa fragmenty:
While implementing only parts of Scrum is possible, the result is not Scrum.
oraz
Easy to learn, Hard to master
Pamiętajmy o tym, że w dalszym ciągu Scrum opiera się na ciągłym uczeniu się i udoskonalaniu procesów - Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.
Komentarze
Prześlij komentarz