blog.testowka.pl

ALE na ACE, ACE z ALE w tle – czyli event, którego nie możecie przegapić

opublikowany przez 25, Mar, 2016, kategorie: Agile, ALE, Scrum

Jak niektórzy z Was zapewne wiedzą, od kilku już lat udzielam się w ruchu Agile Lean Europe oraz w jego Krakowskim odziale ALEKraków. W ramach ALEKraków organizujemy różne lokalne, ale też globalne wydarzenia jak np. ALE Unchonference 2014 w Krakowie. Oprócz tego wspieramy konferencje, czy to jako patroni społecznościowi czy zaangażowani wolontariusze. A wszystko po to, by szerzyć wiedzę na temat współczesnych – zwinnych i szczupłych metod wytwarzania oprogramowania.

W zeszłym roku w ramach naszej grupy pojawił się pomys,ł by zorganizować konferencję w Krakowie na wzór ALE Unconference. Pomysł świetny, tylko że nauczeni doświadczeniami z organizacji un-conferencji z 2014 roku zdawaliśmy sobie sprawę jak duże jest to wyzwanie. Ponadto pojawiło się pytanie czy w ogóle jest potrzeba organizacji w Krakowie kolejnej konferencji. Mniej więcej w tym samym czasie zostaliśmy zaproszeni przez organizatorów Agile Central Europe do objęcia patronatu nad tą konferencją. Wtedy to przyszedł nam do głowy szalony pomysł – a co gdyby tak, zamiast zwykłego patronatu spróbować w ramach ACE zaopiekować się ścieżką tematyczną dotyczącą Agile i Lean. Pomysł spodobał się organizatorom i tak oto wspólnie z ekipą ACE pod wodzą Paul’a Klipp’a objeliśmy opieką „procesową” ścieżkę tematyczną na Agile Central Europe 2016.

Osobiście miałem przyjemność wziąć udział między innymi wyborze prelegentów i tematów do „naszej” ścieżki. I właśnie tym kogo i dlaczego zaprosiliśmy chciałbym się z Wami podzielić. Pamiętam jak kilka lat temu rozmwiałem z Paulem na temat organizacji konferencji i eventów. Wtedy Paul podzielił się swoimi doświadczeniami i przemyśleniami – jednym z nich było stwierdzenie: „Organizuj wydarzenia, w których sam chciałbyś wziąć udział” – i własnie chyba tym głównie kierowaliśmy się podczas układania programu ACE 2016.

Poniżej tylko kilkoro z prelegentów. Pozwalam sobie pominąć Kenynote Speakerów których zapewne dobrze znacie i nie trzeba ich nikomu przedstawiać. A jeśli ktoś nie wie kim jest Mary Poppendieck czy David Hussman to niech szybko googluje.

W ramach scieżki procesowej pierwszy dzień otworzą Ewa Koprowska z PZU oraz Marc Löffler. Zaprosiliśmy Ewę, gdyż istotne dla nas są nie tylko doświadczenia z całego świata, ale też osiągnięcia na naszym lokalnym gruncie, a to co się dzieje w PZU ostatnio warte jest pokazania szerszej publiczności. Marc to konferencyjny wyjadacz. Widząc jego zgłoszenie nie zastanawialiśmy się długo – zawsze gdy mieliśmy przyjemność go oglądać i słuchać na żywo dowiadywaliśmy się czegoś nowego i zaskakującego. Tym razem z pewnością też nas nie zawiedzie. Poza tym Marc to świetny gość – warto zaczepić go w przerwie na kawę i porozmawiać!

Pierwszego dnia równolegle do sesji Open Space (moja ulubiona część każdej konferencji) Claudio Perrone będzie prowadził warsztat z Poppcorn Flow – czyli o tym jak w sposób ciągły, bezboleśnie wdrażać zmiany w organizacji. Oprócz tego, że Claudio jest świetnym mówcą to jest on też jednym z najznamienitszych praktyków Lean i A3 Thinking w Europie. Do Claudio będzie również należała scena drugiego dnia, gdzie wystąpi jako jeden z Keynote Speakerów.

Popołudnie to miedzy innymi wykład Kuby Nabrdalika o tym jak poradzić sobie z tematem tabu – pieniędzmi/pensjami. To chyba dosyć nietypowy temat dla Kuby, którego znam głównie z mocno technicznych prezentacji, ale z pewnością warto będzie uczestniczyć w tym wykładzie. Jego bogate doświadczenia z pewnością zostaną w odpowiedni sposób zaprezentowane na scenie.

