blog.testowka.pl

Archiwum

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

opublikowany przez 25, Mar, 2016, w kategoriach 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!

3 komentarze więcej...

Kluczowe wartości firmy – ale jak?

opublikowany przez 06, Paź, 2015, w kategoriach 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.
5 komentarzy więcej...

Szukamy QA!

opublikowany przez 21, Maj, 2015, w kategoriach 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, w kategoriach 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ą…

2 komentarze więcej...

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...