blog.testowka.pl

Scrum

Jeśli awansowałeś na Scrum Mastera…

opublikowany przez 13, Mar, 2014, w kategoriach Agile, Scrum


awans

Jeśli awansowałeś na Scrum Mastera…

…to zmień pracę…

Scrum Master to rola w zespole Scrumowym a nie stanowisko w organizacji. Jeśli ktoś awansował Cię na Scrum Mastera to albo nie ma pojęcia o tym czym jest Scrum i zrobił to ze względu na swoją ignorancję i niewiedzę, albo nie traktuje Cie poważnie…

Jak postąpić, gdy ktoś próbuje mnie awansować na Scrum Mastera? Grzecznie odmówić i wytłumaczyć, że nie da się kogoś awansować w ten sposób. Scrum Master nie jest przełożonym zespołu, a jeśli rolę tą pełni formalny przełożony to ma on zasadniczo utrudnione zadanie.

Niestety wiele organizacji nadal używa „Scrum” (samego słowa, bo to co robią ze Scrum ma niewiele wspólnego) jako narzędzia do marketingu – zarówno na zewnątrz jak i wewnątrz organizacji… Stwierdzenia typu: „Nie obchodzi mi jak to zrobicie ale macie sami wymyślić jak dotrzymać (nierealnych) terminów – przecież jesteście teraz samo-organizującym się zespołem Scrumowym” czy „Teraz jesteśmy Agile więc powinniście wyrabiać 600% normy (za pewnym niefortunnym stwierdzeniem pewnego guru)” są na porządku dziennym jeszcze w wielu firmach…

Pomimo tego iż jest coraz lepiej nadal warto przypominać o tym, że nie wszędzie jest tak różowo…

6 komentarzy więcej...

Komentarz do: „Błąd Arystotelesa w IT”

opublikowany przez 26, Lut, 2014, w kategoriach Agile, CI, Scrum, XP

[W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany „Błąd Arystotelesa w IT„, który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu – poniżej… zapraszam do dyskusji]

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!

Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)…

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać… Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.

Samo omawianie od podstaw metod zwinnych w 2014 roku jest już raczej zbyteczne.
Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu…
Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać… Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup (gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań)

6 komentarzy więcej...

Szanse na zmianę organizacji

opublikowany przez 18, Lut, 2014, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

change1

Upłynęło już sporo wody w Wiśle od momentu, gdy po długiej, motywującej do działania dyskusji Mike Sutton powiedział mi:

If you can’t change organisation probably you need to change organisation…

Te słowa były powodem jednego z myślę, że kluczowych zwrotów w moim życiu. Ale te słowa wymagają również głębszego zastanowienia nad tym co tak naprawdę sprawia, że niektóre organizacje potrafią się zmienić, a inne nie?

Dzięki doświadczeniu jak by nie było w zmienianiu organizacji właśnie, które zbierałem przez ostatnich kilka lat udało mi się zaobserwować kilka czynników, które moim zdaniem w pewnym, znaczącym stopniu determinują czy dana organizacja ma szanse na zmianę.