Drugi dzień to między innymi  Luis Gonclaves, który podzieli się swoimi doświadczeniami z wielu transformacji Agile i wdrożeń Scrum. Luis poprowadzi też warsztaty z retrospekcji, w których warto wziać udział jeśli pracujecie używając Scrum.

Na ACE zdecydowanie warto zostać do samego końca, gdyż tutaj miejsce będą miały dwie prezentacje, których ja osobiście nie chciałbym opuścić. Popołudnie będzie należało do Pawła Wrzeszcza i Mariusza Sieraszczkiewicza, którzy opowiedzą o swoich doświadczeniach w pracy z różnymi zespołami. Obydwaj panowie to doświadczeni programiści i o ile Mariusz chyba nadal trochę bardziej skupia się na bardziej technicznych aspektach pracy to Paweł ostatnio rozwija się głównie w kierunku coachingu. Ten duet i to połączenie różnych perspektyw i umiejętności to moim zdaniem jedno z najbardziej efektywnych ustawień pozwalających na efektywne wdrażanie zmian w organizacjach. Sam często w takim układzie pracuję z moimi kolegami i koleżankami, tymbardziej chętnie posłucham o tym jak robią to inni.

Ostatnia prezentacja w ścieżce procesowej to prezentacja Miny Boström Nakićenović, która w przejrzysty sposób pokaże jak wiele możemy się nauczyć na temat wytwarzania oprogramowania czerpiąc z innych dziedzin – chociażby takich jak biologia. Osobiście widziałem już tą prezentację w 20 minutowej wersji – w stylu Pecha-Kucha, niemniej jednak z pewnością obejrzę dłuższą wersję jeszcze raz – bo warto!

Oprócz tematów procesowych z zakresu Lean i Agile jest jeszcze cała ścieżka produktowa, gdzie można będzie dowiedzieć się ciekawostek z zakresu rozwoju produktu, UX, Lean Startup itp.

W imieniu swoim i pozostałych organizatorów serdecznie zapraszam Was na ACE 2016.

A gdybyście w przyszłości chcieli zaangażować sie w działania ALE Kraków – to również zachęcam do dołączenia do naszej otwartej grupy!

2 komentarze więcej...

Pytaliście o następny Agile Coach Camp PL?

opublikowany przez 09, Lut, 2016, kategorie: Agile, ALE

Gdy opublikowałem pierwszą relację z pierwszego ACCPL dopytywaliście o to, skąd można się dowiedzieć o następnych? Odpowiedziałem, że warto śledzić mojego bloga i twittera 😉 więc aby nie być gołosłownym… Rejestracja rusza jutro  (jak tylko będę coś więcej wiedział, to będe twittował)!

Kiedy?
22-24 kwietnia 2016 r.

Gdzie?
Hotel Podklasztorze w Sulejowie.

Ile jest miejsc?
60

Cena:
600 PLN

Więcej szczegółów tutaj: https://accpl.wordpress.com/

 

W imieniu organizatorów zapraszam. Ostatnio bilety rozeszły się w dwa dni więc nawet nie próbujcie się zastanawiać nad rejestracją tylko klikajcie i wpłacajcie kasę – warto! Do zobaczenia!

Dodaj komentarz więcej...

Gemba Walk w IT – robimy to źle?

opublikowany przez 25, Sty, 2016, kategorie: Inne

Ostatnio wdałem się przypadkiem w bardzo ciekawą dyskusję z Michaelem Feathersem na Twitterze. Micheal sprowokował mnie do dyskusji stwierdzeniem:

Gemba is the place where value is created. In manufacturing the genba is the factory floor. In a software org, it’s the code.

Gemba Walk to sposób na odkrywanie problemów. Zgodnie z definicją chodzi o to, by osoby decyzyjne przebywały od czasu do czasu w miejscu gdzie tworzona jest wartość – w miejscu pracy, wśród ludzi (lub maszyn) wytarzających tą wartość. W ten sposób osoby decyzyjne poznają naturę problemów z jakimi boryka się ich organizacja i są w stanie je skutecznie rozwiazywać  W fabryce miejscem takim jest hala produkcyjna. Pozostaje pytanie co jest takim miejscem w organizacji bazującej na wytwarzanym oprogramowaniu?

