Scrum dla dwojga

„Złożony system, który działa, niezaprzeczalnie ewoluował z prostego systemu, który działał. Złożony system sklecony ze skrawków nigdy nie działa ani nie można poprawić go tak, aby działał. Musisz zacząć od nowa z działającym prostym systemem."- Prawo Galla

Jestem Scrum Masterem z siedmioletnim doświadczeniem. Podczas mojej kariery zawodowej jako Scrum Master zdobyłem doświadczenie w pracy w różnych kontekstach i konfiguracjach zespołów, takich jak zespoły jednoproduktowe i zespoły będące częścią większych działań w zakresie skalowania, zespołów rozproszonych i pracujących we wspólnym środowisku, w małych, średnich i dużych organizacjach. To, co pomaga mi być dobrym Scrum Masterem, to ciekawość, jak działają rzeczy i jak je ulepszyć. Obecnie pracuję jako Scrum Master dla zespołu w jednym z największych banków w Danii.

Mój zespół, we współpracy z innym zespołem, odpowiada za rozwój usług krytycznych dla codziennej pracy banku. Naszą domeną są dane klientów i produkty, a także systemy świadczeń. W tym artykule podzielę się z wami, jak dwa zespoły Scrum inspirowane ramami Nexusa, odkryły lepszy sposób współpracy.

Struktura zespołów jest zgodna z zastosowaną technologią. Z biegiem lat usługi, za które odpowiedzialne są nasze zespoły, były opracowywane w technologii mainframe (Cobol, gen), a później w Javie. Z tego powodu każdy zespół składa się z programistów Java i Mainframe, a także architekta, analityka biznesowego, Scrum Mastera i Właściciela produktu. Właściciel produktu, analityk biznesowy i architekt dzielą się swoim czasem z obydwoma zespołami. Zespoły są małe — do 6 programistów. Pracujemy również w trzech lokalizacjach w dwóch krajach — Danii i Polsce.

Kiedy dołączyłem do banku rok temu, spotkałem zespół, którego członkowie pracowali ze sobą od kilku lat. W tym czasie próbowali znaleźć sposób na użycie Scrum bez żadnej pomocy lub wskazówek z zewnątrz. Nie było dla mnie więc zaskoczeniem, że znajdą się obszary otwarte na zmiany. Oto kilka kwestii, które zwróciły moją uwagę na samym początku mojej podróży z tym konkretnym klientem:

brak przeglądu sprintu,

za mało udoskonalone elementy backlogu produktu,

duży nacisk na budżetowanie i liczenie „roboczodni”,

dwa zespoły pracujące w tej samej domenie — jeden przeciążony pracą, drugi szukający czegoś do zrobienia,

dwóch programistów (po jednym z każdego zespołu) oddelegowanych do pracy nad zadaniami utrzymania tylko podczas sprintu.

Dobrą stroną było to, że Zespół programistyczny był (i nadal jest) grupą inteligentnych, wykwalifikowanych ludzi, którzy zdawali się tkwić w pewnych problemach. W tym artykule skupię się na tym, jak zmieniliśmy sposób, w jaki pracowaliśmy razem, aby przezwyciężyć te wyzwania.

„Dla całego Nexusa i wszystkich jego Zespołów Scrumowych istnieje tylko jeden Backlog Produktu. Odpowiedzialność za Backlog Produktu, w tym za jego zawartość, dostępność i kolejność, ponosi Właściciel Produktu”, Przewodnik po Nexusie

Twórcy Scruma twierdzą, że Scrum jest „łatwy do zrozumienia” i „trudny do opanowania”. W zadaniu, które aktualnie wykonuję jako freelancer, mieliśmy do czynienia z zarządzaniem dwoma uporządkowanymi listami elementów backlogu produktu, po jednym dla każdego z dwóch zespołów. Dowiedziałem się, że dzieje się tak głównie z przyczyn historycznych, które już nie obowiązują. W pewnym momencie zespoły zgodziły się na podział zakresu odpowiedzialności i zdecydowały, który zespół będzie właścicielem jakich usług. Okazało się, że zmiany, które trzeba wprowadzić, aby zapewnić wartość biznesową, leżą głównie w zakresie jednego zespołu. Właścicielka produktu stanęła przed podwójnym wyzwaniem: z jednej strony, że nie mogła spełnić wymagań interesariuszy, a z drugiej strony miała trudności ze znalezieniem pracy dla drugiego zespołu.

