• Lis : 09 : 2013 - Wstępniak
  • Lis : 09 : 2013 - Dziel i zwyciężaj ...bądź scalaj i zwyciężaj
  • Gru : 15 : 2013 - Doomsday is coming
  • Sty : 15 : 2014 - Ramzes umarł, Kryzys żyje
  • Sty : 24 : 2014 - "Dupa" na tablicy
  • Lut : 20 : 2014 - Zarządzanie czasoprzestrzenią
  • Maj : 15 : 2014 - Stosunek przerywany, czyli strzelając z biodra w architekturę

Featured articles

"Zarządzanie czasoprzestrzenią" - czyli kilka porad dotyczących harmonogramu zdarzeń SCRUM'owych Czytaj ...

Doomsday clock - czyli o tym jak mój zespół monitoruje dług techniczny i pokochał zagładę Czytaj...

"Stosunek przerywany, czyli strzelając z biodra w architekturę" - czyli słów kilka o groomingach Czytaj ...

"Dupa" na tablicy

Posted by pOtrek - 0 komentarze



Fizyczne tablice rządzą


Większość z nas, praktyków arkan SCRUMowych, używa SCRUM board’ów jako reprezentacji Sprint Backlogu. Część korzysta z tablicy „analogowej”, powieszonej gdzieś w pokoju, część cyfrowej w postaci jakiegoś toola (np. JIRY). Ja osobiście jestem wielkim zwolennikiem tych pierwszych, ponieważ:
    • Stanowią naturalny punkt „zbiórki” dla zespołu, gdy trzeba przedyskutować plan działania,
    • Są niezastąpione podczas Daily Scrum’a i stanowią idealne tło dyskusji (wszyscy wiedzą, o czym mowa, mogą pokazać na karteczkę z konkretnym zadaniem, mogą wreszcie przejrzeć swoje karteczki, aby przypomnieć sobie nad czym ostatnio pracowali),
    • Wystarczy oderwać oczy od klawiatury, aby zorientować się w postępie prac (zamiast szukać odpowiedniego tab’a w przeglądarce),
    • Są zdecydowanie bardziej „elastyczne” niż jakikolwiek inny system elektroniczny,
    • Jest coś przyjemnego w „ręcznym” przesuwaniu karteczek… poważnie J