W całym tym naszym Agile ciągle powtarzamy, że chodzi o to, żeby zbliżyć IT do biznesu. Wynika to między innymi z potrzeby przezwyciężenia  Prawa Conwey’a, które mówi o tym, że organizacje projektujące systemy, budują rozwiązania, które są odzwierciedleniem struktur komunikacyjnych tych organizacji. Jak zatem to robimy i dlaczego źle? Wszystkie te nasze Scrumy i inne metody zakładają, że trzeba zbliżyć developerów do biznesu. Trzeba rozmawiać z biznesem na temat produktów i domeny biznesowej, tak aby developerzy lepiej rozumieli biznes.

Jako Agile Coach czy Scrum Master moja praca sprowadzała się zazwyczaj do sprawienia by developerzy zobaczyli trochę szerszą perspektywę niż ich kawałek kodu i jednocześnie by biznes zrozumiał o co chodzi w tym developmencie. I zazwyczaj to wystarczało by znacząco poprawić efektywność stosowanych procesów.

A co jeśli to jest niewystarczające? A co jeśli można by osiągnąć znacznie więcej? A co gdybyśmy spróbowali zrobić to wszystko w drugą stronę, a najlepiej w obie i nie tylko ciągać developerów do biznesu, ale też biznesowi pokazać kod? W końcu w Gemba Walk chodzi o to, by to osoby decyzyjne poruszały się po miejscu, gdzie tworzona jest wartość. O ile developerzy owszem mają wpływ na wiele decyzji i sporo ich mniej lub bardziej świadomie podejmują to jednak przeważnie więcej decyzji podejmowanych jest w biznesie.

Co by się stało gdybyśmy pokazali biznesowym osobom decyzyjnym nasz kod, albo przynajmniej architekturę aplikacji? Co by było gdybyśmy co tydzień poświęcali godzinę na przeprowadzenie naszego CEO przez kawałek kluczowego dla naszej aplikacji kodu?  Ile problemów mogli byśmy w ten sposób wykryć?

No dobra, może nie od razu CEO ale może ktoś inny z biznesu powinien od czasu do czasu przejrzeć nasz kod… Jak często zdarza się wam, że nazewnictwo klas czy metod użyte w kodzie nijak się ma do języka stosowanego w biznesie? Jak często coś takiego prowadziło do nieporozumień? Jak często mówicie, że czegoś nie da się zrobić w waszej aplikacji, gdyż model aplikacji zupełnie nie odpowiada modelowi biznesowemu waszej organizacji?

 

 

 

 

Dodaj komentarz więcej...

Kluczowe wartości firmy – ale jak?

opublikowany przez 06, Paź, 2015, kategorie: Agile, Zarządzanie

Zakładając ponad rok temu firmę developerską zastanawiałem się nad tym jak bym chciał by ta firma wyglądała za jakiś czas, z jakimi ludźmi chciałbym pracować docelowo, co będzie mnie/nas motywowało, czym będziemy się kierować? Oczywiście słyszałem o czymś takim jak „Kluczowe wartości firmy” ale w praktyce przeważnie to co widziałem różniło się zasadniczo od tego jak to według teorii powinno wyglądać. Z tego powodu dosyć sceptycznie podchodziłem do tematu ustanawiania kluczowych wartości, wypisywania tego na stronie czy na ścianach w biurze. Moja praktyka konsultanta i Agile Coacha często pokazywała, że na ścianach w wielu firmach widniały piękne frazesy o tym jacy to jesteśmy super i czym się tutaj kierujemy, a w rzeczywistości pracownicy tych firm mieli to gdzieś lub zupełnie się z tymi wartościami nie utożsamiali. Oczywiście winę za to można by zwalić na proces rekrutacji ale myślę że nie tylko.

Niemniej jednak, gdy podczas ostatniego roku nasza firma stopniowo rosła poczułem, że zaczyna nam brakować czegoś, co by nas wszystkich łączyło. Czegoś co by sprawiało, że wszyscy utożsamiali byśmy się z naszą marką i z tym co robimy. Ustanowienie kluczowych wartości, wspólnych dla wszystkich, którymi będziemy się kierować w codziennej współpracy wydawało się być dobrym pomysłem na rozwiązanie tego problemu.