Z moich obserwacji organizacje dzielą się na trzy typy.

  1. Success Story – Takie które radzą sobie w miarę dobrze. Dla takich organizacji nie ma przeważnie realnych zagrożeń które by zagroziły ich egzystencji (a przynajmniej zagrożenia te nie występują w sposób nagły i nieprzewidywalny). Przeważnie to że te firmy radzą sobie lepiej od innych wynika z tego, że wyrobiły sobie odpowiednie metody szybkiego wprowadzania zmian i reagowania na zmiany w otoczeniu. W takich organizacjach przeważnie wszyscy widzą potrzebę wprowadzania ciągłych zmian i usprawnień jako coś naturalnego, co może sprawić że będzie jeszcze lepiej.
  2. Standard – Organizacje w których nie wszyscy wyrażają chęć zmian czegokolwiek. Organizacje te radzą sobie zazwyczaj przeciętnie, ale nie widzą na horyzoncie (przynajmniej na razie) realnych zagrożeń, które mogły by wymusić jakiekolwiek realne zmiany. W takich organizacjach są oczywiście pojedyncze osoby, które chciały by sprawić by praca była bardziej efektywna i by organizacja wyrosła ponad przeciętną. Osoby te zazwyczaj dostrzegają zmiany na rynku, zmiany w konkurencyjnych firmach i nowe trendy w stosowanych na świecie metodach zapewniające wzrost efektywności.
  3. Tarapaty – Organizacje które są już w poważnych tarapatach. Dla nich zmiana często jest jedynym ratunkiem, a przynajmniej próbą ratunku przed mniej lub bardziej spektakularną porażką. „Poważne tarapaty” nie oznaczają, że organizacja z dnia na dzień przestanie istnieć jeśli nic nie zrobi – to raczej proces długotrwały, niemniej jednak widoczny. W takich organizacjach potrzeby zmian dostrzegane są przez wiele osób bardzo często również na samym szczycie struktury organizacyjnej.

Największe szanse na wprowadzenie realnych zmian mają organizacje z grupy pierwszej i trzeciej. Rozważając dlaczego właśnie tak się często dzieje warto zastanowić się nad tym co wywołuje opór przed zmianą. Prawdę powiedziawszy ludzie po prostu z natury boją się jakichkolwiek zmian, gdyż zmiana zawsze niesie z sobą niepewność, że to co po niej nastąpi będzie gorsze od tego co jest teraz. Oczywiście obawa ta nie jest nieuzasadniona, ale wystarczy w pełni otworzyć się nie tylko na najbliższe zmiany ale także na możliwe (albo raczej pewne) kolejne i strach zaczyna być irracjonalny. Jeśli coś pójdzie nie tak jak powinno to przecież zawsze można znowu coś zmienić.

W organizacjach typu drugiego nie ma realnej potrzeby wprowadzania zmian. Nie ma aspiracji do tego by stać się wybitnie lepszym i obecnie oraz nie ma realnych zagrożeń – przynajmniej chwilowo. Pracownicy takich organizacji, którzy często po prostu chcieli by się rozwijać i poprawiać efektywność swoją jak i swojego otoczenia często cierpią katusze z powodu słabo widocznych efektów ich działań oraz braku docenienia ich starań w kwestii poprawienia stanu obecnego.

Organizacje pierwszej kategorii nie mają problemu ze zmianami. Od pracowników tutaj wręcz wymaga się ciągłego kwestionowania status quo oraz eksperymentowania z różnymi metodami. Nie jest to oczywiście odpowiednie środowisko dla każdego niemniej jednak, ci którzy już się tam znajdą przeważnie nie narzekają na brak motywacji.

Organizacje w tarapatach również czują realną potrzebę wprowadzenia zmian. Jest to dużo trudniejsze niż w przypadku typu nr jeden, lecz opór jest znacznie niższy niż przypadku typu drugiego. Dużo łatwiej jest każdemu zracjonalizować potrzebę wprowadzenia zmian. Ponadto zazwyczaj ludzie i tak w takiej organizacji czują się zagrożeni więc zmiana rzadko kiedy może jeszcze bardziej pogorszyć sytuacje.

Reasumując, aby wprowadzić realne zmiany w organizacji potrzebna jest odpowiednia presja i dobre powody by takowe zmiany wprowadzić. Obecnie za każdym razem, gdy ktoś próbuje mnie zatrudnić do pomocy w transformacji zawsze pytam o konkretne powody wprowadzania zmian. Czasami takie dyskusje wymagają dużej ilości czasu, zastosowania metod coachingowych oraz innych narzędzi by dotrzeć do głównych potrzeb organizacji. Często okazuje się że znając powody potrzeby wprowadzania zmian jesteśmy w stanie dużo lepiej je zaadresować niż w przypadku, gdy klient przychodzi do nas z gotową propozycją rozwiązania swoich problemów i potrzebą zatrudnienia wykonawcy, który takie rozwiązanie wdroży. Zdarzyło mi się już kilkukrotnie odmówić pomocy, gdy widziałem, że jedynym powodem wprowadzania zmian w organizacji była moda lub irracjonalna chęć wykorzystania budżetu szkoleniowego w „jakiś” sposób.

