blog.testowka.pl

Archiwum wiadomości z Kwiecień, 2015

Jak radzić sobie z Timeboxami?

opublikowany przez 28, Kwi, 2015, w kategoriach Agile, Scrum

clock-248718_640
Podczas jednego z realizowanych przeze mnie projektów coachingowych (Agile Coaching) pojawił się problem z timeboxami. Poniżej kilka fragmentów maila jaki przysłała Scrum Master zespołu.
Z jednej strony fajnie, że się (developerzy) angażują i widzą pewne problemy w zespole (…) Nie chcę przerywać komuś kto odważył się włączyć do dyskusji w połowie zdania, bo wiem, że każdy tak naprawdę dojdzie do sedna tego co chciał powiedzieć. Ale z drugiej strony fakt, że nie jestem w stanie przewidzieć kto w kwestii danego problemu się odezwie i ile zajmie mu wypowiedź sprawia, że Retrospekcje strasznie się przeciągają – czasem nawet o półtorej godziny!
Tak, przedłużanie spotkania o półtorej godziny to faktycznie problem. Twórcy Scrum tworząc ten framework zadbali o to, by każdy artefakt i spotkanie miały określony cel, który jest ważniejszy od samego sposobu  przeprowadzania tego spotkania czy implementacji danego artefaktu. Wprowadzenie ram czasowych jest też nie bez znaczenia – w ten sposób jesteśmy w stanie w efektywnie zarządzać naszym czasem. Mając jasno określony cel – to co chcemy mieć po wyjściu ze spotkania i ramy czasowe pozostaje nam jedynie wymyślenie efektywnego sposobu osiągnięcia celu w zadanym czasie.
Jak sobie zatem radzić z problemem przedłużających się spotkań – oto co było w dalszej części maila:
Nie mamy pomysłu co można by jeszcze zmienić. Do tej pory staraliśmy się zoptymalizować:
– przygotowanie planu spotkania (w miarę możliwości)
– wybieranie najważniejszych problemów (które mają odpowiednią ilość głosów innych członków zespołów)
– moje przypominanie ile jeszcze zostało do końca spotkania (ile mamy czasu)
I o ile dochodzimy do postanowień i wszystkie cele tego spotkania są spełnione, to jednak nie jesteśmy w stanie zmieścić się w czasie.
Powyższe próby to z pewnością dobra droga. Jak widać w powyższej wypowiedzi cel spotkania jest osiągany a głównym problemem jest próba zamknięcia tematu w ramach czasowych.
Najważniejsze jest to, by z retrospekcji były jakieś postanowienia (konkretnie: zaplanowane akcje, które można wykonać a nie obietnice) i by te postanowienia były realizowane.
Zanim zasugeruję jakieś rozwiązanie tego typu problemu kilka pytań pomocniczych:
  • Czy czujecie/widzicie, że robicie postępy dzięki takim retrospekcjom? Czy wnoszą one wartość? Czy wartość retrospekcji przewyższa koszt czasu spędzonego na tym spotkaniu?
  • Czy oprócz tego, że „łamiecie reguły” Scrum przedłużając retrospekcje są jakieś negatywne efekty takich przedłużonych spotkań? Jakie?
  • Czy zespół widzi to jako problem?
  • Czy ktoś poza zespołem widzi to jako problem? (BTW: Jeśli tak to co mu do tego?)
  • Nieśmiertelne pytanie do Scrum Mastera – czy pytałaś zespół o to jak rozwiązać ten problem?
    • Czy według Was gdyby spotkanie było krótsze to mogło by być równie efektywne? Co musiało by się stać żeby tak było?

Moim zdaniem (wynika to z mojego doświadczenia) w pierwszej kolejności wdrażając tą czy inną praktykę powinniśmy nastawić się na osiągnięcie oczekiwanego efektu stosowania danej praktyki (w tym przypadku na osiągnięcie celu w postaci zaplanowanych konkretnych usprawnień). Jeśli mamy z tym problem to nie skupiajmy się na detalach takich jak przestrzeganie timeboxów – na to przyjdzie czas później. Byćmoże w Waszych zespołach nie ma takich problemów i wszystko udaje się zrobić przed czasem (a może jednak nie do końca i nie wszystko?) – w każdym razie, timebox nie zawsze jest Waszym największym problemem.