No dobrze – ale jak ustanowić wartości wspólne dla wszystkich?

Samo mówienie o kluczowych wartościach to jedno, ale w jakiś sposób trzeba by ustalić jakie one mają być. Zrobienie tego w niewłaściwy sposób nie tyle będzie szkodliwe, co sprawi, że nie wszyscy będą się z tymi wartościami utożsamiać, a co za tym idzie wartości te nie będą w pełni działać o ile w ogóle będą działać. Pierwszy pomysł na ustanowienie wartości jaki przyszedł mi do głowy polegał na tym, że chiałem porozmawiać o naszych personalnych wartościach z wspólnikami, a następnie przedłożyć te wartości innym. W końcu my wiemy jakimi wartościami kierowaliśmy się zakładając firmę i zatrudniając ludzi oraz jakimi kierujemy się na codzień.

Pomysł ten o ile z pozoru bardzo dobry, wydawał mi się niekompletny. Miałem obawy (myślę, że słuszne), że zrobienie tego w taki sposób nie rozwiąże problemu związanego z tym, że ludzie nie będą się czuli związani z tymi wartościami. Z pomocą przyszedł Michał (jeden z pierwszych naszych developerów, który współpracuje z nami w zasadzie od samego początku Pragmatic Coders). Michał podsunął mi artykuł, o tym jak podobny problem rozwiązał CEO Imgur.

We wspomnianym artykule autor opisał swoją historię tego jak rozpoczynając pracę w Imgur dostał od swojego pracodawcy maila z pytaniem o jego personalne, kluczowe wartości, którymi kieruje się na codzień. Podobnego maila napisałem i ja do naszych współpacowników. Ale zanim do tego doszło postanowiłem zapytać innych (między innymi moich wspólników) co myślą o takim pomyśle? W dużym skrócie wszyscy z którymi rozmawiałem (oprócz Michała) byli do tego mocno sceptycznie nastawieni. Moi wspólnicy wręcz stwierdzili, że „w ten sposób się ośmieszę przed pracownikami i stracę autorytet”, poza tym „nikt nie przeczyta tego maila, a już napewno na niego nie odpowie”. Kolejną obawą moich wspólników było to, że „co jeśli ktoś odpisze i okaże się, że jego wartości są zupełnie sprzeczne z tym jak my widzimy naszą firmę?”. Tym ostatnim akurat postanowiłem się w ogóle nie przejmować – po pierwsze sami tych ludzi zatrudnialiśmy, więc raczej spełniają nasze oczekiwania także pod tym względem, a po drugie nawet jeśli kierują się innymi zasadami niż my to wiedza na ten temat może nam jedynie pomóc we wzajemnych relacjach.

Treść maila znajdziecie poniżej. Tak, wiem, że jest strasznie długi, ale bardzo zależało mi na tym, by wszyscy dobrze zrozumieli o co mi chodzi i dlaczego zależny mi na tym, by na niego odpowiedzieli.