Jasne było, że rozwiązaniem problemu musi być jeden backlog produktu dla każdego zespołu, tak jak w ramach Nexusa. Uzyskanie wsparcia dla tego pomysłu od Właścicielki produktu było dosyć proste. Wspólnie dostrzegliśmy tam wiele korzyści, na przykład:

koniec ze sztucznym podziałem i skupienie się na tym, co przynosi największą wartość obu zespołom,

utrzymywanie jednego backlogu jest łatwiejsze niż dwóch,

lepsza wymiana wiedzy między programistami z dwóch zespołów.

Jednak nasze zespoły programistyczne obawiały się, że zanim ruszymy z tym pomysłem, musimy zrozumieć:

Kiedy podjąć decyzję o tym, który zespół będzie pracował nad którym elementem backlogu produktu?

Jak należy podejść do szacowania elementów backlogu produktu?

Jak poradzić sobie z zależnościami w sprincie?

Były to uzasadnione obawy. Wspólne prace nad tym zajęły nam trochę czasu i doprowadziły do dalszych ulepszeń w sposobie naszej pracy. Na szczęście nie byliśmy pierwszymi, którzy zmagali się z takimi problemami. Przyjrzeliśmy się Przewodnikowi po Nexusie, który okazał się doskonałym źródłem inspiracji dla znalezienia dobrego rozwiązania w naszym kontekście.

Doskonalenie Backlogu Produktu jest działaniem polegającym na dodawaniu szczegółów, oszacowań i porządkowaniu elementów Backlogu Produktu”, Przewodnik po Scrumie

„To, jak i kiedy dochodzi do doskonalenia, zależy od decyzji Zespołu scrumowego. Doskonalenie zazwyczaj nie zajmuje więcej niż 10% czasu Zespołu deweloperskiego w sprincie”, Przewodnik po Scrumie

Począwszy od tego zadania, doskonalenie backlogu produktu zostało potraktowane jako coś nieistotnego. Niektórzy członkowie zespołu uważali to za stratę czasu, ponieważ „wszystko” można omówić podczas planowania sprintu. W rezultacie prognoza utworzona podczas planowania sprintu była obciążona dużą niepewnością, a oba zespoły odkrywały podczas sprintu, że zadania, które muszą wdrożyć, były znacznie bardziej złożone niż pierwotnie zakładano. Spowodowało to następujące problemy:

elementy backlogu produktu przeciągały się z jednego sprintu do drugiego,

Właścicielka produktu musiała stworzyć wiarygodny plan wydań i w pewny sposób przekazać go zespołom,

interesariusze byli rozczarowani pracą zespołową,

w końcu wszystkie te kwestie doprowadziły do braku zaufania (interesariusze nie ufali Właścicielce produktu, Właścicielka produktu nie ufała zespołowi, a nawet niektórzy członkowie zespołu nie ufali swoim współpracownikom).

Widząc to wszystko, rozpocząłem dialog z Właścicielką produktu na temat potrzeby inwestowania większej ilości czasu w lepsze zrozumienie pracy, którą mamy zamiar wykonać. Początkowo zgodziła się, że przygotuje listę elementów backlogu produktu, które uważa za priorytet na następnym sprincie, a następnie wyśle ją do zespołu z prośbą o udoskonalenie. Znaleźliśmy się w sytuacji spotkań ad hoc, na których staraliśmy się zrozumieć, co trzeba zrobić. To był krok we właściwym kierunku, ale nie byliśmy zadowoleni z wyników. Wywołało to dobrą dyskusję na temat sposobu, w jaki przeprowadzamy doskonalenie podczas jednej z retrospektyw sprintu, którą miałem przyjemność pośredniczyć. Zdecydowaliśmy, że chcielibyśmy, aby jeden dzień w sprincie poświęcić wyłącznie na doskonalenie.

Oto jak organizujemy „Dzień doskonalenia”:

Rano Właścicielka produktu udostępniła obu zespołom (wszyscy byli obecni) elementy backlogu produktu do udoskonalenia.

