Temat: Synchronizacja pracy Zespołów Scrumowych

Od jakiegoś czas w projekcie, w którym pracuję, mamy dwa zespoły scrumowe (bardzo prawdopodobne, że ich liczba w przyszłości się zwiększy) i chciałbym się dowiedzieć w jaki sposób radzicie sobie z synchronizacją pracy pomiędzy nimi? Wymianą informacji o postępie?

Czy odpowiedzialnością za to powinien być obarczony Scrum Master czy któryś z członków zespołu?
Jak powinna wyglądać wymiana informacji pomiędzy zespołami? Czy uczestniczyć w tej synchronizacji powinni wszyscy członkowie zespołów (co nie wydaje mi się dobrym pomysłem), czy raczej wybrane osoby?

Obecnie zastanawiamy się nad robieniem wspólnego Daily Standupa z tym, że zespoły pracują nad innymi elementami aplikacji, więc nie wiem, czy jest to dobry pomysł?
Myślałem również nad uczestnictwem jednej osoby (nie koniecznie zawsze tej samej) z innego zespołu w DS drugiego, z tym, że w przypadku większej ilości zespołów takie rozwiązanie również byłoby problematyczne.

Będę wdzięczny za wszelkie sugestie i podpowiedzi.

Temat: Synchronizacja pracy Zespołów Scrumowych

Cześć,

Z tego co zauważyłem to im więcej osób jest na standupie tym trudniej swobodnie mówić o rzeczach, które mogą się nie udać dlatego tu bym nic nie mieszał. Najlepiej niech zespoły same zorganizują sobie komunikację (zespoły jako "zespoły" a nie zespoły jako scrum masterzy czy inne takie osoby).
U mnie zadziałało.

pzdr

Temat: Synchronizacja pracy Zespołów Scrumowych

Co do DS, to właśnie przeczuwam problemy z robieniem jednego dla kilku zespołów.

Zastanawiam się nad wybraniem jednej osoby w każdym zespole (zmiennej co jakiś czas, co sprint?), która odpowiadałaby za wymianę informacji. Istotne rzeczy mogłaby prezentować właśnie podczas DSów.

Nie wiem, czy pomysł pozostawienia tego zespołowi będzie dobrym pomysłem, bo boję się, że wiele informacji będzie po prostu uciekało albo pozyskiwanie ich będzie dublowane, co skutkowałoby stratą czasu (tym więcej czasu, im bardziej skomplikowany temat).
Chociaż, z drugiej strony, jeżeli każdy członek zespołu prezentowałby istotne rzeczy na DS, to mogłoby zadziałać:)

Dzięki Pawle, z pewnością spróbuję:)

Temat: Synchronizacja pracy Zespołów Scrumowych

Osobiscie odradzalbym, zeby to ScrumMaster byl docelowo jedyna osoba, ktora bedzie punktem 'wejscia-wyjscia' dla zespolu. Ostatecznie, bedac w tej roli wypadalo by zapobiegac potencjalnym przeszkodom, a tzw. single point of failure pod postacia ScrumMastera przynoszacego newsy z zespolu obok, moze raczej zaszkodzic niz pomoc - oczywiscie w dlugim terminie. Dlatego tez, zaproponowalbym rotowanie reprezentanta zespolu (w kazdym sprincie kto inny, albo jedna osoba na tydzien, jezeli zespol uzna czestsze zmiany za bardziej efektywne, przy zalozeniu, ze nie macie jednotygodniowych iteracji). Stand up to tylko jedna z okazji, zeby poznac plany/przeszkody/wyzwania u sasiadow. Poza tym, jego 'zakres' to najwyzej kolejne 24 godziny.