Jako, że nasza firma cały czas rośnie i mamy nadzieję, że ten trend się nadal utrzyma, coraz bardziej istotne staje się odpowiednie zdefiniowanie wspólnych, kluczowych wartości, w oparciu o które dalej kształtować się będzie nasza kultura organizacyjna, jak na zewnątrz i wewnątrz firmy będzie wyglądała nasza marka, a także jak zostanie zaplanowana strategia dalszego rozwoju Pragmatic Coders.
Dlatego zwracam się do Ciebie z prośbą. Opisz prosze 3-5 wartości, które są dla Ciebie ważne. Wartości to coś, co definiuje to kim każdy z nas jest i kim chce być. Każda taka “wartość” może być pojedynczym słowem albo zdaniem, który opisuje to, co jest dla nas ważne w codziennej pracy.
Zdefiniowanie kluczowych wartości to próba określenia tożsamości Pragmatic Coders – zasad, tego w co wierzymy, filozofii którą wyznajemy na codzień w pracy i poza nią. Osobiście od jakiegoś czasu próbowałem takie wartości samemu opracować, ale doszedłem do wniosku, że to bez sensu – bo Pragmatic Coders to my wszyscy a nie tylko ja, Marcin i Marek.
Tylko wspólnie określone wartości mogą być czymś, w co wszyscy będziemy wierzyć, czymś co ma dla nas wszystkich znaczenie i motywuje nas każdego dnia do działania. To nie mogą być puste słowa i marketing bulshit, który wrzucimy na stronę i napiszemy na ścianie złotymi literami. Abyśmy mogli rozwijać się w określonym kierunku, który będzie odpowiadał każdemu z nas te wartości muszę mieć dla nas wspólne znaczenie.
To powinny być rzeczy, które są ważne dla każdego z nas personalnie, wcale nie muszą odzwierciedlać tego jak wygląda nasza firma w tej chwili. Odpisz proszę bezpośrednio do mnie, nie musisz jeśli nie chcesz o tym rozmawiać z innymi i dzielić się tym z nimi.
Mam nadzieję, że po zebraniu tego razem będziemy mogli lepiej zrozumieć to, co jest dla nas ważne i w jakim kierunku powinniśmy się rozwijać jako firma, zespół i ludzie.
Ku zdziwieniu niedowiarków na maila odpisali wszyscy. Niektórzy, bardzo krótko i zwięźle, inni rozpisując się na kilka stron. Natomiast najważniejsze było to, że teraz do wyznaczania naszych wspólnych wartości miałem już do dyspozycji wiedzę na temat tego jakie wartości wszyscy wyznajemy. Ostatecznie nawet jeden ze wspólników postanowił dopisać swoje wartości do listy wartości zebranych od wszystkich w firmie. Dalej było już z górki – wszystkie odpowiedzi wrzuciłem do arkusza w excelu rozbijajac je na pojedyncze wartości. Uważnie wszystko przeczytałem, poszukałem elementów wspólnych lub podobnych, pogrupowałem i uporządkowałem według tego jak często dana wartość powtarzała się w odpowiedziach moich kolegów i koleżanek. W efekcie powstało siedem kluczowych wartości, które następnie skróciliśmy do 4 najważniejszych:
  • Ludzie i Współpraca
  • Pasja i Zaangażowanie 
  • Satysfakcja i Jakość
  • Szacunek i Zaufanie

 

Dzięki odpowiedziom wszystkich w firmie, do każdej z powyższych kluczowych wartości mogliśmy też dopisać jej wspólne znaczenie dla każdego z nas.
Co dalej? Narazie te wartości zawisły na ścianie w biurze. Natomiast najważniejsze jest to, że te wartości są wypadkową nas wszystkich. Nie trzeba ich w żaden sposób „wdrażać” w naszą pracę – one tam po prostu są. Ale to, że teraz wiszą na ścianie cały czas przypomina nam dlaczego tu jesteśmy i dlaczego robimy to co robimy. A gdy z jakiegoś powodu, ktoś z nas zaczyna działać niezgodnie z tymi wartościami dużo łatwiej jest nam teraz wrócić na właściwe tory i naprawić to co zepsuliśmy.
O tym jak idzie nam ich wykorzystywanie w codziennej pracy pewnie jeszcze napiszę nie raz.
4 komentarze więcej...

Szukamy QA!

opublikowany przez 21, Maj, 2015, kategorie: Inne, Praca, Testowanie

Przez długi czas w Pragmatic Coders pracowaliśmy bez QA. Później mieliśmy testera po stronie klienta. W obydwu przypadka radziliśmy sobie całkiem dobrze. Teraz jednak stwierdziliśmy, że chcielibyśmy radzić sobie jeszcze lepiej.

Datego…

Poszukujemy osoby na stanowisko Quality Assurance Engineer, która wniesie dodatkową wartość do naszego zespołu.

