blog.testowka.pl

Zarządzanie

Code i Coach Retreat

opublikowany przez 28, Lis, 2013, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

duck
Wielkimi krokami zbliża się Światowy Dzień Code Retreat pora więc napisać o tym wydarzeniu kilka zdań. Od kilku lat programiści na całym świecie spotykają się jak co roku w grudniu by wspólnie programować. Podczas Code Retreat nie powstaje żaden projekt czy produkt. Chodzi o wspólną pracę nad własnymi umiejętnościami a nie nad produktem.

Code Retreat to kilka sesji programistycznych trwających około godziny podczas których za każdym razem podchodzimy do rozwiązania tego samego problemu na różne sposoby. Za każdym razem zaczynamy od zera. Programujemy oczywiście w parach – gdyż w ten sposób najlepiej jest się uczyć od siebie na wzajem. Każda sesja rządzi się swoimi zasadami i w każdej pracujemy nad konkretną techniką. Po każdej sesji następuje krótka retrospekcja i omówienie tego co się nauczyliśmy.

Zabawa jest przednia i zachęcam wszystkich do udziału w tym wydarzeniu. Tak – do udziału, gdyż Code Retreat 14 Grudnia będzie organizowane również w wielu miastach w Polsce. Wystarczy pogooglować.

Ale to nie wszystko! Dla tych z Was którzy nie tylko programują mam zaproszenie na jeszcze jedno ciekawe wydarzenie (na mniejszą skalę). 05.12.2013 w Krakowie organizuję Coach Retreat. Udało mi się zaprosić jedną z pomysłodawców Coach RetreatOanę Juncu, która pomoże nam w facylitacji tego wydarzenia.

Format Coach Retreat jest zbliżony do Code Retreat:

  • najpierw wybieramy jeden z kilku przygotowanych wcześniej problemów,
  • dobieramy się w grupy max 6 osobowe,
  • jedna osoba wciela się w rolę Coacha a druga w Coachowanego
  • pozostałe osoby w grupie są obserwatorami i udzielają feedbacku w trakcie i po sesji
  • mamy 5-6 sesji coachingowych podczas których próbujemy rozwiązać problem za każdym razem przy użyciu innych metod
  • po każdej sesji retrospekcja i zmiana grup/ról w grupach

Wydarzenie jest całodniowe i raczej darmowe (możliwe jednak, że wymagana będzie drobna opłata rzędu 50zł od osoby jeśli okaże się, że będziemy potrzebować bardzo dużej sali – okaże się wkrótce). Jeśli jesteście zainteresowani udziałem piszcie na adres szkolenia@codesprinters.com lub wiktor.zolnowski@gmail.com. Ilość miejsc ograniczona!

Oana poprowadzi dla nas również warsztaty 06.12.2013 w Krakowie o interesującym tytule Test Driven Business for Lean Startup (powołajcie się na mnie przy rejestracji a czeka Was niespodzianka).

Warsztaty te to kolejny z moich „projektów”. Tym razem nie jest za darmo, ale i tak w bardzo przystępnej cenie. „Projekt” ten polega na sprowadzeniu do Polski trenerów, na których szkolenia sam bym chętnie poszedł. Wynika to z tego, ze na Polskim rynku dość już jest podstawowych szkoleń z Agile i Lean, a na szkoleniu ze Scrum to już chyba każdy był. Ostatnia konferencja Agile By Example potwierdziła moją tezę, że praktycy w naszym kraju wyszli już na wyższy level. Teraz potrzebujemy czegoś więcej niż podstawowe szkolenia na oklepane tematy – potrzebujemy rozwoju. Ja też go potrzebuję dlatego z pewnością w warsztatach Oany wezmę udział jako uczestnik. W przyszłym roku pojawią się kolejne ciekawe szkolenia prowadzone przez niesamowitych trenerów z całego świata.

2 komentarze więcej...

ALE 2013 – retrofleksje

opublikowany przez 08, Paź, 2013, w kategoriach Agile, Zarządzanie