Po zapoznaniu się ze wszystkimi elementami następuje decyzja, kto będzie odpowiedzialny za doskonalenie których elementów. Tworzymy grupy robocze doskonalenia pracujące w obu zespołach (w tym momencie zakładamy, że dany element może być zaimplementowany przez jeden z dwóch zespołów)

Pod koniec dnia zbieramy się ponownie, a każda grupa przedstawia swoje ustalenia reszcie

Scrum Masterzy w razie potrzeby pomagają w ułatwianiu tego procesu

Grupy robocze doskonalenia samoorganizują się w ciągu dnia w zakresie sposobu przeprowadzania doskonalenia

Koncentrując się bardziej na doskonaleniu, po planowaniu sprintu uzyskaliśmy dokładniejsze prognozy. Zaplanowaliśmy nasze doskonalenie w pierwszym dniu drugiego tygodnia naszego 2-tygodniowego sprintu, który przyniósł lepsze uporządkowanie i pomógł utrzymać koncentrację podczas sprintu (mniejsza liczba spotkań ad-hoc, które rozpraszają programistów podczas sprintu).

Planowanie sprintu:

„Celem Planowania Sprintu Nexusa jest skoordynowanie działań wszystkich Zespołów scrumowych w Nexusie na czas pojedynczego Sprintu. Właściciel Produktu dostarcza wiedzę domenową i przewodzi procesowi doboru prac i ustalania priorytetów”, Przewodnik po Nexusie

„Gdy ogólny zakres pracy do wykonania w nadchodzącym Sprincie będzie dla wszystkich zrozumiały, każdy Zespół scrumowy przeprowadza własne Planowanie Sprintu”, Przewodnik po Nexusie

Decyzja o udostępnieniu jednego backlogu produktu między dwoma zespołami spowodowała dalsze zmiany w sposobie, w jaki obecnie pracujemy. Musieliśmy dostosować sposób, w jaki przeprowadzamy planowanie sprintu. Planowanie sprintu rozpoczyna się od współpracy przedstawicieli zespołów z Właścicielką produktu pod kątem ustaleń, jakie cele powinniśmy osiągnąć do końca sprintu, które elementy backlogu produktu wspierają te cele, a także jak podzielić pracę między dwa zespoły, aby zminimalizować zależności. Po tej części planowania sprintu każdy zespół kontynuuje pracę, prowadząc własną szczegółową dyskusję na temat elementów backlogu produktu wybranych do sprintu. Podczas drugiej części planowania sprintu do dyspozycji pozostają Właścicielka produktu, analityk biznesowy i nasz architekt. Scrum Masterzy obsługują ten proces jako moderatorzy.

Definicja ukończenia (DoD):

„Kiedy element Backlogu Produktu albo Przyrost jest określany jako „Ukończony”, wszyscy muszą rozumieć, co to właściwie oznacza”, Przewodnik po Scrumie

Ponieważ oba zespoły pracują nad tym samym backlogiem produktu, należy dokonać uzgodnienia co dla obu z nich oznacza ukończenie backlogu produktu. To była jedna z kluczowych spraw, które pomogłem osiągnąć, aby współpraca między dwoma zespołami była owocna. Plan osiągnięcia takiego uzgodnienia był prosty:

z obydwoma zespołami dokonać przeglądu Definicji ukończenia i udostępnić je we wspólnej przestrzeni (wiki),

przygotować jedną wersję Definicji ukończenia i poprosić o zgłaszanie uwag,

omówić uzgodnione wersje Definicji z obydwoma zespołami w trakcie retrospektywy.

Podczas tego procesu odkryliśmy, że niektóre z rzeczy przedstawionych w poprzednich wersjach Definicji ukończenia były przestarzałe, a w niektórych przypadkach interpretowaliśmy je na różne sposoby. Dzięki temu mamy teraz jednakowo postrzegamy pojęcie „ukończenia” i dodaliśmy więcej punktów związanych z jakością naszych rozwiązań.

Przegląd sprintu:

Praktykujemy jeden Przegląd sprintu z obydwoma zespołami, podczas którego dzielimy się rezultatami sprintu. Nasza Właścicielka produktu również podziela wizję dotyczącą przewidywalnej przyszłości, z naciskiem na kolejny sprint. Nadal ulepszamy sposób, w jaki prowadzone są nasze przeglądy sprintu, na przykład w zakresie uzyskiwania lepszych informacji zwrotnych od naszych interesariuszy.

