Kiedy dochodzi się do wysokiego poziomu wiedzy na pewien temat, ma się wrażenie, że każdy to wie, rozumie i wykorzystuje. Każde zagadnienie to oczywista oczywistość. Każde rozwiązanie problemu czy praktyka to rzeczy bardzo zależne od kontekstu i wielowymiarowe. Taki problem dotknął mnie w tematach Scrum, Agile, Testowania i ostatnio także coachingu. Mam trudność w znalezieniu dobrego tematu na prezentację lub warsztat, bo wydaje mi się, że podstawy już są powszechnie znane, a poszukiwanie kolejnej srebrnej kuli i Świętego Graala zostały porzucone. Skoro jest 17 stron Scrum Guide, to wszystko jest jasne i oczywiste. Prawda? Mogłoby się tak wydawać. Jednak wybierając się na konferencje lub wchodząc do kolejnej firmy jako konsultant często jestem zaskoczony jak wiele pracy u podstaw jest nadal potrzebne. Inspiracja przychodzi znienacka. Tym razem przybrała postaci uczestnika konferencji i zdarzenia drogowego.
Może najpierw o sytuacji na drodze. Podjeżdżam do skrzyżowania z zamiarem skręcenia w prawo, co sygnalizuję włączonym kierunkowskazem. Sygnalizator świetlny pokazuje czerwone światło z zieloną strzałką w prawo. Zatem zatrzymuję się tak samo jak to się robi zawsze przy czerwonym świetle i dosłownie po sekundzie ruszam dalej upewniając się, że mogę włączyć się do ruchu. Za mną stał w swoim zgniłym Mercedesie jegomość, który miał aparycję sprzedawcy kebabów. Zaczął trąbić i energicznie wymachiwać rękami, w momencie, w którym się zatrzymałem. Kiedy ruszyliśmy wyprzedził mnie poboczem z prawej strony i usiłował doprowadzić do stłuczki. Oprócz podniesienia mi adrenaliny, napędził stracha mojej żonie. Pomijając prostactwo i stwarzanie niebezpiecznej sytuacji na drodze, pozostaje pytanie kto miał rację? Żeby się tego dowiedzieć, należy sięgnąć do źródła, czyli do Kodeksu Ruchu Drogowego.
Sygnał ten zezwala na ruch w najbliższą drogę na skrzyżowaniu w kierunku wskazanym strzałką, po zatrzymaniu się przed sygnalizatorem.
Czyli to ja zachowałem się prawidłowo i poniósłbym negatywne konsekwencje w przeciwnym przypadku.
Teraz przejdźmy do sytuacji z konferencji. Rozmawialiśmy na temat ról w Zespole Scrum, kiedy jeden z rozmówców powiedział, że Ch… napisał w swojej książce, że Scrum Master powinien kierować Zespołem Developerskim, a ja w swojej twierdzę, że powinien ograniczyć się do roli usłużnego lidera. Ch… twierdzi, że jest czarne, a Kaczor, że białe. Komu wierzyć? Wbrew pozorom, dokładnie tak jak w poprzednio opisanym przypadku, odpowiedź jest prosta. Scrum nie pojawił się znikąd i nie jest czymś, co trzeba odkrywać tak jak fizykę kwantową. Scrum został stworzony przez Jeffa Sutherlanda i skodyfikowany przez Kena Schwabera. Obecnie podstawą wiedzy jest Scrum Guide, czyli Przewodnik Scrum, który można pobrać strony scrum.org. Pomimo swojego rozmiaru ten przewodnik małego rozmiaru (16 stron — okładka, spis treści i notatki końcowe), jest to bardzo dobrze przemyślane, skondensowane źródło podstawowej wiedzy. Zatem, w razie wątpliwości zajrzyj najpierw tam. W następnej kolejności poszukaj odpowiedzi w The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method, który jest zbiorem artykułów Jeffa Sutherlanda dogłębnie omawiających podstawy i pochodzenie elementów Scrum. Wreszcie możesz sięgnąć do książek na konkretny temat napisanych przez Kena Schwabera, Jeffa Sutherlanda i Mike’a Cohna. Robiłem tak na początku swojej przygody z metodami zwinnymi i dokładnie tak samo postępowałem pisząc “Scrum i nie tylko. Teoria i praktyka w metodach Agile”.
Podsumowując, na pytania komu wierzyć i jak to być powinno, odpowiadam jeśli masz wątpliwości, to sprawdź u źródła.
- Zespoły Agile — kto do nich pasuje? — 09/05/2025
- Prawo Brooksa w środowiskach Agile — 02/05/2025
- Definition of Ready — 23/04/2025