Pozostaja jednak kwestie zakresu kolejnego sprintu i tego jak bardzo rozne zespoly beda sobie wchodzic w droge (na poziomie implementacji, potrzeb zwiazanych z testowaniem, czy chociazby tego samego srodowiska, na ktorym bedzie mialo sie odbyc demo dla ProductOwner'a). W sumie glowne opcje sa dwie. Pierwsza, elementy Product Backlog'u sa na tyle niezalezne, ze zespoly biorac je do sprintu od razu wiedza, czy to w wyniku analizy, czy tez dzieki krzywej uczenia sie, ze nie bedzie zaleznosci od postepu prac w innych zespolach - wspominales, ze zespoly pracuja nad innymi elementami aplikacji. Druga, wymagajaca moim skromnym zdaniem czestszej komunikacji pomiedzy zespolami, kiedy postep prac jednego zespolu wplywa na inne, co potencjalnie moze zatrzymac cala maszynerie. Wtedy wyzwan synchronizacji pracy pomiedzy zespolami moze byc wiecej.

A propos analizy user stories na przyszly sprint. W celu unikniecia kolizji i niedomowien - w przypadku, kiedy wiadomo, ze zakres historyjek na siebie zachodzi, warto zawczasu zorganizowac Joint Product Backlog Refinement (JPBR), gdzie pojawi sie reprezentant kazdego zespolu dzieki czemu bedzie mial okazje zabrac glos w sprawie design'u, sposobu testowania itp. oraz szeroko rozumianego Definition of Done (prawdopodobnie bedzie ono bardzo zblizone dla wszystkich zespolow realizujacych historie w obrebie jednego produktu).

Wracajac do Stand-up'a, mysle, ze warto sprobowac codziennego Scrum of Scrums, ktory odbywa sie po 'normalnym' Stand-up'pie w kazdym zespole i na ktorym pojawia sie reprezentant kazdego zespolu, zeby zakomunikowac status, przez co inni maja pojecie co sie dzieje gdzie indziej i czy wplywa to na ich plan dnia.

Skalowanie Scruma moze okazazac sie nie lada wyzwaniem i pewnie w kazdym projekcie rozne praktyki daja rozne efekty. Niemniej, o tym czy cos zadziala prawdopodobnie dowiesz sie eksperymentujac i poprzez ciagle obserwacje stale usprawniajac proces :)Maciej Kurek edytował(a) ten post dnia 29.10.12 o godzinie 20:49

Temat: Synchronizacja pracy Zespołów Scrumowych

Maciej Kurek:
Osobiscie odradzalbym, zeby to ScrumMaster byl docelowo jedyna osoba, ktora bedzie punktem 'wejscia-wyjscia' dla zespolu. [...]
zaproponowalbym rotowanie reprezentanta zespolu [...]

To świetnie, bo akurat pokrywa się z moimi pomysłami:P

Pozostaja jednak kwestie zakresu kolejnego sprintu i tego jak bardzo rozne zespoly beda sobie wchodzic w droge [...].
W sumie glowne opcje sa dwie. Pierwsza, elementy Product Backlog'u sa na tyle niezalezne, ze zespoly [...]
wiedza [...], ze nie bedzie zaleznosci od postepu prac w innych zespolach - wspominales, ze zespoly pracuja nad innymi elementami aplikacji.

I tak jest najczęściej, ale...

Druga [...], kiedy postep prac jednego zespolu wplywa na inne, co potencjalnie moze zatrzymac cala maszynerie. Wtedy wyzwan synchronizacji pracy pomiedzy zespolami moze byc wiecej.

Takie sytuacje zdarzają się, rzadko, ale się zdarzają i na razie działa to w ten sposób, że zespoły komunikują się ze sobą i przez pewien okres, kilka osób z obydwu zespołów (te odpowiedzialne za implementację miejsc granicznych) komunikują się dość intensywnie.
Implementacja i postęp pracy idzie całkiem nieźle, ale mam wrażenie, że informacje wymieniane pomiędzy tymi osobami gdzieś ulatują.

I tak naprawdę to jest najistotniejszy problem. I wydaje mi się, że na razie nie trzeba nam tworzyć dodatkowych rozwiązań, a jedynie w jakiś sposób usystematyzować to, co jest robione obecnie. Dlatego też wydaje mi się, że DS to odpowiednie moment na przedstawianie tych informacji.

A propos analizy user stories na przyszly sprint. W celu unikniecia kolizji i niedomowien - w przypadku, kiedy wiadomo, ze zakres historyjek na siebie zachodzi, warto zawczasu zorganizowac Joint Product Backlog Refinement (JPBR), gdzie pojawi sie reprezentant kazdego zespolu dzieki czemu bedzie mial okazje zabrac glos w sprawie design'u, sposobu testowania itp. oraz szeroko rozumianego Definition of Done (prawdopodobnie bedzie ono bardzo zblizone dla wszystkich zespolow realizujacych historie w obrebie jednego produktu).

