W skrócie: Opisany zespół, miał największą wydajność i najmniej bugów gdy:

• Historyjki były dewelopowane przez programistów o najmniejszej wiedzy domenowej (w obszarze danej historyjki)
• Historyjki były dewelopowane przez pary, które same wybierały nad czym chcą pracować
• Historyjki nie były przypisane konkretnym osobą, cały zespół był odpowiedzialny za historyjkę
• Pary rotowały co ~2 godziny. (Osoba która była dłużej w parze opuszcza parę).

Daj znać innym

Ponieważ to jakie praktyki najlepiej się sprawdzą zależy od naszego kontekstu, zacząłem od opisania sytuacji mojego zespołu.

Zespół w którym jestem jest

• mały (~7 osób)
• wszyscy siedzimy w jednym pokoju
• mamy wewnętrznego klienta / product ownera. Siedzi z nami na tym samym piętrze i ma dla nas czas
• tworzymy ważny, ale wewnętrzny system

Dla każdej praktyki powiedziałem:

• na czym polega
• dlaczego/po co ją stosujemy
• „dobre rady”

Oto lista praktyk, które aktualnie stosujemy w moim zespole:

Codziennie

• Stand-up
• Pair programming
• TDD
• Continuous Integration
• Continuous Delivery
• Story wall / Story lifecycle
• Work in progress limits
• Information radiators
• Learning huddle

Raz na tydzień

• Coding dojo
• Team lunch
• Dev-ops stand-up

Raz na dwa tygodnie

• 1-1 feedback

Raz na miesiąc

• Retrospekcja

Około raz na 3 miesiące

• Incepcja
• Estymacja
• Story mapping
• Persony

Na żądanie / Wg potrzeby

• Technical spike
• Demo / Show case
• Public code review
• Team charter

A jakie praktyki stosuje Twój zespół?

Daj znać innym

Wczoraj rozmawiając z kolegą zaproponowałem zrobienie prostej aplikacji.

Odpowiedział: „O ciekawe! Myśleliśmy już o tym – super pomysł…. Kiedyś mieliśmy „dni innowacji”, ale potem z czasem jakoś przestaliśmy je robić. Gdzie podziały się te pomysły?”

Zapewne jest wiele sposobów na podtrzymanie ekscytującej atmosfery w pracy.

Oczywiście potrzeba ludzi wkręconych i kochających to co robią. Ale Ci ludzie pozostawieni sami sobie z czasem popadną w rutynę, będą znali się na wylot, będą mieli swoje ulubione techniki i style pracy.

Naszemu zespołowi może pomóc: czytanie książek, blogów, Twittera i wyjazdy na konferencje. To zapewni przypływ świeżych pomysłów.

Ale skąd brać siły na ich wdrażanie w terenie, który jest dobrze zbadany i unormowany? Czasem, zwłaszcza z małymi rzeczami nie jest to problem: „Spróbujmy przez tydzień programować w parach.. Hmm, czemu nie?„.

Czasem nie jest to takie proste: „Spróbujmy wrzucać nasz soft na produkcje jednym kliknięciem myszki.. No co ty, to się nie uda, za dużo biurokracji, próbowaliśmy„. Każdy wie, że jest coś czego nie da się zrobić, ale przychodzi ktoś kto nie wie, że się nie da i robi to ! ” Albert Einstein. Jednym słowem potrzebujemy studenta .. Lub, kogoś z autorytetem i wiedzą że się da, bo zrobił to gdzie indziej: konsultanta.

Na chwilę obecną uważam, że by zapewnić przepływ świeżej krwi w zespole potrzeba: konsultantów, którzy są z zespołem od 3 do 6 miesięcy i studentów. Konsultanci wzbogacą zespół ideami z innych miejsc, w których byli. Studenci będą zadawać pytania. Wszystko to zachwieje ustalonym statusem quo i zapewni jakże potrzebny powiew świeżości.

Masz jakieś doświadczenia lub przemyślenia w tym temacie?

Daj znać innym

W telegraficznym skrócie:

Niedziela

• Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

• Google prezentuje nowy język programowania – Dart

Wtorek

• TODO

 Środa

• TODO

Czwartek

• Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
• Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

• Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie

Daj znać innym

Koordynacją wolontariuszy zajmowałem się razem z drugim „Gregiem”. Myślę, że nasz duet w miarę dobrze się sprawdził, mi w każdym razie współpracowało się z Gregiem dobrze

Ciekawostka: W czasie organizacji ALE2011 była to normalna sytuacja (kilka osób odpowiedzialnych za jeden obszar, bez formalnego lidera). ALE2011 wprowadziło koncepcję „sof” (nawiązując do „Conference Chair”).