Powiem szczerze, że ciężko mi sobie wyobrazić porządny Daily Scrum bez tablicy. No chyba, że z gigantycznym ekranem dotykowym J W sytuacji, gdy macie w zespole kilka osób „zdalnych” możecie utrzymywać jednocześnie tablicę analogową i cyfrową. Te kilka minut dziennie potrzebne na zsynchronizowanie tablic wydaje mi się śmiesznie małą ceną za wszystkie zalety fizycznych tablic, które wymieniłem powyżej (możecie również spróbować takiego toola: http://jimflow.jimdo.com).

Elastyczna tablica, czyli nie bój się kolorów


W dalszej części tego prosta chciałbym poruszyć temat „elastyczności” fizycznych tablic. SCRUM board nie musi wyglądać jak tabelka z kolumnami TODO, In Progress, Done, na której przyczepione są żółte karteczki. Macie cały zestaw wspaniałych narzędzi, które uczynią wasz product backlog bardziej czytelnym i przyjemniejszym w użyciu. Pamiętajcie, że karteczki typu post-it są dostępne w różnych kolorach, kształtach i rozmiarach. Wykorzystajcie to!! Pamiętajcie także, że możecie również skorzystać z wszelkiego rodzaju magnesów z obrazkami, naklejek, wydruków, żetonów z gry, odznak, awatarów, zdjęć, korowych taśm klejących, zakładek do książek, markerów… słowem jakichkolwiek przyborów papierniczych jakie wpadną wam w ręce. Ciekawy przykład: mój zespół potrzebował czegoś by oznaczać zadania  przy realizacji których pojawił się problem/blocker. Mieli do dyspozycji tylko „zwykłe” karteczki typu post-it oraz karteczki przylepne w kształcie serduszka, gwiazdki i księżyca. Żadna z nich nie specjalnie kojarzy się z problemem. Co zrobili? Wzięli serduszka przywiesili je do góry nogami i stwierdzili że od teraz symbolizują one „dupę” J. Na każdej takiej „dupie” pisali w kilku słowach na czym polega problem. Poniżej znajdziecie listę różnych sposobów modyfikacji zwykłej, szarej i nieatrakcyjnej tablicy SCRUMowej w użyteczną, czytelną i „fajną” jej wersję. Pomysły zaczerpnąłem z koncepcji, które stosujemy lub stosowaliśmy w naszym zespole jak i z podpatrzonych wśród innych zespołów.
·         Oznaczanie User Story kolorami – wszystkie zadania związane z jednym User Story zapisujcie na karteczkach w tym samym kolorze. Każde User Story (US) w ramach jednego Sprintu powinno mieć inny kolor. Dzięki temu dużo łatwiej ocenić ile zadań zostało do wykonania w ramach różnych US oraz widać nad jakimi US zespół aktualnie pracuje,
·         Wysokość US na tablicy określa jego priorytet w sprincie – US umieszczone najwyżej na tablicy mają najwyższy priorytet. Zespół (w ramach rozsądku) powinien zacząć pracę „od góry” tablicy i kontynuować „w dół”. Dzięki temu zmniejszy się ryzyko niedostarczenia kluczowych US,
·         Dodatkowe znaczniki na kartkach z zadaniami – stosuj znaczniki aby sygnalizować „specyficzne” statusy związane z zadaniami. Poza wspomnianą wcześniej „dupą” w naszym zespole stosowaliśmy również magnesiki z nadrukami, które używaliśmy do oznaczania następujących statusów: zadanie zblokowane, zadanie nie idzie zgodnie z planem, zadanie idzie bardzo źle, FUBAR. Magnesiki z własnymi „nadrukami” możecie zamówić za parę złotych na allegro,
·         Awatary reprezentujące członków zespołów – zamiast pisać kto wykonuje dane zadanie można przy tym zadaniu umieszczać wydruk awatara reprezentującego konkretnego developera. Awatary możecie zrobić tu, tu, tu lub skorzystać z tej listy,
·         Zasygnalizować maksymalną ilość zadań nad którymi zespół może równolegle pracować – czyli po ludzku WiP limit dla kolumny In progress. Można zrobić to na wiele sposobów: napisać w nagłówku kolumny jaki jest WiP limit, narysować miejsca na karteczki (tylko tam można umieszczać zadania), fizycznie ograniczyć ilość miejsca w kolumnie In progress.
·         Wielkość karteczki z zadaniem odpowiada wielkości zadania – tego jeszcze nie spróbowaliśmy w praktyce ale wydaje się być ciekawą koncepcją J

Zachęcam do eksperymentowania z waszymi Sprint Backlogami. Pamiętajcie tylko, że nadrzędnym celem jest zwiększenie jego czytelności, a nie zrobienie go bardziej zbajerowanym.

Nasz Sprint Backlog





W naszym zespole do realizacji Sprint Backloga używamy białych tablic. Na tablicy z lewej strony wieszamy kartki (formatu A5) reprezentujące User Stories, w kolejności od góry do dołu (na górze są najbardziej priorytetowe US). Obok US umieszczamy zadania. Wszystkie zadania dotyczące jednej US są napisane na kartkach tego samego koloru. Zadania uporządkowane są od prawej do lewej strony, czyli najbliżej kolumny In progres znajdują się te, które najwcześniej będziemy robić. Kartka z zadaniem wygląda następująco:





Dodatkowo, gdy zadanie jest gotowe do review, wpisujemy na niej literkę R, a obok niej osobę która zgłosiła się, aby wykonać Review. Nasz Spritnt Backlog ma tylko 3 kolumny: TODO, In progres i Done. Nie mamy kolumny Review oraz Test (często spotykanej w innych zespołach). Zamiast stanu Test mamy zadania typu Test. Powód jest prosty: testujemy funkcjonalności, a nie poszczególne zadania (typu dodaj kolumnę do bazy danych).


Ramzes umarł, Kryzys żyje

Posted by pOtrek - 0 komentarze


Nasz proces deploymentu


Apokaliptycznych wizji ciąg dalszy. Jak wspomniałem we wstępniaku, proces deploymentu nowych funkcjonalności jest dość skomplikowany. SCRUM’em objeliśmy jedynie fazę developmentu i testów na środowiskach developerskich. Reszta procesu wygląda (w pewnym uproszczeniu) mniej więcej tak:


Dla tych którym nie chce się zagłębiać w powyższy diagram lista co ciekawszych właściwości procesu:
  1. Proces skomplikowany i przejście go trwa bardzo długo (średnio około miesiąca),
  2. Przez proces przepływają nowe wersje komponentów, a nie funkcjonalności (jedna funkcjonalność może wymagać zmiany w kilku komponentach),
  3. Spora część procesu znajduje się poza bezpośrednią kontrolą zespołu,
  4. Po stronie organizacji klienta istnieje trylion różnych zespołów IT, nad którymi nasz klient (sponsor, PO, zespół biznesowy) nie ma bezpośredniej kontroli (znajdują się w innym pionie organizacji).

Problem


Teraz najwyższa pora opisać jak to wyglądało w praktyce. Otóż przez proces przepływała olbrzymia ilość zgłoszeń o deploy komponentów. Część z nich utykała w różnych miejscach procesu, część  w ogóle ginęła w niewyjaśnionych okolicznościach, części nie udało się zainstalować z powodu braku innych komponentów, od których były zależne, wreszcie część jakimś cudem udawało się „przepchnąć” na środowisko produkcyjne. W tym ogólnym galimatiasie co jakiś czas zespół biznesowy ni stąd, ni zowąd rzucał jakąś datą: np. funkcjonalność XYZ ma być gotowa za tydzień bo umówiliśmy się z klientem na testy. Oczywiście funkcjonalność, mimo że gotowa od strony developerskiej, znajdowała się w bliżej nieokreślonym stanie w procesie deploymentu. Jednym słowem KRYZYS. W takich przypadkach zbieraliśmy sztab kryzysowy, zakasaliśmy rękawy i do roboty!! A robota polegała na szaleńczym „przepychaniu” zgłoszeń wszelkimi możliwymi sposobami… co oczywiście przynosiło skutek odwrotny od oczekiwanego i funkcjonalność „przechodziła” przez proces deploymentu jeszcze dłużej. Ramzes umarł, kryzys żyje!!!

Rozwiązanie


Ktoś mógłby powiedzieć, że fundamentalnym problemem jest tutaj „zasięg” SCRUM’a, który nie obejmuje procesu deploymentu. Niestety, mimo że takie podejście pozwoliło by nam rozwiązać większość wymienionych powyżej problemów, w naszym przypadku nie jest możliwe do zastosowania. Przeszkodami są tutaj:
  1. Zespół developerski nie ma kontroli nad sporą częścią procesu, 
  2. Proces trwa bardzo długo, a z powodu opisanego w punkcie 1. zespół developerski nie ma możliwości skrócenia go,
  3. Wydłużenie sprintów tak, aby mogły objąć development + deployment nie wchodzi w grę z powodu dużej dynamiki biznesu klienta (cały czas coś się zmienia, a długie, miesięczne sprinty spowodowałyby nieakceptowalną dla zespołu biznesowego „bezwładność” funkcjonalności).

Debatując nad problemem doszliśmy do wniosku, że w naszej sytuacji najistotniejszą rzeczą, jaką musimy zrobić, jest opanowanie chaosu. Wszyscy muszą mieć wyraźny wgląd w aktualną sytuację, jaka panuje w procesie deploymentu. W świecie Lean Managementu istnieje oczywiście rozwiązanie naszego problemu i nazywa się Visual Management. Dodatkowo aby ułatwić wdrożenie nowego rozwiązania oraz uczynić go atrakcyjniejszym dla zespołu postanowiłem „ubrać go w szaty” zabawy. I tak powstała gra planszowa „Kryzys”. 


Czym jest gra planszowa „Kryzys” ?


Jest to pewna wariacja tablicy Kanbanowej (nie mylić z tablicami często wykorzystywanymi w SCRUM’ie do realizacji Sprint Backlogu), która reprezentuje nasz proces deploymentu. Przez pola przedstawiające poszczególne kroki procesu, wędrują żetony funkcjonalności (a nie tak jak do tej pory komponenty). Jednak w porównaniu do typowej tablicy Kanbanowej posiada ona kilka innych elementów. Są to:

  • Żetony „Kryzysu” (reprezentowane przez bombę atomową) – jeśli widzimy zagrożenie, że dana funkcjonalność może nie „przejść” procesu deploymentu na czas przypinamy do niej żeton „Kryzysu”,
  • Pole z Datami – które reprezentują daty dostarczone przez klienta,
  • Punktację dla graczy biorących udział w grze.

Nasza tablica wygląda mniej więcej tak:


Tura gry „Kryzys” odbywa się codziennie o stałej porze (za wyjątkiem dni planningów) i bierze w niej udział delegacja z zespołów: developerskiego, testerów i IT.

Gorąco zachęcam też do zapoznania się z instrukcją do gry, którą znajdziecie w pliku poniżej:

Instrukcja do gry "Kryzys"

Problemy Wyzwania


Visual Management pomógł nam opanować chaos, a przedstawienie pomysłu jako gry planszowej uczyniło to rozwiązanie atrakcyjnym dla zespołu. Należy jednak pamiętać, że dla developerów zarządzanie procesem deploymentu to zło konieczne, którym najchętniej w ogóle by się nie zajmowali. Dlatego z czasem entuzjazm w zespole osłabł, jako ScrumMaster musiałem (!?) pilnować, aby spotkania kryzysowe odbywały się regularnie, frekwencja również bardzo zmalała. Problemem również okazało się  wyciąganie (a właściwie to wydzieranie) dat i terminów od zespołu biznesowego. Niemniej jednak przedsięwzięcie uważam za bardzo udane… wprowadziliśmy je półtora roku temu i wciąż działa. Pomogło nam też zapobiec wielu poważnym  kryzysom.

Przyszłość

Dlaczego nie zastosowaliśmy Kanbana? Odpowiedź jest prosta: tak jak SCRUM, Kanban jest koncepcją prostą do zrozumienia, lecz trudną do stosowania, szczególnie dla zespołu biznesowego osadzonego w rzeczywistości korpo(racji). Gra „Kryzys” pozwoli na łagodne „wejście” w świat Kanbana… świat w stronę którego zmierzamy (przynajmniej w kwestii deploymentów, ponieważ oczywiście ze SCRUMa nie rezygnujemy). W tym momencie, gdy zaczniemy wprowadzać np. WiP limity, każdy zrozumie dlaczego to robimy. W końcu wielokrotnie podczas gdy w „Kryzys” widział jak ten czy tamten krok procesu korkuje się powodując znaczne utrudnienia dla wszystkich deploymentów.

Wyciągnięte lekcje


  1.  W firmie/projekcie zmiany wprowadza się trudno i mozolnie. Dotyczy to szczególnie projektów, które mają styczność z rzeczywistością korpo(racyjną)
  2. Nie oznacza to, że nie warto próbować. Jeśli nie możesz przeskoczyć problemu to spróbuj go obejść
  3. Zmiany wprowadzaj małymi kroczkami (nie wszystko naraz)
  4.  Zespół zaadaptuje zmiany szybciej, jeśli spróbujesz ją uczynić dla nich … po prostu fajną (fun factor !!!)
  5. „Krzywa nauki” będzie mniej stroma, jeśli upewnisz się, że:
    1. Wszyscy wiedzą, dlaczego wprowadzamy zmianę / nowy element procesu
    2. Zasady są jasne i przejrzyste
  6. Przygotuj się na to, że w wypadku zmian typu „zło konieczne” zapał z czasem osłabnie.
  7. W świecie Agile poza SCRUM’em istnieją też inne frameworki. Większość z nich ma tą ciekawą właściwość, że nie wykluczają się nawzajem, lecz raczej uzupełniają (najczęściej stosowany mix to SCRUM + XP, ale nie jest to jedyna możliwość)



Doomsday is coming

Posted by pOtrek - 0 komentarze

Geneza problemu


Jednym z problemów, z którym boryka się mój zespół, jest dług technologiczny. System tworzony jest od kilku lat, w między czasie znacząco zmienił się jego zakres (łącznie z docelowym przeznaczeniem), oryginalny skład zespołu … czyli innymi słowy sporo „legacy code’u” i „ciekawej” (czytaj pokręconej) architektury. Gdy poruszyliśmy temat długu technicznego na retrospekcji okazało się, że pierwszym krokiem w celu poprawy sytuacji powinno być w jakiś sposób monitorowanie sytuacji. Tylko jak ? Narzędzia do statycznej analizy kodu (Sonar, checkstyle, fxcop) dają jakiś taki pogląd na jakość kodu ale to nie wystarczy. Nie są w stanie zobrazować sytuacji na poziomie architektury, nie wyłapią „quickfixów” i co bardziej kreatywnych „obejść problemów”.


Rozwiązanie


Wtedy wpadliśmy na pomysł Doomsday clock’u. Jest to koncepcja wymyślona w 1947 roku na Uniwersytecie Chicagowskim. Pomysł jest bardzo prosty: przy pomocy zegara przedstawić jak daleko jesteśmy od totalnej zagłady ludzkości w wyniku wojny nuklearnej. Gdy wybije północ rozpocznie się judgement day. Każde istotne wydarzenie (np. pakt rozbrojeniowy) zapisywane jest w rejestrze zegara, a jego wskazówki przesuwane są do przodu lub do tylu w zależności od tego czy skutki zdarzenia były pozytywne czy negatywne. Więcej o Doomsday clock tutaj: http://pl.wikipedia.org/wiki/Zegar_Zagłady
Pomysł więc był prosty: monitorować dług technologiczny przy pomocy naszej wersji Doomsday clock’a.

   

Jak zrobić Doomsday clock


  1. Kup najprostszy, najtańszy zegar ścienny (analogowy, nie cyfrowy ;) )
  2. Jeśli zegar ma szybkę to ją zdemontuj
  3. Dla zwiększenia efektu, podmień tarczę zegara na taką która w tle ma jakiś apokaliptyczny zegarek (my wydrukowaliśmy ją na kartce A4, wycięliśmy i wstawiliśmy do zegara)
  4. Zadbaj o to aby wskazówki były jak najbardziej widoczne (my obkleiliśmy końcówki wskazówek jaskrawym papierem kolorowym)
  5. Powieś zegar w pokoju w którym pracujecie
  6. Pod zegarem powieś dużą kartkę papieru na rejestr zegara (świetnie do tego nadaje się folia/tablica samoprzylepna http://styl-sklep.pl/biala_tablica_samoprzylepna,257,5177.html#.Uod-uFyoF0o)
  7. Gotowe !
U nas wygląda to tak:






Pytania i odpowiedzi


Dlaczego wybraliście akurat taką formę monitorowania długu technologicznego ?
Bo jest fajna :) Poważnie ! To jest bardzo istotny czynnik. Zespół dużo chętniej robi coś co sprawia mu przyjemność (nawet w odniesieniu do tak nieprzyjemnej rzeczy jak dług technologiczny)
Czy zegar przedstawia „twarde, statystyczne dane” ?
Oczywiście że nie. Zegar bazuje na intuicji zespołu. A intuicja przeważnie ma dużo więcej wspólnego z rzeczywistością niż twarde dane statystyczne :)
Czy pokazujecie zegar swojemu klientowi ?
Tak. Wytłumaczyliśmy koncepcję klientowi i zegar stanowi integralną część raportów prezentowanych Product Owner’owi. Oczywiście nie obyło się bez pytań typu ”a nie dało by się zaprezentować tego  „bardziej konkretnie” np. w postaci Story Pointów ?”
Na którą godzinę ustawić początkową wartość zegara ?
Koncepcja Doomsday clock opiera się na subiektywnej ocenie sytuacji. Nie ma tutaj jednoznacznej odpowiedzi. Im bliżej północy zaczniecie tym bardziej podkreślicie powagę sytuacji.
O ile zmieniać wskazania zegara ?
Tak jak przy odpowiedzi na poprzednie pytanie -  nie ma tutaj konkretnej zasady. Jeśli korzystacie przy estymacjach ze Story Point’ów dość łatwo do tego dojdziecie. Story Point’y określają relatywną wielkość funkcjonalności, zmiany wskazań zegara określają relatywny wpływ zdarzeń podczas sprintu na gromadzenie lub likwidowanie długu technicznego. Dla ułatwienia możecie zrobić sobie przykładowy „cennik” który posłuży wam jako punkt odniesienia.
Co to jest sprint drift ?
Podczas jednej z retrospekcji doszliśmy do wniosku, że w sytuacji, gdy podczas sprintu nie zrobiliśmy nic co wpływa na dług technologiczny (ani nic nie zepsuliśmy, ani też nie naprawiliśmy), tak naprawdę sytuacja się pogarsza. Powód: doszły nowe funkcjonalności, które trzeba utrzymać, a stary zakumulowany dług technologiczny tak jak bomba zegarową… wciąż tyka. Dlatego po zakończeniu tworzenia rejestru zegara na dany sprint dodatkowo przesuwamy wskazówkę zegara o stały interwał do przodu (w stronę północy)
Kiedy aktualizować Doomsday clock ?
Kiedy chcecie, ważne aby uczestniczył w tym wydarzeniu cały zespół. Możecie zrobić to podczas retrospekcji lub na osobnym, krótkim spotkaniu (najwygodniej umieścić je gdzieś między spotkaniami typu retrospekcja, sprint planning)