A jeśli faktycznie przedłużające się spotkania są (już) Waszym głównym problemem (prędzej czy później zapewne będą, ale może jeszcze nie teraz) to proponuję próbę wdrożenia poniższego eksperymentu.
To co teraz napiszę może wydać się Wam brutalne – niemniej jednak postarajcie się potraktować to jak eksperyment: Jednym z najlepszych sposobów na przestrzeganie timeboxów (czy to na retrospekcji, czy na planowaniu, czy na Daily Scrum) jest przestrzeganie timeboxów. Tutaj Scrum Master musi się wcielić w rolę managera (o rolach i wcieleniach Agile Coacha pisałem tutaj) a nawet managera-tyrana i w momencie, gdy skończy się czas przewidziany na dane spotkanie brutalnie je zakończyć nawet jeśli cel nie został osiągnięty i efekty nie są zadowalające.
By coś osiągnąć w ramach określonego timeboxu warto podczas spotkania przypominać o tym, że czas się kończy, niemniej jednak, takie groźby muszą mieć pokrycie i gdy czas się skończy to spotkanie faktycznie musi się skończyć.
Z mojego doświadczenia przeważnie wystarczało jedno-dwa takie ucięte spotkania by za trzecim razem udało się osiągnąć cel. Warto zastosować tą zasadę nie tylko do retrospekcji, ale także do każdego innego wydarzenia w Scrum i nie tylko. To jest dobra praktyka, której stosowanie warto wypracować w zespole.
Oczywiście nie jest to rozwiązanie uniwersalne i może nie być wręcz wskazane dla zespołów, które dopiero zaczynają swoją przygodę z retrospekcjami i którym jeszcze nigdy nie udało się wnieść realnej wartości podczas takich spotkań. Także tak jak w opisanym przypadku radził bym najpierw nauczyć się osiągać cel takich spotkań a później pracować nad (istotnymi) szczegółami typu ramy czasowe.
Z pewnością takie rozwiązanie jest też raczej ostatecznością – warto wcześniej spróbować omówić ten problem w zespole i wspólnie znaleźć jego rozwiązanie (takie czy inne). Czasem wystarczy dobra moderacja spotkania – na przykład jeden z zespołów z którym pracowałem szybko przejął ode mnie powiedzonko: „no dobrze – ale do brzegu…”, które humorystycznie wykorzystywałem zawsze, gdy miałem poczucie, że rozmowa nie idzie w kierunku rozwiązania problemu tylko raczej jest na bardzo ogólnym poziomie i „pływamy” – a raczej dryfujemy bez celu zamiast skupić się na rozwiązaniu. „Do brzegu…” stało się zwrotem-wytrychem we wzajemnych relacjach zespołu.
Nie bez powodu użyłem słowa eksperyment powyżej. To nie jest tak, że macie od razu  wprowadzać powyższe zasady – sprawdźcie czy to u Was zadziała. A jeśli nie, to przeprowadźcie kolejny eksperyment – zmieńcie coś. Żeby eksperyment z brutalnym odmierzaniem czasu (czy jakikolwiek inny eksperyment) mógł się udać potrzebna jest przede wszystkim zgoda na jego przeprowadzenie wszystkich biorących w nim udział dlatego warto wytłumaczyć na czym ten eksperyment polega i jaki jest jego cel.
Jest jeszcze idea spotkań
Więcej na temat timeboxów pisałem w „Mity i Problemy w Agile„. Znajdziecie tam obszerniejszy opis tego dlaczego poszczególne spotkania w Scrum nie powinny być ani za długie ani za krótkie.
Dodaj komentarz więcej...

Syzyfowe Prace – Agile Transformacje

opublikowany przez 14, Kwi, 2015, w kategoriach Agile, Coaching, Lean

3195818623_6757843874_o

„(…) We can see that the insanity – and tragedy – of agile – lies in the Sisyphean task of trying to build effective teams – and ways of working- inside ineffective organisations.”

Bob Marshal „What Is Agile Software Development?

Powyższy cytat bardzo dobrze obrazuje to co od kilku lat zauważam podczas mojej pracy jako Agile Coach. Głównym problemem moich klientów jest przeważnie to, że konieczne zmiany wymagane do usunięcia wielu dysfunkcji powinny zachodzić na poziomie całej organizacji a tymczasem wszyscy próbują optymalizować na poziomie poszczególnych zespołów.

Brak spójnej wizji, jasno określonych wartości, misji lub też misja i wartości jako marketingowy chwyt całkowicie sprzeczne z tym jak naprawdę działa organizacja to chleb powszedni wielu firm.

Krytyka Boba Marshal’a w artykule z którego pochodzi powyższy cytat – mniej lub bardziej przesadzona jest jednak w dużej mierze trafna – większość Agile’owych technik i metod skupia się głównie na pracy zespołu (zespołów) wokół produktu – ponad tym wszystkim jest jeszcze organizacja wewnątrz której dany zespół egzystuje i wytwarza produkty.

Stąd też moje zainteresowanie Lean Software Development i System Thinking – w tych dwóch podejściach pracujemy z całymi organizacjami i jednocześnie z zespołami. Praktycznie za każdym razem pracując z nowym zespołem i organizacją zaczynam od zwizualizowania strumienia wartości (Value Stream Mapping). Za pierwszym razem robimy to z perspektywy zespołu a następnie staramy się tą wizję zweryfikować i rozszerzyć o to jak faktycznie wygląda przepływ wartości w organizacji. Gdzie zaczyna się wartość – skąd biorą się wymagania? Co dzieje się z wymaganiami zanim trafią do developmentu? Co dzieje się z nimi później – w jaki sposób są weryfikowane? W których miejscach pojawiają się przestoje produkcyjne – gdzie wymaganie czeka, czyli gdzie generowane są straty? Gdzie są wąskie gardła (w skali całej organizacji raczej rzadko w zespole developerskim)? To tylko kilka z pytań które mogą być przydatne podczas stawiania takiej diagnozy.