ALE-glass-bigMniej więcej miesiąc temu miałem przyjemność uczestniczyć w trzeciej już edycji un-konferencji Agile Lean Europe 2013 – tym razem w Bukareszcie. ALE un-conference to jedno z najbardziej inspirujących wydarzeń jakie kiedykolwiek widziałem. Ale od początku…

Moja przygoda z ALE Network zaczęła się w 2011 roku jeszcze przed pierwszą konferencją oznaczoną zmodyfikowanym logotypem Uni Europejskiej (patrz powyżej). Pierwszy raz o ALE usłyszałem na konferencji Agile Central Europe 2011, gdzie podczas jednej z sesji open space Jurgen Apello rzucił temat integracji lokalnych społeczności w całej Europie. Właśnie tam rozważana była też idea zorganizowania pierwszej un-konferencji. Pomysł tak bardzo mi się spodobał, że gdy tylko znane były termin i miejsce (koniec sierpnia 2011, Berlin) od razu się zarejestrowałem.

Czym un-konferencja różni się od konferencji?

Normalne konferencje mają zazwyczaj z góry określony program i są organizowane przez konkretne organizacji lub firmy specjalizujące się w organizacji tego typu wydarzeń i z reguły zarabiające na tym. Un-konferencje w tym ALE są organizowane przez społeczność. W przypadku ALE oczywiście mowa o społeczności Agile i Lean.

Program un-konferencji nie jest zazwyczaj w całości z góry ustalony – wiele miejsca pozostawione jest na sesje open space i luźne dyskusje. Często zdarza się też, że program jest zmieniany w oparciu o feedback od uczestników. W przypadku ALE oprócz „tradycyjnego” formatu un-konferencji i zazwyczaj kilku krótkich ścieżek z prezentacjami wokół całego wydarzenia organizowane jest wiele różnych aktywności.

Rzeczy, których nie znajdziecie nigdzie indziej

Kids and Spouse program – jednym z pierwszych pomysłów wokół organizacji pierwszej un-konferencji ALE w 2011 roku było przygotowanie specjalnego programu dla dzieci i partnerów uczestników konferencji (warto dodać, że zupełnie bezpłatnego). Co się dzieje podczas takiego programu? To naprawdę trzeba po prostu zobaczyć – poniżej jeden z efektów współpracy z dzieciakami:

Wolontariusze – ALE Un-conference jest w całości organizowana przez wolontariuszy. Swoje siły łączą tutaj zarówno praktycy i aktywiści ze świata Agile i Lean, jak również lokalne społeczności i środowiska uniwesyteckie.

Kolacja z „nieznajomymi” – jednym z pomysłów na integracje uczestników jest kolacja z nieznajomymi. Organizatorzy dbają o to by zarezerwować pojedyncze stoliki w wielu różnych restauracjach w okolicy po to, by uczestnicy mogli się samo-zorganizować przy ich wyborze, tak aby zjeść kolacje z jak największą ilością osób, których się wcześniej nie znało. Uwierzcie mi na słowo – to niesamowite jak wiele ciekawych historii można usłyszeć od „nieznajomych” i jak łatwo w ten sposób zyskać nowych przyjaciół.

Niesamowicie aktywna społeczność – ALE to przede wszystkim ludzie. Ale nie do końca zwyczajni ludzie. Większość z nas to pasjonaci, którzy uwielbiają dzielić się swoim doświadczeniem i przemyśleniami z innymi.

Za każdym razem inne miejsce i inni organizatorzy – co roku konferencja odbywa się w innym mieście i w innym kraju. Zmieniają się też organizatorzy (przeważnie prawie wszyscy). Oczywiście doświadczenia z organizacji poprzednich edycji są przekazywane nowym osobom. Do tej pory ALE odbywało się kolejno w Berlinie, Barcelonie i Bukareszcie.

Non-profit – całe wydarzenie organizowane jest na zasadach non-profit. Dochód z biletów (a w zasadzie to co zostanie po opłaceniu kosztów) jest przekazywany na cele charytatywne.