Jeśli:

  • jesteś przyzwyczajony do pracy od 8 do 16 i nie wyobrażasz sobie tego jak można inaczej (nie tolerujesz wychodzenia z pracy kiedy się chce i pracy zdalnej jeśli ma się na to ochotę),
  • masz certyfikat ISTQB Advanced Level i posiadasz szerokie doświadczenie w stosowaniu omawianych tam praktyk,
  • jesteś ekspertem w pracy w ciągłym konflikcie z developerami i potrafisz ten konflikt efektywnie wykorzystywać do tego, by zapewnić jak najwyższą jakość,
  • Agile dla Ciebie jest fajny, ale zdajesz sobie sprawę z tego, że w praktyce lepiej jest jednak napisać plan testów, przypadki testowe i scenariusze,
  • masz bogate doświadczenia jako Test Manager i z łatwością zbudujesz dla nas dział testów w skład którego wejdą Twoi nowi podwładni,
  • masz doświadczenie w automatyzacji testów i wiesz, że automatyzacja ma sens tylko jeśli funkcjonalności są już stabilne i nie będą się zmieniać,
  • potrafisz sukcesywnie odseparować swoje życie od pracy (bo przecież praca to smutny obowiązek, ale jednak konieczny by móc się poza nią rozwijać),
  • jesteś prawdziwym ekspertem w wykonywaniu scenariuszy testowych, a Twoje raporty z testów i zgłoszenia błędów są zawsze bardzo starannie opisane i nie wyobrażasz sobie by można to było robić inaczej,
  • wiesz jak efektywnie wtestować jakość w oprogramowanie – znasz wiele praktyk, które na to pozwalają i wiesz jak je wdrożyć w życie,
  • potrafisz efektywne komunikować się z programistami używając wyłacznie Jiry (i/lub innego bugtrackera),

…jeśli spełniasz powyższe wymagania… to… raczej nie masz czego u nas szukać… No chyba, że szukasz terapii szokowej…

W innych przypadkach daj nam znać – chętnie porozmawiamy o Twoim doświadczeniu! Nie liczy się dla nas piękne CV i dekady doświadczeń w korpo – prawdziwa wiedza i doświadczenie oraz chęć i umiejętność szybkiego uczenia się – to jest to, co jest dla nas najważniejsze!

Więcej informacji i faktyczne wymagania znajdziecie tutaj.

Wiemy, że poprzeczka jest dosyć wysoko, ale nasz zespół w tej chwili potrzebuje osób, które faktycznie nie będą zostawały z tyłu w tym szybko zmieniającym sie i rozwijającym środowisku. W każdym razie postaramy się w miarę możliwości dać szansę każdemu kto spełnia przynajmniej kilka z wymienionych wymagań.

Widełki (bo przecież trzeba): 3000-8000 PLN (netto)
Zasady są proste – wynagrodzenie zależy od ilości spełnianych wymagań.

Miejsce pracy: Kraków
Umowa o Dzieło/Zlecenie lub B2B.

Jeśli macie jakieś pytania to dajcie znać.

 

 

1 komentarz więcej...

Definicja jakości

opublikowany przez 12, Maj, 2015, kategorie: Agile, Jakość, Testowanie

5387711359_26983180a5_o

 

Definicji jakości oprogramowania powstało już wiele. Jedną z chyba najczęściej cytowanych ostatnio jest ta (chyba jej autor to Gerald Marvin (Jerry) Weinberg ):

„Quality is a value to some person”

Jakość jest tym co jest wartościowe dla kogoś. Czyli definicja jakości będzie się różniła w zależności od tego kogo o nią zapytamy.

James Marcus Bach dorzucił do tej definicji kolejne dwa słowa:

„Quality is a value to some person who metters”

Przecież w definicji jakości nie istotne jest zdanie każdego człowieka. Liczy się tylko zdanie osób które się liczą. Użytkowników, interesariuszy, sponsorów oprogramowania czy też osób wyznaczających trendy.

Ja do tej definicji dopisuję kolejny warunek:

„Quality is a value to some person who matters and it varies in time”

Jakość oprogramowania jest tym co ma wartość dla osób, które mają znaczenie i z pewnością będzie się to zmieniać w czasie.

Zmiana jest nieunikniona. Zmieniają się trendy na rynku, konkurencja wypuszcza kolejne, coraz lepsze rozwiązania, technologia się rozwija dając nam nowe możliwości. Ale przede wszystkim w miarę postępów pracy nad produktem i walidacji naszych założeń odkrywamy kolejne wartości i kolejne grupy osób które się liczą w definiowaniu jakości.

Podstawą jakości według mojej definicji jest możliwość ciągłego rozwijania i zmieniania oprogramowania przy stosunkowo stabilnych i przewidywalnych kosztach. W zasadzie to mając zapewnioną możliwość łatwego wprowadzania zmian w oprogramowaniu stosunkowo łatwo jesteśmy w stanie zapewnić dostarczanie wartości/jakości dla ludzi, którzy się liczą.

Warto pamiętać też że „liczące się osoby” z czasem też się zmienią…

Dodaj komentarz więcej...

Jak radzić sobie z Timeboxami?

opublikowany przez 28, Kwi, 2015, kategorie: 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...