Inne zegary


Oczywiście koncepcję zegara możecie wykorzystać również na inne sposoby. Zespoły które uczestniczą w yourdon’owskim „Marszu ku klęsce” mogą rozszerzyć zegar do wszystkich zdarzeń mających kluczowe znaczenie dla projektu. Wówczas północ oznacza FUBAR (Fucked Up Beyond All Recognition/Repair). Zegar może również posłużyć jako wskaźnik nastroju zespołu lub nawet status prac nad całym projektem (godzina 12 – projekt został ukończony).  

Dziel i zwyciężaj… bądź scalaj i zwyciężaj

Posted by pOtrek - 0 komentarze


Gdy dołączyłem do zespołu półtora roku temu jedną z pierwszych rzeczy, która zwróciła moją uwagę, były Daily Scrum’y. Wszystkie osoby uczestniczące w projekcie (a było ich 17) ustawiały się w kółku, które z powodu wielkości zespołu, zajmowało cały pokój. Następnie każdy recytował odpowiedzi na trzy pytania: „Co robił wczoraj ?” , „Co będzie robił dzisiaj” i „Czy ma problemy?”. A te odpowiedzi wyglądały mniej więcej tak: „Wczoraj pracowałem na ticketem XYZ, dzisiaj nadal będę pracował nad ticketem XYZ, problemów nie mam”. Gdy pojawił się problem cały zespół nad nim dyskutował. Po kilku takich spotkaniach uświadomiłem sobie że:
  • Daily SCRUM’y strasznie się przedłużają. Zajmowały często ponad 30 minut
  • Po zakończeniu spotkania tak naprawdę nie mam pojęcia co się dzieje w Sprincie
  • Członkowie zespołu byli zmęczeni i znudzeni („no nieeee… znowu Standup. Muszę na niego iść ?”)
  • Poszczególni developerzy koncentrowali się na wąskich obszarach (swoich ticketach)