Podczas konferencji do zadań wolontariuszy należało: rejestracja uczestników, odpowiadanie na pytania w punkcie informacyjnym, pilnowanie czasu prezentacji, zbieranie feedbacku po prezentacji, pomoc w opiece na dziećmi, robienie zdjęć oraz reagowanie na nie przewidziane wydarzenia (np. wyczerpanie się baterii w mikrofonie).

Rekrutacja

Wolontariuszy próbowaliśmy rekrutować za pomocą Twittera, strony eventu, facebooka (bezpośrednie kontakty) i innych sieci społecznościowych. Wysłałem też e-maile do kilku uczelni w Berlinie oraz do Wrocławia. W sumie udało nam się z rekrutować 8 osób, z czego jedna się rozchorowała a druga „nie dawała znaku życia po rejestracji”.

W zespole wolontariuszy były 3 osoby z Berlina (Lina z Kolumbii, Budi i Melisa z Indonezji), 2 osoby z Brna (Petr i Michal) oraz Adam z Krakowa.

• Wszyscy zarejestrowani wolontariusze dowiedzieli się o możliwości bycia wolontariuszem bezpośrednio od kogoś, kogo znali.
• Z 8 zarejestrowanych wolontariuszy, 2 nie dotarło na event. By „bez problemu” poradzić sobie z zadaniami, jakie stały przed wolontariuszami potrzeba by około 14 osób.
• Deadline „rejestracji” wprowadzał zamieszanie. Wolontariusze nie byli pewni czy można się jeszcze rejestrować.
• Ekipa wolontariuszy była świetna
• Plakaty na uczelni! By dotrzeć do studentów, warto by było powiesić plakaty na uczelni. Niestety nie wszyscy śledzą Twittera i wchodzą na stronę konferencji

Daj znać innym

W piątek skończyła się pierwsza paneuropejska konferencja Agile Lean Europe. O konferencji możecie poczytać między innymi na blogu Marcina lub na Twitterze.

Konferencja była dla mnie szczególna, gdyż pierwszy raz wziąłem w niej udział jako koordynator wolontariuszy (wcześniej byłem „tylko” wolontariuszem).  Wiązało się to z dużo większym zaangażowaniem podczas eventu w sprawy „organizacyjne” i mniejszą możliwością udziału w samej konferencji.

Nie mniej jednak miałem okazję poznać sporo fajnych osób i przeprowadzić dużo ciekawych konwersacji, za które swoim rozmówcą chciałbym tutaj podziękować.

Na konferencji:

• Dowiedziałem się o Agile Tour – może w ten sposób można sprowadzić konferencję agile’ową do Wrocławia?
• Spotkałem się z propozycją by w czasie planning pokera zamiast estymować złożoność zadań, estymować to jak bardzo dane zadanie jest dla nas zagadkowe/niepewne.
• Twój manager stosuje micro management? Nie gódź się na to! Walcz! To w naszych rękach jest zmiana świata na lepszy gdzie króluje samoorganizacja
• W czasie retrospekcji co najmniej 50% czasu spędzaj na rozmowach o przyszłości. Jakie konkretnie kroki przeprowadzicie, by poprawić to co jest „teraz”?
• Potrzebujemy studentów, którzy „wiedzą co to agile”. Zaproponuj by wygłosić wykład na uczelni, wyjdź na przeciw do studentów. W tym miejscu chciałbym podziękować doktorowi Madeyskiemu za to, że prowadzi świetne kursy wprowadzające w tematykę Agile’ową na Politechnice Wrocławskiej.
• Poznałem autora techniki Pomodoro, który właśnie przeprowadził się do Berlina
• Być może w Berlinie stworzymy regularne spotkania dla geeków, inspirowane XTC

Najwięcej „dowiedziałem się” o tym jak organizować zespół wolontariuszy – w praktyce. O tym w następnym wpisie

Daj znać innym

Ostatnio na naszej tablicy pojawiły się tajemnicze liczby

Reprezentują one tak zwane limity „Work in progress” (WIP). Na chłopski rozum chodzi mniej więcej o to, ile maksymalnie zadań może jednocześnie przebywać w danej kolumnie..

Dlaczego? Po co?

Zacznijmy od początku..

Przez ostatnie parę miesięcy doskonale radziliśmy sobie bez tych limitów, historyjki płynnie przesuwały się od analizy do stanu zaakceptowania przez Product Ownera(PO).