To już u nas działa. Co prawda jeszcze nie wychodzi nam to idealnie, ale powoli się "docieramy" i efekty takich spotkań za każdym razem są coraz lepsze.

Wracajac do Stand-up'a, mysle, ze warto sprobowac codziennego Scrum of Scrums, ktory odbywa sie po 'normalnym' Stand-up'pie w kazdym zespole i na ktorym pojawia sie reprezentant kazdego zespolu, zeby zakomunikowac status, przez co inni maja pojecie co sie dzieje gdzie indziej i czy wplywa to na ich plan dnia.

Wydaję mi się, że jeżeli jedna osoba w teamie będzie odpowiedzialna za komunikację, to na obecnym etapie możemy podarować sobie tego typu spotkanie, ale przypuszczam, że w przyszłości może stać się konieczne.

Skalowanie Scruma moze okazazac sie nie lada wyzwaniem i pewnie w kazdym projekcie rozne praktyki daja rozne efekty. Niemniej, o tym czy cos zadziala prawdopodobnie dowiesz sie eksperymentujac i poprzez ciagle obserwacje stale usprawniajac proces :)

:)

Temat: Synchronizacja pracy Zespołów Scrumowych

Hejloł Seba ;)

Mamy 12 osobowy team podzielony na 4 "ścieżki".
2 osoby backend, 2 osoby aplikacja na SetTopBox, 2 osoby Web, 3 osoby poprawianie błędów i implementacja nowych rzeczy (o ile starcza czasu) praktycznie z każdego obszaru, 2 testerów, scrum master/PM.
Każda "ścieżka" mogłaby na dobrą sprawę pracować niezależnie, z konsultacjami od czasu do czasu z pozostałymi.
W razie potrzeby osoby są przenoszone do innych ścieżek i np. przez sprint czy dwa backend ma tylko 1 dedykowanego programistę.

Wspólny daily stand up meeting. Początkowo 3 minuty na ścieżkę. Aktualnie 1 minuta na osobę.
Wspólny Scrum planning meeting, retrospektywa. Wspólna JIRA, z podziałem na "ścieżki". W sumie prawie, że wszystko razem.
Jeśli któraś "ścieżka" ma dużo nowych rzeczy do omówienia z Product Owner-em to załatwiają to sami, reszta załatwia swoje rzeczy i wraca do kodowania.

Po wprowadzeniu podziału na ścieżki staraliśmy się przerzucać czasem ludzi do innych ścieżek, żeby lepiej poznali projekt (przydatne zwłaszcza w przypadku nowych osób). Teraz już się to praktycznie ustabilizowało i jeśli ktoś zmienia ścieżkę to na "Bug fixing" na jeden sprint i wraca do poprzedniej.

Wszystkie informacje na temat utrzymywania projektu itd. staramy się zapisywać w Wiki. Używamy też czasem askbot-a. Ostatnio zaczęliśmy wprowadzać Document Driven Design. Podchodzimy do tego bardzo entuzjastycznie ponieważ wszyscy odczuwają brak dokumentacji a to wydaje się najprostsza droga do tego, żeby ją w końcu stworzyć.
Innym sposobem na dzielenie wiedzy to robienie code review osobom z innych ścieżek.

Temat: Synchronizacja pracy Zespołów Scrumowych

Damian Sromek:
Mamy 12 osobowy team podzielony na 4 "ścieżki". [...]
Wspólny daily stand up meeting. Początkowo 3 minuty na ścieżkę. Aktualnie 1 minuta na osobę.

A co jeżeli Wam się team rozrośnie? I czy rzeczywiście wszystkie informacje są istotne dla wszystkich? Bo u nas nie.:) I jestem przekonany, że teamy nie wiedzą zbyt wiele na temat szczegółów pracy innych zespołów. Zdają sobie sprawę z tego, jakie funkcjonalności będą wprowadzana, ale nic ponad to . I wydaje mi się, że nie potrzeba im dużo więcej, ponieważ wiedza na temat całego produktu nadal jest aktualna, ale nie "zaśmiecona" zbędnymi (z punktu widzenia członka innego teamu) szczegółami.
Chodzi tak naprawdę jedynie o momenty, gdy współpraca musi zachodzić. I nawet nie o samą współpracę chodzi (bo ona nie kuleje), ale o informacje wymieniane pomiędzy zespołami (które w takim wypadku są istotne dla obu teamów). One czasami "gdzieś" giną po drodze.

