Ś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ę programowanie
Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy:
- Framework by Guide
- Jakość techniczna
- Wartości i wyjście poza zespół
- Nieustanny tuning DoD
W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy:
- 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
- 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, wdrożenie Modelling Whirpool
- Regularne Architectural Kata
- Regularne Refactoring Kata
- 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ć
- 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