Ostatnio jednak stan ten uległ zmianie na gorsze. Nasz dotychczasowy tester odszedł do innego projektu. Do zespołu dołączył nowy, ale dzielił swój czas pomiędzy dwa różne zespoły. Dodatkowo naturalnie potrzebował trochę czasu by „wskoczyć na pełne obroty”.  Doprowadziło to do zgromadzenia się wielu historyjek w „kolumnie gotowe do przetestowania”.

Było tak oczywiście ponieważ programiści dalej na pełnej prędkości implementowali życzenia biznesu.

Czemu powyższa sytuacja była nie optymalna?

• Pomimo, że programiści pracowali, biznes nie widział / nie dostawał swoich historyjek. Przecież nie pokażemy czegoś, co nie spełnia najwyższych standardów jakości.
• Gdy nasz tester zabrał się do testowania, programistom było trudniej przypomnieć sobie co i jak dokładnie zostało zrobione. Od momentu testowania dzieliło ich już czasem ponad tydzień pracy nad czymś innym (u nas jest to rzadkość ).
• Czasem podczas testowania może zostać odkryte nowe wymaganie lub problem, który dotyczy kilku historyjek. Im wcześniej coś takiego zostanie wykryte, tym mniej pracy zostanie zmarnowane na pracowanie nad czymś, co i tak trzeba będzie poprawić.

Teraz, gdy programista skończył implementować historyjkę, a kolumna „gotowe do testowania” była pełna, był „zablokowany”. I co tu robić? Oczywiście pomóc z testowaniem!

Limity WIP zmusiły programistów do wyjścia ze strefy komfortu. W ten sposób jako programiści:

Jakby tego było mało, zaraz natknęliśmy się na kolejny limit – „Gotowe do pokazania biznesowi”. I tutaj programiści mieli szansę poćwiczyć nowe umiejętności przygotowując ”demo” i zbierając informację zwrotną od PO.

Generalnie eksperyment z WIP uważamy za udany. Następnym krokiem być może będzie wprowadzenie limitu na historyjki, które czekają na wejście na produkcję. Może w ten sposób uda nam się trochę ten proces usprawnić

Jeśli chcesz dowiedzieć się więcej na ten temat, polecam tę książkę.

Daj znać innym

Zgodziłem się z nim, że retrospekcje są bardzo ważnym elementem procesu wytwarzania oprogramowania. Jest to jedno z pierwszych narzędzi jakie wprowadza do zespołu Alex jako trener.

W czasie rozmowy zdałem sobie sprawę, że nie pamiętam kiedy dokładnie mój zespół miał retrospekcję. Wytłumaczyłem Alexowi, że w naszym zespole wszystko idzie dobrze, a ponadto regularnie mamy sesje feedbacku 1-1. Mina Alexa wskazywała na powątpiewanie

Alex wyraził opinię, że nie powinniśmy zaniedbywać retrospekcji. Następnie opowiedział trochę o jego obserwacji na temat deweloperów: „są bardzo odporni na ból” – z reguły nie narzekają i robią swoje. Dlatego Alex kładzie szczególny nacisk na zachęcenie deweloperów by zwracali szczególną uwagę na wszelki ból jaki odczuwają  ”sprzęt jest za wolny, IDE nie wspiera wykonywanych zadań, za dużo spotkań” itp.

W poniedziałek w pracy zasugerowałem: „kiedy właściwie mieliśmy ostatnią retrospekcję?:)”.

Na wczorajszej retrospekcji zidentyfikowaliśmy kilka konkretnych i poważnych spraw do załatwienia – warto było się spotkać i spojrzeć z boku na to co się dzieje -

Nie zaniedbuj swoich retrospekcji! Spotykajcie się co najmniej raz na miesiąc! (gdy są problemy, częściej!).

Jaki jest klucz do efektywnych retrospekcji? Zapiszcie konkretne akcje, które mają na celu polepszenie sytuacji / rozwiązanie (częściowe) problemów i przypiszcie konkretne osoby do tych akcji. Następnie akcje zawieście w widocznym miejscu na ścianie waszego pokoju.

Ps. Jeśli na prawdę wszystko idzie świetnie, retrospekcje są miejscem w którym można proponować i oceniać eksperymenty. Na przykład my w najbliższym czasie będziemy eksperymentować z WIP.

Daj znać innym

Sądząc po komentarzach uczestników, było fajnie

Łukasz Bałamut wrzucił do sieci świetne zdjęcia.

Następnym razem chcę wziąć udział jako programista

Podczas eventu praktycznie w ogóle nie kodowałem, co następnym razem chcę zmienić – by skorzystać jako programista Z niecierpliwością czekam na wydarzenie z dogodnym dojazdem z Berlina, może Wrocław?

Organizacja CodeRetreat