Powyższe to oczywiście tylko moje luźne, subiektywne obserwacje dotyczące kilku organizacji. Nie są to sztywne reguły, które łatwo można dopasować do każdej organizacji. Są to raczej wskazówki pomagające mi i moim kolegom oraz koleżankom z Code Sprinters efektywniej pracować z naszymi klientami od samego początku – w zasadzie współpracować zanim jeszcze rozpoczniemy współpracę.

2 komentarze więcej...

Czym jest Agile Coaching

opublikowany przez 01, Gru, 2013, w kategoriach Agile, Coaching, Scrum, Zarządzanie

coaching

Pisałem jakiś czas temu o tym jak bardzo potrzebujecie Agile Coacha ale w zasadzie nigdy nie wytłumaczyłem czym Agile Coaching tak właściwie jest? Zakres Coachingu Agile dobrze obrazuje powyższy obrazek. Agile Coaching składa się z (co najmniej) pięciu elementów składowych.

Przede wszystkim Agile Coaching nie jest tym samym czym Coaching. Chociaż Coaching jest jednym z narzędzi często stosowanych przez Agile Coacha.

Po pierwsze Mentoring. Agile Coach służy zespołowi/organizacji całym swoim doświadczeniem. Daje przykład, udziela rad, często też uczy jak osiągnąć mistrzostwo. Bardzo istotne jest tutaj doświadczenie Agile Coacha, które nie powinno ograniczać się tylko do pojedynczych metod – jak na przykład Scrum. Coach powinien posiadać szeroką wiedzę i doświadczenie, gdyż celem Coachingu Agile niekoniecznie musi być wdrożenie Scrum czy Kanban – coaching taki ma przede wszystkim za zadanie poprawić efektywność wytwarzania oprogramowania i funkcjonowania organizacji. Częścią mentoringu jest oczywiście doradztwo.

Po drugie Trening. Agile Coach jest trenerem – szkoli zespół i organizacje. Dlatego bardzo istotna jest nie tylko wiedza Agile Coacha ale także umiejętność jej przekazywania. Docelowo Agile Coach chce doprowadzić do sytuacji, w której zespół staje się samodzielny i nie potrzebuje jego dalszej pomocy.

Po trzecie Facylitacja czyli wpływanie na efektywność pracy danej grupy. Zadaniem Agile Coacha jest między innymi usuwanie wszelkich przeszkód, które stoją na drodze zespołu i przeszkadzają w efektywnym dostarczaniu wartości. Facylitator nie musi być merytorycznie zaangażowany w pracę zespołu, wręcz nawet dobrze jeśli potrafi zachować obiektywność i neutralność zwłaszcza w kontekście rozwiązywania sporów. W skrócie Agile Coach w roli facylitatora odpowiedzialny jest za to, by dany proces działał.

Po czwarte Coaching. Coaching to proces mający na celu jak najlepsze wykorzystanie potencjału jakim dysponuje klient (zespół, organizacja). Coaching opiera się na wielu różnych zasadach i założeniach. Coach nie doradza, nie szkoli, nie zarządza – rolą tradycyjnego coacha jest wydobywanie informacji od klienta i pomoc w jak najlepszym zrozumieniu tych informacji, oraz następnie odpowiednim wykorzystaniu ich. Coaching stanowi nieodzowną pomoc podczas wyznaczania celów (dla poszczególnych osób, zespołu i organizacji), a także pozwala na odpowiednie wybranie drogi prowadzącej do osiągnięcia tychże celów, oraz pomaga podczas jej przemierzania. Coaching to proces – narzędzie, które z pewnością zasługuje na bardziej dogłębne opisanie w kolejnych notkach.

