“Bo tak jest napisane w Scrum Guide” jest wytłumaczeniem, które słyszałem ostatnio kilka razy od początkujących Scrum Masterów. Na początku mnie to trochę przeraziło, ale potem uświadomiłem sobie, że w ten sposób wielu z nich uczy się Scruma. Czytają Scrum Guide, albo słyszą reguły Scruma od aspirującego Agile Coacha i każe im się ich kurczowo trzymać. Co w większości przypadków ma sens, bo wiele modyfikacji Scruma wynika z potrzeby ukrycia problemów wyciągniętych na światło dzienne przez Scruma. Na przykład, jeżeli każdy członek zespołu ma własne cele i zadania, to nie potrzebuje się synchronizować z pozostałymi i będzie unikał Daily Scruma. Ma to nawet swoją nazwę “Prawie Scrum” (ScrumBut), pochodzącą od sposobu w jaki te modyfikacje są opisywane (“Robimy Scruma, ale nie spotykamy się codziennie”).
Zrozumieć Dlaczego
Mimo to, oczekiwałbym od każdego Scrum Mastera, niezależnie od poziomu doświadczenia, umiejętności odpowiedzenia nie tylko na pytania “co” i “jak” robić, ale również “dlaczego”. Na przykład, poza wiedzą, że mamy się spotkać codziennie i w jaki sposób przeprowadzić daily, dużo ważniejsze jest zrozumienie po co w ogóle mamy Daily. Zwłaszcza, że argument “Bo tak jest napisane w Scrum Guide” nie przekona ani Waszych klientów ani kierownictwa firmy. Dlatego każdy Scrum Master musi znać odpowiedzi na pytania “Dlaczego nie możemy mieć pięciu Product Ownerów?”, albo “Dlaczego mam Ci płacić za obserwowanie zespołu, kiedy możesz testować?”. Jak inaczej zachowasz swoją robotę?
Scrumowa Cebula
Na ostatnich szkoleniach pokazuję, że Scrum składa się z kilku warstw (jak ogr):
- Wartości – co jest dla nas ważne?
- Zasady – dlaczego robimy to co robimy?
- Ramy (Framework) – co i jak robimy?
- Dobre Praktyki – jakie techniki warto wypróbować?
- Złe Praktyki – jakich technik lepiej unikać?
Na przykład Daily Scrum jest częścią Frameworka, ale już tablica zadań czy wykresy są Dobrymi Praktykami. Natomiast używanie elektronicznych narzędzi zamiast fizycznych tablic najczęściej jest Złą Praktyką. Chcesz wiedzieć dlaczego? Zobacz na wady tablicy elektronicznej.
Od Wartości do Zasad
Scrum bazuje na Wartościach Agile spisanych w Agile Manifesto, ale posiada również pięć swoich wartości, które znalazły swoje miejsce w aktualizacji Scrum Guide z 2016 roku. Są nimi Otwartość, Szacunek, Odwaga, Zobowiązanie i Skupienie.
Scrum bazuje również na Dwunastu Zasadach Agile i również wprowadza kilka dodatkowych zasad. Jednak z jakiegoś powodu, te nigdy nie zostały spisane przez Kena Schwabera lub Jeffa Sutherlanda, współautorów Scrum Guide. Osobiście uważam, że zrozumienie tych zasad jest ważne dla każdego Scrum Mastera i Agile Coacha. Dlatego bazując na moich doświadczeniach oraz rozmowach z innymi CST stworzyłem swoją listę. Dwa założenia, które przyjąłem to:
- Zasady Scruma bazują na Zasadach Agile, więc nie ma sensu ich duplikować.
- Zasady Scruma powinny być minimalną listą pozwalającą na zdefiniowanie Frameworku Scrum.
Moja lista ewoluuje, w miarę jak waliduje ją z uczestnikami moich szkoleń. Poniżej znajdziesz aktualną wersję.
Zasady Scrum
- Inkrement
Dostarczcie wartość w każdym krótkim cyklu, miesięcznym lub krótszym (Sprint). - Kontekst
Wasz kontekst jest ważny, dlatego sami stwórzcie swój proces. - Przejrzystość
Zapewnienie przejrzystości jest tańsze niż kontrola. - Empiryzm
Częsta Inspekcja i Adaptacja (co dzień i co Sprint) pozwoli Wam iść w dobrym kierunku. - Samoorganizacja
Zespół wie jak to zrobić, pozwólcie mu więc zdecydować. - Współpraca
Zespół to coś więcej niż suma jednostek. - Product Owner
Jedna osoba decydująca o kierunku pomaga optymalizować wartość. - Scrum Master
Jedna osoba wspierająca cały system powoduje, że wszystko działa płynniej. - Skupienie
Ramy czasowe, ograniczenie pracy w toku i usunięcie przeszkód pozwolą Wam się skupić. - Eksperymenty
W każdym Sprincie spróbujcie czegoś innego.
Pobierz 10 zasad Scrum