Organizatorzy i prelegenci również płacą za bilety – w większości przypadków wstęp na tradycyjne konferencje jest dla organizatorów i prelegentów oczywiście bezpłatny. W wielu przypadkach płaci się prelegentom za wystąpienia (często niemałe pieniądze). W przypadku ALE wszyscy za bilety płacą tyle samo – prezentacje i prelegenci nie są główną atrakcją tego wydarzenia. Liczy się przede wszystkim społeczność, wiedza i doświadczenie każdego uczestnika z osobna. Tutaj wszyscy są równi.

Lokalne społeczności – ALE Network to nie tylko coroczna konferencja. Wokół ALE dzieje się wiele ciekawych wydarzeń organizowanych ogólnie przez ALE Network, a także przez lokalne społeczności. W Krakowie działa na przykład społeczność ALE Kraków która organizuje cykliczne spotkania i prelekcje.

ALE 2013

W tym roku ALE Un-conference odbyło się po raz trzeci. Miałem przyjemność uczestniczyć również w pierwszej edycji w Berlinie. Wszelkie moje oczekiwania co do tego wydarzenia zostały (ponownie) spełnione – powiedział bym, że nawet znacznie ponad wymiar. To niesamowite jak wiele inspiracji można czerpać ze „zwykłych” rozmów z innymi mniej lub bardziej doświadczonymi ludźmi. Nie ma sensu rozpisywać się o prezentacjach, prelegentach czy poszczególnych tematach poruszanych podczas rozmów. W tym po prostu trzeba wziąć udział, to trzeba poczuć na własnej skórze.

ALE 2014

A jeśli już mowa o udziale w tego typu wydarzeniach postanowiliśmy połączyć nasze siły z Tomkiem Wykowskim i zgłosić Kraków jako kandydata na miasto, w którym powinna odbyć się un-konferencja ALE w 2014 roku.

Jeśli chcecie pomóc przy organizacji napiszcie mi maila – przyda się każda pomoc. To co możecie zrobić już teraz to zagłosować na naszą propozycję organizacji ALE 2014 w Krakowie.

3 komentarze więcej...

Źle się dzieje w państwie naszym…

opublikowany przez 23, Wrz, 2013, w kategoriach Agile, Zarządzanie

zielona-wyspa

Tak sobie przeglądam dosyć regularnie różne blogi i artykułu na temat współczesnego zarządzania, Agile, Scrum, Lean i innych metod. W zasadzie tylko pod tymi tworzonymi przez polskich autorów po polsku znajduję komentarze, w których czytelnicy w ogóle poddają w wątpliwość to czy Agile w ogóle działa. Nie – nie pisze tutaj o ostatnich dyskusjach pod poprzednimi wpisami, a przynajmniej nie tylko o tym. Ta tendencja jest znacznie szersza.

Niekończące się kłótnie o to, czy Agile jest lepszy od Waterfall i na odwrót zaczynają być domeną wielu rodzimych konferencji (na przykład zeszłoroczny TestWarez) – głównie tych po polsku. Tam gdzie przemawiają obcojęzyczni prelegenci mało kto wdaje się w polemikę. Nie wiem – może wstydzą się, że nie znają języka. A skoro nie znają języka to pewnie nie czytają tego co się na świecie pisze. W sumie gdyby czytali to pewnie by nie polemizowali z rzeczywistością.

Na całym świecie Agile powoli przestaje kogokolwiek zaskakiwać. Ba! Niektórzy twierdzą, że powoli Agile przechodzi do lamusa, że są już lepsze metody, nurty w zarządzaniu. A u nas? U nas o Agile albo nie słyszeli, albo mówią, że Agile to Yeti – ktoś to podobno widział. U nas (nie tylko u nas, ale tu też) używają słów takich jak Agile albo Scrum do opisania rzeczy, które z tymi pojęciami mają niewiele wspólnego. Cóż to trochę boli – ale nie ma co narzekać – pracujemy nad zmianą tego stanu rzeczy. Na szczęście są wśród nas ludzie, którzy się spotykają po to, by zdobyć wiedzę, wymienić się nią a nie bezsensownie kłócić.

Agile nie jest jak Yeti (jak niektórzy próbują przekonywać). Agile działa! Oczywiście, zawsze znajdą się przykłady, gdzie Waterfall działa. Bo Waterfall działa!

