W toku pracy z zespołami zwinnymi wypracowałem sobie listę kontrolną, która pomaga zbudować strukturę warsztatu startowania Zespołu Scrumowego. Lista ta może też pomóc w sytuacji, gdy zespół przechodzi wyraźną modyfikacji swojego składu czy zakresu odpowiedzialności – zrewidowanie zasad działania procesu pracy może pomóc de facto zrestartować zespół i wyczyścić niedoskonałości metod pracy postrzegane przez jego członków. W ramach tych punktów zakładam, że członkowie zespołu znają już podstawy podejścia zwinnego i metodę Scrum, jeśli nie – startowym punktem jest zrealizowanie całym zespołem jakiejś formy warsztatu tłumaczącego czym jest agile i jak pracować scrumowo.
Jaki jest cel powołania zespołu?
Ustalcie co jest celem istnienia zespołu – jaki produkt będzie pod opieką zespołu, jakie potrzeby biznesowe albo – w ostateczności – jaki projekt ma zostać realizowany przez dany zespół. Warto nazwać sobie wartość biznesową, jaka jest najważniejsza w ramach pracy nad produktem (np. wzrost przychodów, bezpieczeństwo, użyteczność). Pamiętajmy też o najnowszym zobowiązaniu związanym z Backlogiem Produktu, czyli Celu Produktu.
Jeśli dany zespół wcześniej nie stosował Scrum warto też ustalić co jest celem próby jego zastosowania – co chcemy tym sposobem poprawić, zmienić, jak to podejście ma być lepszy od dotychczasowych metod organizacji pracy.
Kto jest Właścicielem Produktu?
Wyznaczcie JEDNEGO Właściciela Produktu dla całego zespołu. Zespół nie może mieć kilku PO, PO od wybranych tematów czy projektów, itd. Jeśli z jakichś powodów nie można wyznaczyć Product Ownera, nie ma sensu iść dalej z próbą realizowania pracy Scrumem – potrzebny jest jeden decydent z wizją na temat produktu.
Kto wchodzi w skład Zespołu?
Ustalcie kto obejmuje odpowiedzialność Deweloperów – w realiach wielu organizacji może to oznaczać dosyć trudne rozmowy o zaangażowaniu się w jeden konkretny zespół jako alternatywę do bycia rozrywanym przez kilka konkurujących priorytetów z różnych projektów. Spośród zainteresowanych osób jednoznacznie określcie, czy dana osoba jest w Zespole Scrumowym, czy może jest poza nim. Zastanówcie się też, czy nie brakuje jakiejś kompetencji w Zespole, by mógł on realizować w całości Cel ustalony w punkcie 1.
Jaka jest nazwa zespołu?
Wybierzcie jako zespół nazwę dla siebie. Odważcie się na nazwę inną niż „zespół <imię i nazwisko kierownika>” albo „zespół <nazwa modułu którym się opiekujecie>”. Nazwa zespołu zbuduje jego tożsamość i pozwoli lepiej spoić jego członków, a jeśli uda się wymyślić taką kreatywną nazwę, która w jakiś ciekawy sposób ukrywa historię znaną tylko zespołowi – uzyskamy dodatkowy smaczek, który doda członkom zespołu poczucie należenie do kręgu wtajemniczonych. Jeśli w zespole są takie talenty – można też przygotować jego logo.
Kto jest Scrum Masterem?
Wybierzcie spośród siebie Scrum Mastera. Ważne by proponowana osoba pełniąca tą odpowiedzialność chciała ją pełnić. Jeśli nikt w Zespole Scrumowym nie jest dobrym kandydatem na SM albo nie ma chętnych – zgłoście to jako przeszkodę w stosowaniu Scrum do kierownictwa. Jeśli w zespole jest wcześniej wskazana osoba do pełnienia odpowiedzialności SMa – odświeżcie kredyt zaufania tej osobie, potwierdzając jej, że cały zespół chce, by spełniała się w tej funkcji.
Jaki jest cykl wydarzeń scrumowych?
Ustalcie długość Sprintu i kiedy będzie realizowany Codzienny Scrum oraz Planowanie Sprintu, Przegląd Sprintu i Retrospektywa Sprintu. Szczególnie uważni bądźcie jako Zespół Scrumowy na to, co o propozycjach sądzi Właściciel Produktu, ponieważ być może Sprint Review będzie trzeba dopasować do możliwości wzięcia udziału w nim jakiegoś ważnego dla Waszego zespołu interesariusza. Umówiona osoba (np. SM, PO albo ochotnik z zespołu) wrzuca w kalendarz cykliczne zaproszenie na wszystkie ustalone wydarzenia. Nie zapomnijcie o cyklu spotkań warsztatowych w ramach procesu Refinementu Backlogu Produktu – zwłaszcza, jeśli zespół dopiero zaczyna pracę razem, dużo czasu i energii trzeba będzie włożyć w zbudowanie dobrego Backlogu Produktu.
Jaka jest Definicja Ukończenia?
Spiszcie sobie Wasz pomysł na Definicję Ukończenia (DoD), zgodzić się na nią muszą wszyscy członkowie zespołu, ponieważ od pierwszego sprintu będzie trzeba jej przestrzegać. Zapytajcie też PO, czy nie ma potrzeby dołożenia dodatkowych punktów (bardziej biznesowych niż technicznych – np. Aktualizacja jakiejś instrukcji, materiałów dla użytkowników, materiałów marketingowe). Uwzględnijcie w swojej Definicji Ukończenia wytyczne organizacyjne (standardy co do procesu wytwórczego, standardy kodowania). Pamiętajcie, że DoD jest sformalizowanym zobowiązaniem Zespołu Scrumowego i jednoznacznie określa to, czy Przyrost jest skończony i czy może być zaprezentowany na Przeglądzie Sprintu!
Jakie są pierwsze elementy Backlogu Produktu?
Najpóźniej na pierwszym Planowaniu Sprintu Product Owner musi mieć pierwszy pomysł na elementy Backlogu Produktu, by zespół miał nad czym pracować (Cel Produktu). Zbudowanie pierwszych elementów może się odbyć w ramach warsztatu startowania zespołu lub najpóźniej na pierwszym planowaniu. Można użyć technik opisanych w artykule “User Story Jam Session”.
Na jakie wsparcie może liczyć zespół?
Ustalcie jakie są ścieżki wsparcia dla Waszych prób scrumowych – kto może pomóc rozwinąć się Waszemu Scrum Masterowi i całemu zespołowi w wykorzystaniu Scruma (jeśli nie czujecie że macie wystarczające doświadczenie). Poznajcie zakres wsparcia oferowanego przez menedżerów powyżej zespołów i powyżej Product Ownera. Upewnijcie się jak organizacja (m.in. kierownictwo, właściciele procesów, inne zespoły) zamierza Wam pomóc w rozwiązaniu problemów, jakie napotkacie i zidentyfikujecie w ramach pierwszych Retrospektyw.
Jakie są reguły współpracy w zespole?
Warto wprost nazwać kilka podstawowych zasad, jakie chcecie przestrzegać jako zespół w trakcie współpracy ze sobą. Może to oznaczać rozmowę o wartościach, jakie chcecie przestrzegać i wzajemnych oczekiwaniach co do członków Zespołu Scrumowego. Nawet jeśli będą to oczywiste sprawy, warto by wybrzmiały „na głos” i żeby cały zespół potwierdził chęć ich przestrzegania, ponieważ możliwe, że w sytuacjach stresowych o niektórych z nich możecie zapomnieć i trzeba się będzie do nich odwołać.
Kilka rad ogólnych przy startowaniu nowego zespołu
- Nie blokujcie się na konieczności wybrania idealnego podejścia – wszystkie te rozwiązania które ustalicie w ramach warsztatu mogą ulec dalszej ewolucji w ramach kolejnych Retrospektyw. Nie musicie szukać decyzji idealnych, ważne, by to, co ustalicie, było akceptowalne dla członków zespołu jako punkt startu.
- Zaufajcie empiryzmowi – nie martwcie się na zapas, tylko po prostu wystartujcie pierwszy Sprint i zobaczcie, jakie będą efekty. Niektóre wyobrażenia na temat tego, co może pójść nie tak okażą się przesadzone, za to napotkacie rzeczy, o których nikt z Was by nie pomyślał.
- Jeśli nikt w zespole nie ma doświadczenia w Scrumie, w trakcie rozpoczynania pracy zadbajcie o udział w warsztacie osoby spoza zespołu, która takie doświadczenie ma (np. Scrum Master z innego zespołu, Agile Coach spoza firmy) – do podejmowania niektórych decyzji przyda się eksploracja różnych opcji, których niedoświadczone osoby mogą nie znać.
- Na tyle na ile to możliwe przyjmijcie realistyczne założenia na podstawie obecnego stanu funkcjonowania zespołu albo organizacji – np. nie planujcie za ambitnego DoD, nie próbujcie naprawić cały świat jednym warsztatem
- W miarę możliwości próbujcie przestrzegać powyższej kolejności, kolejne tematy wynikają z poprzednich. Możliwe że rozmowy o dalszych pytaniach cofną Was do poprzednich, bo zauważycie coś, czego wcześniej nie wspomnieliście
- Nie zapomnijcie w trakcie całego warsztatu spisywać swoich ustaleń, przekujcie co tylko się da widoczne dla całego zespołu sformułowania podsumowujące Wasze decyzje
Co jeszcze robicie, gdy uruchamiacie nowy Zespół Scrumowy albo resetujecie zasady pracy starego? Czy jest coś jeszcze, co dodalibyście do tej listy?
Źródło zdjęcia: Martin Strattner „START” https://flic.kr/p/yRVKc na licencji CC BY-ND 2.0