Liczba uczestników myślę, że była wystarczająca – sala była pełna. Nie mniej.. fakty odnośnie organizacji CodeRetreat:

• Trudno było zdobyć 50 chętnych osób (zajęło to ponad 2 tygodnie, dla porównania w Krakowie miejsca rozeszły się w 2h)
• W dniu eventu pojawiło się tylko 35 osób (z czego spodziewaliśmy się 43 osób, po tym jak pozostałe poinformowały e-mail o rezygnacji).

To, że było nas tylko 35 osób zamiast 50 oznacza, że pewne zasoby od sponsorów się zmarnowały. Pomysły na przyszłość jak temu zaradzić:

• Organizować event na mniejszą liczbę osób (?)
• Pobierać kaucję od uczestników przy rejestracji (płacisz 10 euro, które zwracamy Ci, jeśli przyjdziesz na CodeRetreat)
• Rejestrować +10% więcej uczestników niż jest miejsc.

Na chwilę obecną, najbardziej podoba mi się środkowa opcja.

Poza tym wszystko z organizacją CodeRetreat poszło świetnie. Korzystając z sieci kontaktów i Twittera udało mi się skontaktować z odpowiednimi osobami, które stanowiły trzon zespołu organizacyjnego.

W naszym małym zespole mieliśmy trzy spotkania na żywo.

Podczas pierwszego spotkania nie wiedzieliśmy jeszcze, gdzie odbędzie się CodeRetreat. Na spotkaniu podzieliłem się „wizją” wydarzenia i uzyskałem początkowe wsparcie (w tym ważną deklarację o udostępnieniu sali). Ustaliliśmy, że resztę zadań będziemy koordynować za pomocą narzędzia Kanbanery (które świetnie się sprawdziło).

Drugie spotkanie na żywo odbyło się około miesiąc przed wydarzeniem. Miałem między innymi okazję zobaczyć na żywo salę, w której miało odbyć się CodeRetreat. Ponieważ wszystko szło zgodnie z planem, spotkanie było krótkie i przyjemne

Trzecie spotkanie odbyło się w piątek wieczorem, zaraz przed sobotnim CodeRetreat. W tym spotkaniu uczestniczył też Alexandru Bolboaca, który maił okazję zobaczyć salę na żywo.

Oprócz tych 3 spotkań na organizację CodeRetreat składało się między innymi załatwienie śniadania i obiadu, afterparty, koszulek, podróży i zakwaterowania dla Alex itp. W tym miejscu chciałbym wygłosić kontrowersyjny pogląd dobrze jest pracować w korporacji – wszystko było bardzo łatwo załatwić z pomocą „infrastruktury” dostępnej w korporacji. Na przykład: „Potrzebował bym koszulki..” „Jakie, ile, na kiedy?”

Tak czy inaczej, organizacja Code Retreat jest stosunkowo prosta. Minimum co potrzebujesz to grupę minimum około 12 programistów i salę. Reszta to dodatki Zachęcam Cię do organizacji Code Retreat w Twoim mieście, jest to okazja do nauki, wymiany poglądów i doświadczeń oraz świetna zabawa! Może zorganizujesz CodeRetreat w ramach tego projektu? (osobiście chciałbym w tym dniu zorganizować Code Retreat Berlin i wesprzeć Code Retreat Wrocław).

Daj znać innym

9.07.2011 – CodeRetreat Berlin, które organizuję razem z grupą znajomych w Berlinie. Więcej info na stronie. Ważna data: 6.06.2011 – 18:00 – otwarcie rejestracji. Kto miał okazję uczestniczyć w CodeRetreat ten wie, że warto Kto nie był w Berlinie, ten koniecznie musi wykorzystać tą szansę by odwiedzić te miasto

7-9 wrzesień 2011 - Konferencja ALE2011 w Berlinie. Wkrótce zostanie otwarta koordynowana między innymi prze zemnie rejestracja wolontariuszy. Zapraszam do rejestracji, naprawdę warto

Udział w konferencji jako wolontariusz to okazja do poznania wielu interesujących ludzi ze świata Agile i Lean. Okazja do nawiązania przyjaźni z innymi wolontariuszami z wielu różnych europejskich krajów. No i ciekawa pozycja w CV..

Berlin, to również piękne i różnorodne miasto, które koniecznie trzeba odwiedzić. Jednym słowem, powyższą datę trzeba koniecznie zapisać w kalendarzu jeśli jesteś studentem. O otwarciu rejestracji powiadomię na Twitterze (@dziemid), otwarcie nastąpi prawdopodobnie wkrótce. Zamknięcie rejestracji prawdopodobnie pod koniec czerwca.

Daj znać innym