Ja nie rozumiem tylko jednego – skoro Waterfall tak dobrze działa, to czemu wiele różnych badań (jak chociażby wspomniany ostatnio Chaos Report) pokazuje, że Agile działa lepiej.

STOP! Takie dyskusje, o tym czy Agile, czy Waterfall jest lepszy nie mają sensu!

Drodzy czytelnicy, jeśli macie problemy z tym, że piszę o Agile jako o czymś co działa i jest powszechnie stosowane to… hmm… to czytajcie uważnie to co piszę, zadawajcie pytania, dyskutujcie – na przykład na facebooku albo twitterze, albo w komentarzach.  Z chęcią na nie odpowiem, po polsku i za darmo! Przy okazji może sam się czegoś od Was nauczę!  Może dzięki temu dyskusje o tym „czy Agile działa?” przerodzą się w dyskusje o tym „jak sprawić by osiągnąć jeszcze więcej – nie ważne czy za pomocą Agile czy Waterfall czy jeszcze czegoś innego?”.

Może takie negatywne i zacofane postrzeganie naszej szarej rzeczywistości wynika z tego jak ogólnie wygląda IT w naszym kraju. Przeważająca większość firm IT w Polsce to firmy zagraniczne, które tutaj znalazły sobie „tańszą” i często lepszą siłę roboczą. Wśród pozostałych znajdziemy w większości albo firmy robiące software dla sektora publicznego, albo polskie firmy outsourcujące developerów „na zachód”. Trochę to układ niewolniczo-feudalny, jak by się nad tym głębiej zastanowić. I fakt w wielu przypadkach pod szyldem „Agile” albo „Scrum” panowie tychże niewolników próbują przemycić kolejne metody wyzysku białych murzynów. Nie dajcie się bez walki! Wiedza o tym czym naprawdę jest Agile jest Waszą bronią :-).

5 komentarzy więcej...

Kolejny post o metrykach – w odpowiedzi na pytania

opublikowany przez 20, Wrz, 2013, w kategoriach Agile, Testowanie, Zarządzanie

4324373384_a4c0d68189_z

We wczorajszej notce nawiązałem do wpisu na testerzy.pl dotyczącego mierzenia jakości pracy testera.

Dla mnie jedyną z pozoru sensowną metryką spośród wspomnianych w artykule z odnośnika wydaje się być mierzenie stosunku ilości błędów, które wyszły na produkcję do tych, które zostały wykryte – niemniej jednak w ten sposób nie mierzymy efektywności testerów tylko raczej ich nieefektywność.

O metrykach wszelkiego rodzaju wspomniałem już w książce „Mity i problemy w Agile”. Nie zrozumcie mnie źle, nie uważam, że wszystkie metryki są bezwartościowe. Uważam, że niektóre z nich są bez sensu, a inne powodują większe szkody niż dostarczają wartości.

Zawsze, gdy ktoś atakuje mnie metryką zadaje proste pytanie po co chce daną rzecz mierzyć? O ile pytanie jest proste z odpowiedzią na nie bywa już różnie. Przeważnie okazuje się, że albo zamierzony cel jest bez sensu, albo można go osiągnąć w inny, mniej bolesny i kosztowny sposób.

Tak, mniej kosztowny! Metryki są kosztowne! „Ludzie zawsze robią to co jest w nich wzmacniane” – to podstawy psychologii i socjologii. Metryki są wzmocnieniem. Jeśli wzmacniamy w testerach potrzebę raportowania jak największej ilości błędów to wkrótce utoniemy pod sterami raportów, dla których będziemy musieli opracować nowe metody zarządzania defektami. Gdy, zaczniemy mierzyć ilość błędów na produkcji, to strach przed wydaniem stanie się na tyle paraliżujący, że na pytanie o jakość produktu testerzy zawsze będą odpowiadać, że jest niewystarczająca. Takie informacje są bezwartościowe dla każdego managera – nawet Test Managera.

W odpowiedzi na poprzedni wpis na blogu Radek z testerzy.pl napisał.