Źródła wielu problemów widocznych i często powodujących brak motywacji i frustrację w zespołach wynikają z dysfunkcji, które mają miejsce poza zespołami. Niezliczoną ilość razy słyszałem na warsztatach, szkoleniach i przede wszystkim podczas sesji coachingowych jak wszyscy narzekają na to jak jest źle i nie da się nic z tym zrobić. Oczywiście w wielu takich przypadkach wystarcza zmiana postawy członków zespołu, czasem właśnie po to, by wywrzeć odpowiednia presję na organizację i wypracować pewne zmiany.  Niemniej jednak jest też masa sytuacji w których narzekania na poziomie zespołów i związana z nimi niemoc poprawienia czegokolwiek są przynajmniej częściowo uzasadnione. Bez konkretnych zmian na różnych poziomach organizacji i współpracy z ludźmi, którzy na kształt organizacji mają największy wpływ prędzej czy później możemy natrafić na barierę nie do pokonania. Zawsze można oczywiście zmienić organizację (o ile świat byłby lepszy, gdyby ludzie pracowali w firmach w których CHCĄ pracować), ale to raczej utopia i o ile realna w poszczególnych przypadkach, o tyle niemożliwa do spełnienia przy większej skali.

Patrząc w przeszłość na projekty transformacji agile, które miałem okazję wspierać w ten czy inny sposób jasno widać, ze najlepsze efekty udało się nam osiągnąć tam, gdzie pracowaliśmy z całą organizacją. Począwszy od prezesa/zarządu, poprzez managerów wysokiego i średniego szczebla i skończywszy na developerach (i nie tylko – istotne np. jest też zaangażowanie działów produktowych, marketingowych i przede wszystkim HR).

Tam, gdzie miałem okazję pracować jedynie z pojedynczymi zespołami zmiany zaszły stosunkowo niewielkie. Przeważnie udawało się zoptymalizować pracę zespołu ale potencjał zwiększenia efektywności był znacznie większy – wystarczyłoby tylko wprowadzić pewne usprawnienia na poziomie organizacji, na które nie było zgody (a raczej możliwości porozmawiania z kimkolwiek, kto taką zgodę mógłby wyrazić).

A czy Twoja organizacja (a nie tylko zespół) jest gotowa na zmiany?

1 komentarz więcej...

Trzech developerów – czyli krótka historia z morałem

opublikowany przez 09, Kwi, 2015, w kategoriach Agile, Automatyzacja, TDD, Testowanie, XP

5597863793_60f320a45d_o

Trzech programistów zostało zapytanych o to jak długo zajmie im przejście przez pole do domu?

Junior Developer popatrzył na dystans dzielący go od domu i powiedział: „Nie wygląda żeby było daleko  – zajmie mi to 10 minut”. 

Senior Developer popatrzył uważnie na pole i powiedział: „Powinienem być w stanie dotrzeć tam w ciągu dnia”. Oczywiście zdziwiło to Junior Developera. 

Ninja Developer popatrzył na pole i powiedział: „Wygląda na dziesięć minut drogi, ale myślę, że piętnaście minut będzie odpowiednią estymatą”

Junior Developer wystartował ale po kilku krokach wybuchła pierwsza mina zakopana na polu co sprawiło, że Junior Developer musiał zboczyć z najprostszej drogi. Po tym jak wielokrotnie musiał zawracać wysadzając po drodze kolejne miny, po dwóch dniach udało mu się dotrzeć do celu. Oczywiście nie obyło się bez ran.

Senior Developer od razu rozpoczął swoją podróż na czworaka uważnie sprawdzając każdy metr drogi i przemieszczając się tylko tam gdzie jest bezpiecznie. Oczwiście kilka razy natknął się na minę ale zdążył dotrzeć do celu w trochę ponad jeden dzień. 

Ninja Developer wystartował i spokojnie przeszedł przez pole do celu. Dotarł tam po dziesięciu minutach. 

Dwaj pozostali programiści zszokowani zapytali: „Jak udało Ci się to osiągnąć?”, „Jak przeszedłeś przez pole nie wysadzając żadnej miny?”

„To było łatwe” odpowiedział Ninja Developer – „Po prostu nie zakopałem tam tych min wcześniej”.

[znalezione na Quorze  i przetłumaczone na nasze]

Konkluzja: Emergent Architecture – fajna sprawa, ale warto czasem pamiętać o reużywalności i możliwościach rozwoju naszego kodu. Warto też mieć testy automatyczne, które przez takie pole minowe nas spokojnie, może trochę powoli, ale jednak bezpiecznie przeprowadzą.

 

 

Dodaj komentarz więcej...