Aby potwierdzić moje obserwacje na końcu Daily SCRUM’a zacząłem zadawać niezręczne pytania typu: „Jasiu co dzisiaj będzie robił Krzysiu ?”, „Małgosiu jak idzie Jasiowi ?”, „Ludziska czy dowieziemy cały commitment ?”. Większość odpowiedzi potwierdzały moje przypuszczenia… coś było nie tak.
Zacząłem kombinować jak można byłoby zwiększyć efektywność Daily SCRUM’ów, lecz za chiny ludowe nie mogłem wymyślić jak tego dokonać przy tak dużej ilości osób w zespole. I nagle uświadomiłem sobie, że kluczowym elementem jest właśnie ta „duża ilość osób”. Rzecz wydawałoby się oczywista, lecz jak to często bywa, ciężka do zauważenia wśród nawarstwienia innych problemów. Zacząłem więc zastanawiać się nad podziałem zespołu. Pojawiły się dwa problemy. Pierwszym z nich było wymyślenie jak to zrobić. Najpopularniejszą techniką jest oczywiście „Scrum of Scrums”. Słyszałem jednak wiele negatywnych opinii na jej temat i nie byłem przekonany, czy sprawdzi się w naszym przypadku. Drugim problemem był strach. Zespół współpracował z sobą przez długi czas i był ze sobą zżyty. Nie pomagała też spora liczba publikacji które przeczytałem i opisywały zjawiska typu „synergia zespołu” i „team glue”. Właśnie wtedy w moje ręce wpadła książka Craiga Larmana „Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”. Opisywał on  w niej ciekawe podejście do tego problem, które prezentuje obrazek poniżej. 