Wspólny Scrum planning meeting, retrospektywa. Wspólna JIRA, z podziałem na "ścieżki". W sumie prawie, że wszystko razem.
Jeśli któraś "ścieżka" ma dużo nowych rzeczy do omówienia z Product Owner-em to załatwiają to sami, reszta załatwia swoje rzeczy i wraca do kodowania.

A my się dzielimy:) Jest (a właściwie zawsze było) mało rzeczy wspólnych, więc i pozostałe chcemy oddzielić, żeby skrócić czas tych wszystkich spotkań (bo trwają krócej, jeżeli w pomieszczeniu jest 5, a nie 10 osób:).

Po wprowadzeniu podziału na ścieżki staraliśmy się przerzucać czasem ludzi do innych ścieżek, żeby lepiej poznali projekt (przydatne zwłaszcza w przypadku nowych osób).

Myślałem o tym, ale praca w zespołach jest tak bardzo zróżnicowana (inne języki, inna struktura kody itp.), że byłoby to stratą czasu.

Wszystkie informacje na temat utrzymywania projektu itd. staramy się zapisywać w Wiki. Używamy też czasem askbot-a. Ostatnio zaczęliśmy wprowadzać Document Driven Design. Podchodzimy do tego bardzo entuzjastycznie ponieważ wszyscy odczuwają brak dokumentacji a to wydaje się najprostsza droga do tego, żeby ją w końcu stworzyć.

Tutaj był ten sam problem:) I muszę przyznać, że u nas sprawdziło się tworzenie dokumentacji. W wielu przypadkach naprawdę sporo czasu można zaoszczędzić:) Oczywiście jeszcze mnóstwo rzeczy pasowało by tam umieścić, ale to (mam nadzieję:) kwestia czasu.

Innym sposobem na dzielenie wiedzy to robienie code review osobom z innych ścieżek.

Próbowaliśmy, ale krótko, ponieważ review jest na tyle, że czasami ciężko nadążyć z robieniem ich ludziom we własnym zespole:)

Temat: Synchronizacja pracy Zespołów Scrumowych

Sebastian Malaca:

Damian Sromek:
Mamy 12 osobowy team podzielony na 4 "ścieżki". [...]
Wspólny daily stand up meeting. Początkowo 3 minuty na ścieżkę. Aktualnie 1 minuta na osobę.

A co jeżeli Wam się team rozrośnie? I czy rzeczywiście wszystkie informacje są istotne dla wszystkich? Bo u nas nie.:) I jestem przekonany, że teamy nie wiedzą zbyt wiele na temat szczegółów pracy innych zespołów. Zdają sobie sprawę z tego, jakie funkcjonalności będą wprowadzana, ale nic ponad to . I wydaje mi się, że nie potrzeba im dużo więcej, ponieważ wiedza na temat całego produktu nadal jest aktualna, ale nie "zaśmiecona" zbędnymi (z punktu widzenia członka innego teamu) szczegółami.
Chodzi tak naprawdę jedynie o momenty, gdy współpraca musi zachodzić. I nawet nie o samą współpracę chodzi (bo ona nie kuleje), ale o informacje wymieniane pomiędzy zespołami (które w takim wypadku są istotne dla obu teamów). One czasami "gdzieś" giną po drodze.

Jak wiesz standup nie jest po to, żeby mówić o szczegółach więc wszyscy mają raczej ogólny pogląd co się dzieje w projekcie.

Na razie nie martwimy co się stanie jak będzie nas więcej... staramy się nie rozwiązywać nieistniejących problemów ;)

Wspólny Scrum planning meeting, retrospektywa. Wspólna JIRA, z podziałem na "ścieżki". W sumie prawie, że wszystko razem.
Jeśli któraś "ścieżka" ma dużo nowych rzeczy do omówienia z Product Owner-em to załatwiają to sami, reszta załatwia swoje rzeczy i wraca do kodowania.