Retrospektywa sprintu:

Po zakończeniu przeglądu sprintu mamy czas, by spojrzeć wstecz na ostatni sprint. Sposób, w jaki przeprowadzamy retrospektywę ewoluował w czasie. Zaczęliśmy od retrospektywy sprintu indywidualnie z obiema drużynami. Szybko okazało się, że dzięki posiadaniu jednego backlogu produktu, występują rzeczy, które warto omówić wspólnie (np. wspomniana wcześniej Definicja ukończenia). Więc jako kolejny krok, zdecydowaliśmy, że rozpoczniemy Retrospektywę sprintu z wszystkimi osobami z obu zespołów. A później będziemy kontynuować pracę oddzielnie (w podobny sposób prowadzimy Planowania sprintu). Przez pewien czas się to sprawdzało.

Po zajęciu się początkowymi kwestiami związanymi ze współpracą między zespołami postanowiliśmy zmienić kolejność — zaczynamy od indywidualnych zespołów, a następnie dołączamy do wspólnych wydarzeń, aby zarówno dzielić się wynikami z retrospektyw, jak i rozwiązywać kwestie związane ze współpracą.

Codzienny Scrum:

Każdy zespół ma swój własny Codzienny Scrum, jednak są one otwarte dla kolegów z drugiego zespołu. Daje nam to w razie potrzeby możliwość koordynowania pracy między zespołami podczas sprintu.

Podsumowanie:

Jak opisałem powyżej, sposób, w jaki pracujemy razem, jest kwestią ciągłego doskonalenia. Nie stosujemy żadnego szczególnego podejścia do skalowania, ale wprowadzając nowe elementy do naszej pracy, pamiętamy, że Scrum jest naszym fundamentem i szukamy inspiracji z metod skalowania zbliżonych do Scrum, takich jak Nexus. W rezultacie jesteśmy w stanie wprowadzić lekki proces koordynowania wysiłków dwóch zespołów. Ponadto stworzyliśmy konfigurację, którą lubię nazywać „gotową do skalowania”. Udowodniliśmy, że działa to dla dwóch zespołów, a jeśli zajdzie potrzeba rozwoju, będziemy gotowi dodać do tej konfiguracji nowe zespoły. Nie dlatego, że wynaleźliśmy idealny proces, ale dlatego stworzyliśmy środowisko z silnym fundamentem opartym na Scrumie, jego wartościach i otwarte na współpracę.

Nic z tego nie byłoby możliwe bez wysiłku ludzi, którzy dbają o swoje zespoły, a także inspiracji wykwalifikowanego Scrum Mastera. Znając historię swojego zespołu, zrozumienie stanu rzeczy jest kluczem do umożliwienia pozytywnych zmian we własnym zespole i wpływania na środowisko, w którym działa zespół.

Jakub Milewski to Scrum Master z ponad 10-letnim doświadczeniem zawodowym w branży IT oraz solidnym zapleczem technicznym w zakresie programowania i tworzenia aplikacji. Dzięki doskonałej praktycznej wiedzy na temat Zwinnego Zarządzania Projektami jest dobrze zorientowany w zwinnych metodykach: Scrum i Kanban. Ma doświadczenie w recenzowaniu kodów, narzędziach ciągłej integracji, a także praktykach programowania ekstremalnego: rozwoju opartego na testach (TDD), programowania w parach i rozwoju opartego na zachowaniu (BDD).

Jako Scrum Master pomagał wdrożyć struktury Scrum od podstaw, organizując pracę zespołów programistycznych zgodnie z zasadami Scrum, zarządzając zmianami organizacyjnymi, szkoląc menedżerów i programistów. Ostatnio prowadził wiele zespołów Scrum, a także społeczność Scrum Masterów i pomógł wdrożyć DevOps i Product Discovery.

JM jest zaznajomiony z następującymi technologiami: Atlassian JIRA, Trello, VSTS (Visual Studio Team System), Bash, Git, SVN, Gerrit, Jenkins, Microsoft Office. 

POWIĄZNE