Śmieją się developerzy ze ScrumMasterów, że ci nic nie robią. Niby żartem, niby po przyjacielsku, ale boli. Gdy ScrumMaster zostaje ScrumMaster jedne z pierwszych pytań, które sobie zadaje to:

  • No i co ja mam teraz robić?
  • A co jeśli zapomnę jak się programuje?
  • A co jeśli znudzi mi się scrumasterowanie?
Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy:
  1. Framework by Guide
  2. Jakość techniczna
  3. Wartości i wyjście poza zespół
  4. Nieustanny tuning DoD
W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy:
  1. Framework by Guide
    • Zaimplementowanie w pracy zespołu ról: SM, PO z biznesu, SM, DevTeam
    • Zaimplementowanie w pracy zespołu: sprintów stałej długości, DoD, Planningu, Review, Daily, Retro, regularnego refinementu PBL, Product Backloga, Spring Backloga
    • Biznesowe cele sprintów
    • Zaimplementowanie w pracy zespołu: biznesowego inkrementu produktu na koniec sprintu, współpracy między zespołem a PO, która nie wymaga sztywnego DoR
    • samoorganizacja Zespołu deweloperskiego
    • Doprowadzenie do tego, aby testerzy byli pełnoprawnymi członkami Zespołu scrumowego, a nie podzespołem w zespole
  2. Jakość techniczna
    • Wdrożenie 1-3 metryk kodu oraz systematyczna praca nad ich poprawianiem; propozycja na początek CC oraz LOC na poziomie metod i klas
    • Zmierzenie długu technicznego, przygotowanie planu jego spłaty i wynegocjowanie tego z PO
    • Wdrożenie Continuous Integration -> Continuous Deployment -> Continuous Delivery
    • Wprowadzenie regularnego Code Review w zespole wraz z narzędziem, który je wspiera
    • Wdrożenie Test/Behaviour Driven Development
    • Wdrożenie automatycznych testów funkcjonalnych wraz z narzędziem, które je wspiera; nauczenie PO i/lub interesariuszy formułowania wymagań w formie scenariuszy
    • Wdrożenie Domain-Driven Design, nawiązanie współpracy z ekspertami domenowymi, facylitacja warsztatów Event Storming
    • Regularne Architectural Kata
    • Regularne Refactoring Kata
  3. Wartości i wyjście poza zespół
    • Doprowadzenie do sytuacji, w której prace zespołu są niezależne od innych jednostek organizacji
    • Pomoc managerowi zespołu w na nowo zdefiniowaniu swojej roli w stosunku do zespołu scrumowego
    • Doprowadzenie do określenia zasad współpracy pomiędzy jego/jej zespołem a innymi zespołami i/lub jednostkami organizacyjnymi
    • Stymulowanie wewnętrznych inicjatyw typu "craftsmanship": wewnętrzne konferencje, warsztaty, szkolenia, mini-społeczności skupione w okół danych technologii albo ról (np. gildie)
    • Eksponowanie osiągnięć zespołu na zewnątrz organizacji: konferencje branżowe, artykuły w prasie i na portalach branżowych
    • Wdrażanie i promowanie empirycznego podejścia do pracy tj. wprowadzanie przejrzystych metryk przy jednoczesnym uczeniu organizacji jak z nich sensownie korzystać
  4. Nieustanny tuning DoD
    • Doprowadzenie do sytuacji, w której "Done" oznacza "dostępne dla klientów"
    • Praca na skróceniem time to markiet, time to feedback
    • Dążenie do sytuacji, w której ani zespół ani organizacja nie potrzebują Scrum Mastera, gdyż jego obowiązki zostały osmotycznie przejęte przez członków zespołu i innych pracowników organizacji, którzy bezpośrednio dostarczają wartość dla jej klientów

.