A my się dzielimy:) Jest (a właściwie zawsze było) mało rzeczy wspólnych, więc i pozostałe chcemy oddzielić, żeby skrócić czas tych wszystkich spotkań (bo trwają krócej, jeżeli w pomieszczeniu jest 5, a nie 10 osób:).

Po wprowadzeniu podziału na ścieżki staraliśmy się przerzucać czasem ludzi do innych ścieżek, żeby lepiej poznali projekt (przydatne zwłaszcza w przypadku nowych osób).

Myślałem o tym, ale praca w zespołach jest tak bardzo zróżnicowana (inne języki, inna struktura kody itp.), że byłoby to stratą czasu.

Wszystko zależy od kontekstu. Chciałem tylko opisać jak to u nas funkcjonuje, żeby ci w jakiś sposób pomóc. W twoim projekcie mogłoby się to nie sprawdzić, jeśli zacząłbyś robić to dokładnie tak jak my. Z resztą u nas ciągle się to też zmienia w zależności od problemów i potrzeb.

Wszystkie informacje na temat utrzymywania projektu itd. staramy się zapisywać w Wiki. Używamy też czasem askbot-a. Ostatnio zaczęliśmy wprowadzać Document Driven Design. Podchodzimy do tego bardzo entuzjastycznie ponieważ wszyscy odczuwają brak dokumentacji a to wydaje się najprostsza droga do tego, żeby ją w końcu stworzyć.

Tutaj był ten sam problem:) I muszę przyznać, że u nas sprawdziło się tworzenie dokumentacji. W wielu przypadkach naprawdę sporo czasu można zaoszczędzić:) Oczywiście jeszcze mnóstwo rzeczy pasowało by tam umieścić, ale to (mam nadzieję:) kwestia czasu.

Innym sposobem na dzielenie wiedzy to robienie code review osobom z innych ścieżek.

Próbowaliśmy, ale krótko, ponieważ review jest na tyle, że czasami ciężko nadążyć z robieniem ich ludziom we własnym zespole:)

Tak. Code review zaczyna być "problemem", kiedy ludzie zaczynają intensywnie coś wrzucać po tym jak się zorientują, że to zaoszczędza im dużo problemów w przyszłości ;D

Temat: Synchronizacja pracy Zespołów Scrumowych

W przypadku naprawdę sporej liczby zespołów odpowiedzią mógłby być Scrum of Scrums. Z każdego zepsołu wybierana jest jedna osoba która reprezentuje go na normalnych wszystkich spotkaniach, czyli review, retro planning i oczywiście daily scrum. Na takim daily scrumie należałoby zadać pytania standardowe:

1) Co Twój zespół zrobił od ostatniego spotkania?
2) Co zrobi do następnego spotkania?
3) Czy jest coś blokującego?
i dodatkowe
4) czy jest coś, co może wejść w paradę innemu zespołowi.

Oczywiście taki scrum scrumów musi mieć PO i Scrum Mastera :)

To może działać w przypadku większej ilości zespołów. W przypadku 2-3 myślę, że jeden PO z dobrze zorganizowym backlogiem, niezależnymi user storiesami (ogólnie INVESTowanymi) i dobrą komunikacją pomiędzy zespołami mógłby to ogarnąć. Oczywiście testy integracyjne tutaj grałyby dużą rolę.

Temat: Synchronizacja pracy Zespołów Scrumowych

W firmie mamy dwa zespoły (po ok 6-7 osób). Zespoły pracują w róznych strefach czasowych (ale to inna sprawa). Mamy jeden wspólny Product Backlog. Oto jak to u nas działa:

1. Oczywiście osobne Daily Meetings - to, że pracujemy nad jednym product backlogiem nie znaczy, że powinno się robić wspólne daily meetings. Spotkania te mają służyć Twojemu zespołowi.

2. Raz w tygodniu Scrum of Scrums (było to dobrze opisane przez poprzedników)