Dzięki za wspomnienie naszej publikacji.
Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?
Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?
Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zadane przez Radka pytania są bardzo trafne, dlatego zdecydowałem, że zasłużyły sobie na osobny wpis na blogu.

Moje odpowiedzi poniżej:

Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?

W sumie zastanawiam, się czy normalne to dobre słowo? W końcu normalne to nie odbiegające od normy. Jeśli za normę przyjmiemy większość tego co dzieje się na świecie to… nie – projekty Agile nie są normalne! Natomiast jeśli weźmiemy pod uwagę zdrowy rozsądek…

Jak napisałem wczoraj Waterfall działa świetnie dla „dużych projektów”. I to wcale nie był sarkazm. Waterfall działa tam naprawdę dobrze. To znaczy tak dobrze jak jest to w takim środowisku możliwe. Nie widzę żadnego sensu w jakichkolwiek porównaniach Waterfall do Agile.

Oczywiście za chwilę pojawi się pytanie czy w takim razie można w ogóle przekształcić Waterfallową organizację w organizację Agile? Tak, można – jest to trudne i wymaga wielu zmian, na wielu poziomach. Dotyczy to również zmian w tworzonych produktach i w sposobie tworzenia tych produktów.  Często zmiana sposobu ich tworzenia sama sprawia, że produkty ewoluują we właściwym kierunku samoczynnie – jednak chyba lepiej to robić świadomie.

Co ma zrobić taki tester/kierownik testów w opisanej sytuacji? Ludzie są różni – niektórym (myślę, że wielu z nas) odpowiada stabilna praca w miarę niezmiennym środowisku, gdzie jesteśmy odpowiedzialni tylko za swoją działkę. W takim środowisku można dalej się uczyć, rozwijać swoje umiejętności, zwiększać jakość swojej pracy etc. Jednak czasem można (tak jak ja kilka lat temu) dojść do miejsca, w którym dostrzegamy nowe, większe możliwości. Jakość oprogramowania nie zależy od testerów – nie tylko od testerów. Więc albo możemy się oszukiwać i udawać, że stoimy jako testerzy na straży jakości nie mając tak naprawdę na nią zasadniczego wpływu, albo pogodzić się z tą rzeczywistością i dzięki starannej kontroli jakości dostarczać jak najbardziej obiektywne informacje o jakości do osób decyzyjnych. W ten sposób również możemy stać się mistrzami w swoim fachu.

Możemy też iść całkowicie inną drogą i faktycznie zmienić pracę na taką w której będziemy mieli na jakość wpływ. Często będzie wymagało to od nas zdobycia wiedzy znaczenie szerszej niż ta z obszaru testowania oprogramowania. To wszystko jest kwestią indywidualną.

Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?

Jeśli taka instytucja chce mieć oprogramowanie, które na prawdę będzie odpowiadało ich wymaganiom to tak, powinna pracować inkrementalnie. Ba, znam kilka przykładów instytucji bankowych czy nawet międzybankowych które dokładnie tak pracują. Kilkadziesiąt (w porywach do 100) osób pracujących nad systemem do transakcji międzybankowych i ani jednego testera. Pełna automatyzacja testów, BDD, TDD i jeśli wyjdzie jakiś błąd na produkcje to koszty idą w miliony – jeszcze raz – nie ma tam testerów!

Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zdarzyło mi się pracować kilka razy z takim właśnie „Paniami Halinami” i teraz jestem już przekonany, że właśnie jak najczęstsze pokazywanie im działającego produktu jest jedynym sposobem na zrealizowanie prawdziwych wymagań co do tego produktu. Pani Halina nie rozumie pojęć typu formularz, nie wie co to jest checkbox ani radiobutton, nie ma pojęcia o AJAXie, etc.

Gdy pokażę Pani Halinie produkt z formularzem to dowiem się, że dla niej jest to formatka, a pokazując listę rozwijalną dowiem się, że chodziło o checkboxy, bo można wybrać kilka opcji a nie jedną. Tego dokumentacja nie przewidziała, bo dokumentacja jest kolejną abstrakcją, która nie dość, że jest niezrozumiała dla programistów to jeszcze nie jest zrozumiała dla Pani Haliny.