Na retrospekcji przedyskutowałem problem z zespołem i razem ustaliliśmy nasz wariant implementacji tego modelu. Wygląda on następująco:
  1. Mamy jednego Product Ownera i jeden Product Backlog. Sprint Planning I przeprowadzamy razem jako jeden zespół
  2. Po Sprint Planningu I dzielimy się na 2-3 zespoły. Dostosowujemy wielość i skład zespołów do User Stories, które potencjalnie chcemy zrobić w tym sprincie (te informacje mamy z SP I)
  3. Rozdzielamy User Stories na zespoły
  4. Każdy zespół przeprowadza swój własny Sprint Planning II i posiada swój własny Sprint Backlog 
  5. Jest jeden Scrum Master  dla wszystkich zespołów
  6. Każdy zespół ma swoje własne Daily Scrumy. Członkowie innych zespołów mogą „wpaść z wizytą” na Dialy Scrumy innych zespołów (jako kurczaki)
  7. Demo i Retrospekcje przeprowadzamy wspólnie
  8. Przy groomingu dzielimy się na zespoły, lecz nie muszą to być te same zespoły które realizują aktualny Sprint
  9. Wprowadzamy rolę Feature Owner’a (FO). Jest to stricte techniczna rola odpowiednik technical team leadera ograniczona do jednego obszaru systemu.