3. Mamy jeden Product Backlog w Jirze. Każde user story ma ustawiony label w stylu "zespół 1", "zespół 2". Na podstawie labeli mamy ustawione filtry. Przedstawiciele zespołu spotykają się co jakiś czas aby ustalić, który zespół bierze które user story. W tego typu sptokaniu może brać udział więcej osób. Jest to dobry sposób aby wspólnie omówić sytuację i zrozumieć dokąd zmierza projekt.

4. Na podstawie jednego Product Backloga tworzymy dwa osobe sprinty. Sprinty MUSZĄ kończyć się w tym samym czasie. Pracujemy nad jednym produktem dlatego Sprint Review robimy wspólnie.

5. Backlog grooming robimy osobno.

I to chyba tyle.

Temat: Synchronizacja pracy Zespołów Scrumowych

U nas jest tak, może to będzie jakaś inspiracja:

1 produkt, 1 backlog, 1 zespoł (co bardzo ważne) SCRUMowy podzielony na 2 podzespoły (A, B), które pracują niezależnie, ale mają między sobą zależności:) - tego nie pomalujesz. Sprinty na tą chwilę są dwutygodniowe "na mijankę" - czyli krótko mówiąc rytuały są co tydzień w układzie (A, B, A, B....). Sytuacja taka jest od kwietnia br. Zespół rósł, rósł przez 2 lata, aż w końcu coś trzeba było z tym zrobić. Tak więc ludzie się znają z pracy w jednym zespole SCRUMOwym, to po pierwsze jeśli chodzi o ułatwienia w wymianie wiedzy.

Po drugie na demo zespołu A przychodzi zespół B i vice wersal (45 minut raz tygodniu - niewiele)
Po trzecie w groomingach zespołu B uczestniczy zespół A i vice wersal (jakieś 3h na tydzień - niewiele)
Po czwarte zespół A zaprasza na code review zespół B (znowu niewiele czasu)
Po piąte zespoły A i B mają wspólny backlog, produkt i kod - wbrew pozorom to daje dużo wiedzy o postępie.
Po szóste zespoły A i B mają wspólnego SM, który naprawdę daje radę.
Po siódme siedzimy na jednym open space, więc część wiedzy wymienia się mimochodem. Mamy do siebie blisko, można powiedzieć "słyszymy się" na co dzień. Daily standup odbywa się w jednym miejscu jeden zespół po drugim - więc o najważniejszych rzeczach dowie się kto ma się dowiedzieć.
Po ósme, dorośliśmy chyba, albo raczej dorastamy do tego jaką rolę w tym wszystkim powinny pełnić dobre testy.
Po dziewiąte ludzie z A robią np. crosstesty ludziom z zespołu B.

Czy ktoś powinien być za to odpowiedzialny? Cudownie byłoby, gdyby wszystkim na tym zależało.
Nie mówię, że jest super zielono. Mamy na pewno swoje problemy, bo chciałoby się więcej i lepiej i być "superniezależną" podgrupą A i B...

Jak to się rozrośnie? Nie wiem. Może trzeba będzie robić jeszcze SCRUM of SCRUMs, wymyśleć jeszcze inne rozwiązania (na razie jest tego trochę...).

Temat: Synchronizacja pracy Zespołów Scrumowych

U nas niestety zespoły nie znajdują się już w tym samym pomieszczeniu. Dopóki tak było, to raczej nie było większych problemów, ponieważ, tak jak napisałeś, wiedzę wymieniało się mimochodem. Od kiedy jednak jedna z drużyn przeniosła się na wyższe piętro, to owa wymiana wymaga już jakiejś organizacji.

Świetny pomysł z tymi crosstestami. Wyobrażam sobie, że coś takiego rzeczywiście jest gwarancją, że wiedza na temat tego, co się dzieje z produktem nigdzie nie ucieka.
Niestety u mnie się nie sprawdzi, ponieważ zespoły różnią się również pod względem wykorzystywanych języków programowania, co może być (dla niektórych) problemem. Wynikającym raczej z niechęci do innych technologii niż z braku umiejętności (czyli tym trudniejszym). I to może być coś nie do przeskoczenia.

Mimo wszystko jednak uważam, że jest to naprawdę dobry pomysł i z pewnością kiedyś wypróbuję:)Sebastian Malaca edytował(a) ten post dnia 09.11.12 o godzinie 10:38