Na szczęście jako ludzie, od dziecka kształcimy nasze zdolności komunikacji – potrafimy nawet porozumieć się z ludźmi nie mówiącymi w naszym języku, głównie poprzez pokazywanie przykładów i wizualizacje. Właśnie dlatego każdy programista czy tester, nawet ten najbardziej introwertyczny lepiej dogada się z Panią Haliną niż zrozumie dokumentację.

Świadomość istnienia modeli wytwarzania oprogramowania jest tutaj zbyteczna zarówno u Pani Haliny jak i nawet u programistów i testerów. Opieramy się na podstawowym założeniu, że interakcje pomiędzy ludźmi (ludźmi o zróżnicowanej wiedzy) są lepsze niż jakiekolwiek procesy i narzędzia.

A co jeśli trzeba zaangażować 40 takich osób jak Pani Halina? A trzeba? Czy na pewno? Nawet jeśli to czemu nie – zdarzało mi się robić Sprint Review na którym było około 25 gości z poza IT. Bardzo ciekawe i produktywne dyskusje się tam odbywały. Oczywiście na końcu był jeden Product Owner, który decydował o tym, co jest najważniejszy w danym momencie niemniej jednak wkład od wszystkich gości i innych stakeholderów był znaczący w ciągły rozwój produktu.

Wracając do metryk – według drugiej strony Manifestu Agile jedyną miarą postępu pracy jest działające oprogramowanie. Ja dodam od siebie, że tą miarą jest działające oprogramowanie, które ma sens. Pamiętajcie o zasadzie Pareto – 80% wartości jest generowana przez 20% funkcjonalności.

„Duże projekty” to problem, co ładnie obrazuje podsumowanie CHAOS Report (strona 13 – dla tych co się im nie chce czytać całości). To są twarde dane – oczywiście zawsze znajdą się wyjątki, ale jednak…

W sumie może powinienem napisać o tym jak w takim razie zmienić „duży projekt” w wiele małych?

6 komentarzy więcej...

Agile dla „dużych projektów” nie działa

opublikowany przez 19, Wrz, 2013, w kategoriach Agile, Kanban, Scrum, Testowanie, XP, Zarządzanie

5665717830_dfe3ea51c2_o

Po raz kolejny ktoś próbował mi udowodnić, że Agile dla „dużych projektów” się nie sprawdzi. I… Generalnie zgadzam się z tym stwierdzeniem. Zgadzam się, tak! Agile dla „dużych projektów” nie działa!

Agile z pewnością nie zadziała jeśli za miarę wielkości „dużego projektu” przyjmiemy ilość ludzi nad tym projektem pracujących. Jeśli duże projekty dla Was to takie nad którymi pracuje 200 lub więcej osób to macie znacznie większe problemy niż, to czy Agile zadziała, czy nie.

„Duże projekty” to dysfunkcja sama w sobie.

Programowanie jest rozwiązywaniem problemów – nie potrafię sobie wyobrazić problemu, który potrzebował by więcej niż kilkadziesiąt osób do jego rozwiązania. Owszem, niektóre problemy są bardziej złożone od innych – w takim przypadku jedyne rozsądne rozwiązanie to rozbicie ich na mniejsze – być może mniej złożone problemy i stworzenie mniejszych zespołów rozwiązujących je.

Waterfall powstał właśnie po to, by radzić sobie z „dużymi projektami”. Waterfall jest cool. Waterfall działa… dopóki nie zaczniesz się nad tym zastanawiać…

Cała pseudonauka o tym w jaki sposób powinniśmy testować (oczywiście manualnie) skomplikowane projekty, zarządzać milionami przypadków testowych, poprawnie zgłaszać miliony bugów, następnie zarządzać tymi zgłoszeniami, mierzyć ilość tych zgłoszeń i co gorsza tworzyć z tego metryki mające na celu określenie jakości pracy testerów [BLAH!], to wszystko powstało w odpowiedzi na realne problemy. Problemy, które sami sobie stworzyliśmy budując niewłaściwe oprogramowanie w niewłaściwy sposób.

Skalowanie Agile to kolejny urojony problem.

