Jak wystartować jako zespół scrumowy?

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ść). 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 wchodzi w skład Zespołu Deweloperskiego – 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, 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ą rolę chciała ją pełnić. Jeśli nikt w zespole 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 roli SMa – odświeżcie kredyt zaufania tej osobie, potwierdzając jej, że cały zespół chce, by pełniła tę rolę.

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ń Refinementu Backloga – 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 nie 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).

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ć. 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ół 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

Komentarze do wpisu: “Jak wystartować jako zespół scrumowy?

  1. Ja podczas ostatniego startu jednego z zespołów prosiłam jeszcze o określenie jakie są osobiste cele poszczególnych osób z zespołu oraz co motywuje poszczególne osoby w zespole. Uważam, ze zwłaszcza motywacja poszczególnych osób jest ważna. Dobrze też głośno w zespole to omówić.

  2. Marcin Dimitrow

    Kuba,
    Przede wszystkim dzięki za artykuł. Jak zwykle świetna robota i wartościowy materiał do stosowania.
    Jednak jedno założenie tego artykułu dość mocno zawęziło jego praktyczny charakter.
    Jak dużo miałeś zespołów, w których ta czeklista była na starcie w całości ‚odhaczona’?
    Ja raczej spotykam się z sytuacjami, którą opisałeś pod koniec wstępu. Wtedy jednak samo szkolenie zwykle nie wystarczy.
    Jakie w takim przypadku stosujesz podejście? Ja raczej nie upieram się, żeby nie startować prac takiego zespołu – w sprintach, z planowaniem, review, retro, daily (celowo małą literą), czy z czym tam się jeszcze da. Oczywiście nie nazywam tego Scrumem, ale przygotowane zespołu do Scruma też może być realizowane procesem empirycznym. Staram się, żeby rama Scruma była potrzebą, która zespół sam doświadcza, a nie narzuconą wiedzą przez mądrzejszego SM, czy jeszcze gorzej AC 😉
    Dość krytycznie odniosłeś się do braku 1 PO. Najczęstsze, ktore obserwuję początkowe dysfunkcje, z którymi zespołu się borykają – wielu PO, SM niedoświadczony, niejasny skład zespołu (okazuje sie w trakcie sprintu ze dedykowanie do zespołu było nie do końca 😉 ), waterfallowy backlog, który prowadzi do braku inkrementu i sprintu 0, 0.1 i 0.9 😉 , brak definicji produktu, który wprowadza skomplikowane powiązania z innymi zespołami.
    Myślę, że te dysfunkcje nie wykluczają prób ze Scrumem (oczywiście zawsze podkreślając, że to jeszcze nie Scrum i bardzo prawdopodobne, że nie będzie nam wychodziło właśnie przez te dysfunkcje), co więcej dają zespołowi bardzo ważny element doświadczenia, nauki – po co nam te ograniczenia?

    • Marcin, dzięki za Twój rozbudowany komentarz, poruszasz ważną kwestię, której pewnie w drobnej wymianie uwag pod artykułem nie sposób z mojej strony wyczerpać. Pisząc (przygotowując ten materiał) jednak chcę się trzymać tego minimalnego standardu Scruma – jest Właściciel Produktu, SM i Zespół Wytwórczy, korzystamy z wydarzeń i tworzymy artefakty, dążymy do Przyrostu co sprint. Budujemy zespół na wartościach scrumowych, pamiętamy o tym, żeby ten nasz Scrum był jednocześnie agile. Owszem, da się zrealizować pracę w sposób zwinny bez tego minimalnego zestawu albo dojść do Scruma krok po kroku i są sytuację wymagające kompromisu, ale nie chcę w ramach listy z tego artykułu wprowadzać niezdecydowania czy zachęcać do półśrodków. Firmy czy zespoły za łatwo rezygnują z elementów modelowego Scruma nie rozumiejąc przyczyn, dla których jest on jaki jest i jakie są zaszyte w nim wzajemne wzmocnienia wydarzeń/ról/artefaktów.

      Obawiam się (bazując na praktyce), że chociażby wspomniany przez Ciebie wieloosobowy PO, to próba „robienia” Scruma bez szczerego porozmawiania, z czego skuteczność tej roli wynika. Potrzebne też jest szczere zdecydowanie się, że skoro chcemy takiej metody spróbować, to spróbujmy jej całej, a nie tylko wybiórczo. Słyszę argument, że możemy spróbować choć trochę i potem usprawnić – ale ja za często widziałem „Scrum u nas nie działa”, które oznacza w tych realiach „poszczególne elementy Scruma połączone z naszymi specyficznymi modyfikacjami nie dają nam rezultatu”. I rzadko wtedy jest chęć ewolucyjnego dojścia z bardzo niedoskonałego modelu do modelu czystego. (Choć czystość modelu nie jest dla mnie nigdy celem samym w sobie – ale może być środkiem do zmiany sposobu funkcjonowania).

      Trzeba sobie wprost powiedzieć – jak chcemy spróbować jakiegoś narzędzia, to użyjmy go przynajmniej na próbę zgodnie z instrukcją. I w tym sensie Scrum jest narzędziem, które ma jednoznaczną instrukcję. Jeśli z jakichś powodów ta instrukcja nie jest możliwa, to ja widzę potrzebę przepracowania tematu tych ograniczeń organizacyjnych (dlaczego nie da się delegować ludzi do zespołu? dlaczego nie można wybrać jednego decydenta w produkcie? dlaczego nie jest możliwe regularne wdrażanie przyrostu?) i wprowadzanie zmian na poziomie systemu. Często wtedy możemy dojść do niepokojących ustaleń na temat roli menedżera w firmie i niedociągnięć w dotychczasowym funkcjonowaniu tej warstwy, czego próba realizacji hybrydowych modeli absolutnie nie zastąpi i szczerze wątpię czy zrobi jakąkolwiek korzystną różnicę.

      Jeśli największe ograniczenia systemowe są absolutnie nie do ruszenia, poprawniejszym modelem byłoby ewoluowanie bardziej stylem kanbanowym. Ewolucyjne przyrostowe usprawnianie w takiej sytuacji będzie moim zdaniem lepsze niż wybranie sobie tych elementów Scruma które są możliwe do realizacji i trzymanie kciuków, że to wystarczy by było lepiej. Bo może być gorzej.

      Co niestety nie zmienia faktu, że w wielu firmach tej refleksji, jak w naszej wymianie komentarzy, w ogóle nie ma, poszczególne modele próbowane są w losowy i nierzetelny sposób. Najczęściej sparza to do idei zarówno management jak i pracowników, którzy potem chętnie dzielą się swoimi frustracjami i niezrozumieniem. Wolałbym, żeby takie osoby trafiły do tego artykułu i sobie przeczytały przez jakie pytania powinny przejść przy starcie swojej próby i jak bardzo były odległe od ideału.

      Pozdrawiam,
      Kuba


Pozostaw odpowiedź Jakub Szczepanik Anuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X