I na końcu Management. Jak pisałem w „Mitach i Problemach w Agile” zarządzanie wcale nie musi oznaczać mówienia ludziom co mają robić. Agile Coach zarządza procesem. Powinien też mieć odpowiednie umocowanie w organizacji pozwalające na pracę nad efektywnością stosowanych metod. Często też, organizacje, które zwracają się o pomoc do Agile Coacha pogrążone są w chaosie – w takich sytuacjach, twarde zarządzanie – często w stylu command and control jest najbardziej skuteczne podczas prac porządkujących chaos.

Najtrudniejsze w roli Agile Coacha moim zdaniem nie jest samo zdobycie kompetencji w każdym z wymienionych powyżej zakresów (chociaż do łatwych to nie należy). Znacznie trudniejsze jest odpowiednie „zmienianie kapeluszy” i trafne wcielanie się w każdą w z powyższych ról w zależności od zaistniałej sytuacji. Nieumiejętne wymieszanie powyższych taktyk może mieć bardzo negatywne skutki zarówno dla organizacji, zespołu i coachowanych jak i dla samego Agile Coacha.

Bardzo istotne jest to, że Agile Coach nie jest nigdy częścią grupy, która jest coachowana. Dzięki takiemu podejściu zachowywany jest odpowiedni dystans i obiektywność w ocenie stanu procesu i organizacji. Jeszcze lepsze efekty możemy osiągnąć, gdy Agile Coach nie jest częścią danej organizacji – wtedy jego perspektywa jest już zupełnie niezależna i obiektywna, a dostarczane dzięki temu informacje zwrotne mają jeszcze większą wartość dla całej organizacji.

7 komentarzy więcej...

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

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

(Nie do końca) darmowe szkolenie Scrum

opublikowany przez 17, Wrz, 2013, w kategoriach Agile, Scrum

FREE BEER

Serdecznie zapraszam wszystkich na darmowe szkolenie zatytułowane: „Mity i problemy w Agile – mity o Scrum”, które będę prowadził.

Szkolenie odbędzie się w Krakowie 04.10.2013 – więcej szczegółów oraz rejestracja na stronie www.agileszkolenia.pl.

Za udział w szkoleniu nie musicie nic płacić – jest jednak pewien haczyk.

Szkolenie to organizujemy z Code Sprinters dla społeczności. Poświęcam swój czas na przygotowanie, przeprowadzenie oraz promocję warsztatów. Code Sprinters sponsoruje wszystkie opłaty związane z organizacją szkolenia.

Jedyne czego oczekujemy od Was to, to że w zamian za 8 godzin udziału w szkoleniu poświęcicie 8 godzin swojego czasu dla społeczności.

Przy rozpoczęciu szkolenia podpiszemy umowę w której będzie napisane, że w zamian za udział w szkoleniu zobowiązujecie się poświęcić 8 godzin swojego czasu na rzecz społeczności Agile/Scrum lub innej podobnej, działającej w Waszej okolicy. Umowa będzie sporządzona w jednym egzemplarzu – dla Was. Podpiszemy się na niej – zarówno Ty jak i ja.

Jak to wywiążecie się z umowy – to już zależy od Was. Może na przykład zorganizujecie kolejne spotkanie BYOP? Może sami poprowadzicie jakiś warsztat w tej formie?

Pamiętajcie, że gdy już poświęcicie swoje 8 godzin to możecie w zamian oczekiwać od tych, którzy z tego czasu skorzystali dokładnie tego samego. W ten sposób wkrótce razem zbudujemy coś naprawdę wielkiego!

W ten sposób chcemy sprawić, by więcej osób nie tylko uczestniczyło w wydarzeniach organizowanych przez społeczności takiej jak na przykład BYOP, Agile Warsaw czy ALE Kraków, ale także by pojawili kolejni aktywni członkowie tych społeczności, którzy dadzą coś od siebie.

Cały pomysł zapożyczyłem od Jaume Jornet (@JaumeJornet)- który z powodzeniem aktywizuje społeczność Agile w Barcelonie.

20 komentarzy więcej...