Coraz więcej na około słyszy się o nowych, pięknych i kompleksowych metodach skalowania Agile. Niektóre z nich nawet zapewne działają. Ba, nawet widziałem je w działaniu. Niestety nadal są to narzędzia służące do rozwiązywania problemów, które ktoś, gdzieś sam sobie stworzył.

Agile nie trzeba skalować, jeśli jesteśmy w stanie przeskalować nasz produkt. Tak jak na przykład zrobili to w Spotify. Kluczem do sukcesu nie jest stworzenie squad’ów, tribe’ów, chapter’ów czy guild’ów… To wszystko powstało tylko po to by wokół wielu, względnie niezależnych komponentów produktu, rozwijanych przez interdyscyplinarne i kros-funkcjonalne zespoły stworzyć platformę służącą do synchronizacji pracy i wymiany wiedzy. Agile jest gdzieś indziej – w każdym zespole z osobna. Nie ma tutaj żadnego skalowania.

Więc tak, Agile nie działa w „dużych projektach”! Duże projekty są problemem samym w sobie. Nie chcę tutaj rozwodzić się nad potencjalnymi i faktycznymi przyczynami tego dlaczego nadal mamy do czynienia z tak wieloma „dużymi projektami”. To nie jest czas na to – niech ten post będzie dla Was przestrogą, by Wasze małe jeszcze projekty nigdy nie stały się „dużymi projektami”.

8 komentarzy więcej...

Czy potrzebujesz Agile Coacha?

opublikowany przez 10, Wrz, 2013, w kategoriach Agile, Coaching, Kanban, Praca, Scrum, XP, Zarządzanie

2536358399_88e6544fa9_o
Po raz kolejny utwierdziłem się w przekonaniu, że ludzie nie czytają, nie tylko moich książek, czy mojego bloga… Ludzie nie czytają w ogóle, albo czytają bardzo mało rzeczy związanych z ich pracą. Utwierdziłem się w sposób najprostszy – pytając około 35 osób czy czytają… Ludzie nie czytają i nie jeżdżą na konferencje bo najzwyczajniej nie mają na to czasu przez pracę. Często przez to, że ich praca jest nieefektywna muszą pracować więcej, by osiągnąć oczekiwane rezultaty. Pracując więcej nie mają czasu na to, by poczytać o tym jak pracować efektywniej…

I w sumie bardzo dobrze… Bo ja czytam… Bo ja piszę książki… Bo ja jeżdżę na konferencje i czasem tam coś opowiadam… Publikuję czasem coś na blogu ale przede wszystkim czytam blogi innych… Poświęcam dużo czasu na naukę nowych rzeczy, ale też na przemyślenia związane z praktycznym zastosowaniem tego co już umiem… Eksperymentuje z nabytą wiedzą stosując ją w praktyce… Ciągle nabywam coraz więcej doświadczenia związanego z tymi tematami… Bardzo różnorodnego doświadczenia dzięki pracy dla bardzo różnych klientów… Klientów w różnym kontekście, w różnym środowisku, w różnych technologiach i w różnych branżach… Rozmawiam z ludźmi, dzielę się swoim doświadczeniem ale też korzystam z doświadczeń innych…

Właśnie to wszytko, właśnie to, że ja MAM na to czas i że swój czas na to właśnie poświęcam jest głównym powodem tego, że bardziej opłaca Ci się zatrudnić mnie jako Agile Coacha, jako Mentora, jako Trenera, jako Doradce, niż samemu poświęcać nieskończoną ilość godzin na wyszukiwanie i zdobywanie tej wiedzy i doświadczenia. Jest to również bardziej opłacalne niż samodzielne popełnianie błędów – zwłaszcza tych kosztownych i tych, które ja już wcześniej miałem okazję popełnić, lub zaobserwować gdzieś indziej.

Poza tym ja lubię to robić. Robię to z pasją. Nie traktuję tego nawet jak pracę – jest to bardziej moje hobby…