Jak widać nie wykorzystaliśmy bezpośrednio modelu przedstawionego przez Larmana, lecz wprowadziliśmy
nasze własne zmiany, aby lepiej dostosować go do naszych realiów. Najważniejsze z nich to:  
  • Zostawiliśmy tylko jednego Scrum Mastera, aby zwiększyć efektywność prac. Łączenie roli SM z rolą Developera w naszym przypadku to kiepski pomysł, ponieważ kontakty z zespołem biznesowym miały tendencję do zabierania 100% czasu osoby zaangażowanej. SM zaczął stanowić filtr pozwalający zespołowi wykonywać swoją pracę bez ciągłych „przeszkadzajek” ze strony zespołu biznesowego.
  • Dynamicznie zespoły zmieniające się co sprint pozwoliły nam zachować integralność zespołu (prędzej czy później każdy będzie pracował z każdym) oraz lepiej dostosować się do planów Product Ownera przedstawionych na Sprint Planningu I
Oczywiście nie ma róży bez kolców. Przy podziale na zespoły narzuciłem pewne ograniczenia:
  •  Zespół musi liczyć minimum 3 osoby
  • Zespół musi siedzieć razem w jednym pokoju (nasz projekt ma do dyspozycji dwa pokoje)
Kontrowersje budził szczególnie ten drugi punkt. Na początku trudno było „odkleić” niektóre osoby od miejsc na których siedziały przez ostatni rok.  Nie pomagały również procedury firmowe, które wymagały formalnego przekazywania kluczy do pokoi z podpisaniem oficjalnego „świstka” (a.k.a. protokołu zdania i odbioru). Prowadziło to na początku do kłótni, które trwały czasem ponad godzinę zanim zespół się podzielił. Poruszyliśmy ten temat na retrospekcji i cały zespół ustalił następujące rozwiązanie: gdy po 15 minutach nie udaje się stworzyć zespołów (i co ważniejsze miejsc siedzenia :P ) jedna osoba arbitralnie ustala podział (ten „zaszczyt” przypadł mnie).   I powiem szczerze, że od tamtej retrospekcji bardzo rzadko musiałem interweniować.
Na koniec inna sytuacja związana z podziałem zespołów. Jakiś czas temu na korytarzu zaczepił mnie kolega z pracy, który prowadzi dwa małe projekty. Zapytał mnie w jaki sposób powinien zorganizować product baclogi tych projektów, aby mieć większą kontrolę nad nimi. Zaproponowałem, aby połączył oba backlogi w jeden. On jednak poszedł o krok dalej i połączył zarówno backlogi jak i zespoły (liczące 2-3 osoby). Po jakimś czasie stwierdził, iż było to tak naturalne rozwiązanie, że aż dziw bierze że nie wpadł na to wcześniej. Teraz ma większą kontrolę nad projektem, lepszy przepływ wiedzy między ludźmi oraz potencjalnie mniejsze problemy w okresie wakacyjnym.

Z opisanych sytuacji ja wyciągnąłem następujące lekcje:
  • Warto zastanowić się nad strukturą zespołu. Czy odpowiada aktualnej sytuacji w twoim projekcie?
  • „Najciemniej pod latarnią” . Czasem potencjalnie najbardziej oczywiste rozwiązania są najtrudniejsze do zauważenia
  • Strach przed zmianą jest jednym z największych wrogów zwinności
  • Techniki i metody opisywane w różnych źródłach (książkach, artykułach, blogach ;)) niech będą dla Ciebie inspiracją a nie procedurą postępowania. Nie bój się eksperymentować.

Wstępniak

Posted by pOtrek - 0 komentarze

O czym jest ten blog ?


Witajcie drodzy czytelnicy.
Tytuł tego blogu w dość pokrętny ;) sposób oddaje dwie najważniejsze koncepcje, które będą osią opisywanych przeze mnie zagadnień.