Dość tej autopromocji! Generalnie chodzi o to, że zdobywanie wiedzy to również ciężka praca wymagające wielu poświęceń, a już na pewno dużej ilości poświęconego czasu. Czasem można jednak zdać się na kogoś, kto już tą wiedzę posiada, albo ma czas na to, by zdobyciu tej konkretnej wiedzy się poświęcić…

8 komentarzy więcej...

Kolejny post o diecie

opublikowany przez 21, Sie, 2013, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

Dieta

I po raz kolejny będę pisał o diecie. O diecie dla organizacji. Tym razem zainspirował mnie artykuł, który Dion Almaer opublikował na portalu medium.com (swoją drogą sporo fajnych tekstów na tym portalu, sam też powoli zaczynam tam publikować – polecam).

Wróćmy na chwilę do poprzedniego wpisu w tym temacie oraz odpowiedzi nadesłanej przez Michała Gozderę. Ciekawą dyskusję wywołały powody przejścia na dietę. W przypadku diety mojej własnej może to być na przykład chęć lepszego samopoczucia czy też uzyskanie możliwości patrzenia w lustro bez odrazy do samego siebie. Może to być idea zdrowego i długiego życia, na które szans nie mamy, gdy mamy nadwagę i źle się odżywiamy. A może po prostu chcieli byśmy uzyskać lepszą sprawność fizyczną i wypracować lepszą kondycję by nie umierać po przebiegnięciu kilkunastu metrów w pogoni za odjeżdżającym autobusem.

Podobnie jeśli chcemy zmienić (odchudzić) naszą organizację również musimy mieć do tego dobry powód. Na tyle dobry byśmy sami byli do niego wystarczająco przekonani i byśmy mogli przekonać innych. Często będzie to już niepokojący stan obecny naszej firmy (nie możemy spokojnie spoglądać w lustro).

Dion w swoim artykule napisał coś bardzo istotnego – należy zacząć od restrykcyjnej diety, gdyż uprawianie sportu przy dużej nadwadze wcale nie sprawia przyjemności. Podobnie w przypadku organizacji, gdy cierpi ona na „nadwagę” nie sposób wdrożyć w niej pewnych metod takich jak na przykład TDD czy chociażby automatyzacja testów. A już na pewno nie będzie to przyjemne i łatwe.

Jak już wcześniej pisałem metody takie jak Kanban czy Scrum są swego rodzaju dietą dla naszej organizacji. Same w sobie nie wystarczą do tego, by już na zawsze być zwinnym. Do tego potrzeba długotrwałych zmian nawyków żywieniowych czyli w naszym przypadku zmiany kultury organizacyjnej.

Czy to znaczy, że z pewnymi praktykami i metodami musimy poczekać? Nie, czekać nie musimy, a nawet nie powinniśmy – wspomniane praktyki dodatkowo wzmacniają dyscyplinę i poprawiają efekty naszej „diety”. Niemniej jednak należy pamiętać o tym, że w pewnych sytuacjach będzie to bolesne i może nawet prowadzić do „uszczerbku na zdrowiu”. Bieganie przy dużej nadwadze może skończyć się problemami z kręgosłupem i/lub stawami u nóg, dlatego taki trening musi być dobrze dopasowany do naszych możliwości.

Zasada numer jeden: „mniej jeść” – a w zasadzie jeść rozsądniej i bardziej świadomie. Czy nie na tym właśnie bazuje Scrum czy Kanban? Mamy jeden backlog i ograniczone możliwości realizacji zadań więc musimy wybrać to co jest na tym backlogu najbardziej wartościowe.

Wyobraźmy sobie, że nasze codzienne menu jest zapisane w postaci backlogu – dodajmy limit kalorii (czyli nasze velocity) i teraz możemy uporządkować backlog tak by osiągnąć największą wartość (wartość odżywczą i jednocześnie przyjemność z jedzenia). Nie, nie próbowałem tego – to tylko taki eksperyment myślowy (ale w sumie kto wie…).

Jeszcze jedno wartościowe przesłanie z wspomnianego artykułu – bardzo ważne są widoczne efekty. To właśnie one wzmacniają naszą motywację do dalszego działania. Dlatego też warto zwłaszcza na początku obrać strategię małych zmian dających widoczne efekty.

1 komentarz więcej...